-
Notifications
You must be signed in to change notification settings - Fork 409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
G502 side scroll buttons need onboard profiles to work correctly in Linux #2618
Comments
Solaar should not require the plugdev group any more. What Solaar needs is access to /dev/hidrawN nodes, which is done using a udev rule. Are you sure that you mean side scroll? Solaar doesn't do anything with that on your mouse as far as I can tell. It may be that changing owner is what is interfering with side scroll. |
I guess that explains why I had to chgrp -- the udev file sets "uaccess" and does ACLs (for systemd machines?) -- but those aren't on my machine. Changing group works. It's better than putting my user into the The write access seems required for solaar to do its thing, and the breakage of side-scroll doesn't happen until I start solaar. Since I've saved most things to my mouse's hardware profile, I've been using it without solaar for a while. Side-scroll (toggling the scroll wheel to the left or right) still works. Then,
It shows the expected buttons 6 and 7, whereas after I start solaar (per description up top), the side-scroll comes out as buttons 14 and 15 -- same as in the linked issue #86. What I haven't been able to save to the hardware profile: when the mouse is idle for a minute or so, it turns the LEDs back on. Solaar nixes that immediately and all's well. |
Addendum, the above xev is with the group changed,
so it would have to be something with solaar seeing a non-root group and remapping buttons somehow.
0: appears to be my wired logitech mouse, 1: is the wireless. Solaar has not been running, and a |
As I have the same model mouse I tried changing various setting to see what happens. It turns out that disabling onboard profiles changes what side scroll produces. Onboard profiles do affect what the buttons produce, so it looks as if the default (no active profile) is for the two buttons to produce mouse buttons 14 and 15. It is not abnormal for mice to have a mapping that doesn't work well in Linux and this used to be fixed by using xmodmap. The profiles on the mouse turn these buttons into left and right tilt. Either these produce what Linux expects for left and right shift or some Linux driver knows enough to translate these inputs into the appropriate mouse buttons. Probably the best solution is to turn on onboard profiles (or change the setting to ignore). This probably does mean that you can't modify the DPI or report rate directly in Solaar and would have to dump, edit, and reload the profiles if you want to modify either. |
Information
solaar --version
orgit describe --tags
if cloned from this repository):uname -srmo
):Linux 6.6.47-gentoo x86_64
solaar show
:~/.config/solaar/config.yaml
(or~/.config/solaar/config.json
if~/.config/solaar/config.yaml
not present):Describe the bug
Side scrolling breaks shortly after plugging in the mouse. It seems to be related to Scroll Wheel Resolution (which I disable, because I hate the partial-line scroll, and also scrolling between clicks).
This seems related to #86. When I run
xev
, the left-and-right scroll of the scroll wheel show buttons 14 and 15 (whereas the issue suggests it should be 6 and 7).If I unplug the receiver and plug it back in, it works all right; because I'm not in plugdev group, I change the owner of the hiddev devices in /dev to my user, start solaar, and side-scroll stops working.
The text was updated successfully, but these errors were encountered: