You are not logged in.
Pages: 1
When I scroll my mouse wheel one tick, it actually scrolls about 8 times along the rotation. Using `xinput test` reveals that it is seeing multiple button presses per click. This is in contrast to another computer that does not see this, and does not have this issue. I have tried creating a udev rule to set the scroll wheel angle as suggested in https://unix.stackexchange.com/question … -sensitive, to no avail. These are the properties of my mouse as given by `xinput list-props 10`
Device 'Logitech G903 LIGHTSPEED Wireless Gaming Mouse w/ HERO':
Device Enabled (164): 1
Coordinate Transformation Matrix (166): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
libinput Natural Scrolling Enabled (293): 0
libinput Natural Scrolling Enabled Default (294): 0
libinput Scroll Methods Available (295): 0, 0, 1
libinput Scroll Method Enabled (296): 0, 0, 0
libinput Scroll Method Enabled Default (297): 0, 0, 0
libinput Button Scrolling Button (298): 2
libinput Button Scrolling Button Default (299): 2
libinput Button Scrolling Button Lock Enabled (300): 0
libinput Button Scrolling Button Lock Enabled Default (301): 0
libinput Middle Emulation Enabled (302): 0
libinput Middle Emulation Enabled Default (303): 0
libinput Accel Speed (304): 0.000000
libinput Accel Speed Default (305): 0.000000
libinput Accel Profiles Available (306): 1, 1
libinput Accel Profile Enabled (307): 1, 0
libinput Accel Profile Enabled Default (308): 1, 0
libinput Left Handed Enabled (309): 0
libinput Left Handed Enabled Default (310): 0
libinput Send Events Modes Available (278): 1, 0
libinput Send Events Mode Enabled (279): 0, 0
libinput Send Events Mode Enabled Default (280): 0, 0
Device Node (281): "/dev/input/event4"
Device Product ID (282): 1133, 49297
libinput Drag Lock Buttons (311): <no items>
libinput Horizontal Scroll Enabled (312): 1
libinput Scrolling Pixel Distance (313): 15
libinput Scrolling Pixel Distance Default (314): 15
libinput High Resolution Wheel Scroll Enabled (315): 1
I have tried messing will all the scroll related options, and they either do something different or appear to do nothing.
Offline
https://bbs.archlinux.org/viewtopic.php … 7#p2076947
libinput High Resolution Wheel Scroll Enabled (315): 1
Offline
Hey it's the same mouse. Since I'm not using X on the machine where I have the issue I tried to quirk it in a /etc/libinput/local-overrides.quirks but it doesn't look like it sends actual proper high res events, but bog standard ticks for every little movement of the wheel.
libinput debug-events --verbose gives something like
event7 POINTER_SCROLL_WHEEL +12.672s vert 15.00/120.0* horiz 0.00/0.0 (wheel)
event7 POINTER_SCROLL_WHEEL +12.686s vert 15.00/120.0* horiz 0.00/0.0 (wheel)
event7 POINTER_SCROLL_WHEEL +12.702s vert 15.00/120.0* horiz 0.00/0.0 (wheel)
event7 POINTER_SCROLL_WHEEL +12.718s vert 15.00/120.0* horiz 0.00/0.0 (wheel)
event7 POINTER_SCROLL_WHEEL +12.750s vert 15.00/120.0* horiz 0.00/0.0 (wheel)
261: event7 - wheel state WHEEL_STATE_SCROLLING → WHEEL_EVENT_SCROLL_DIR_CHANGED → WHEEL_STATE_NONE
... event7 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
... event7 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_ACCUMULATED → WHEEL_STATE_SCROLLING
event7 POINTER_SCROLL_WHEEL +12.946s vert -15.00/-120.0* horiz 0.00/0.0 (wheel)
event7 POINTER_SCROLL_WHEEL +13.029s vert -15.00/-120.0* horiz 0.00/0.0 (wheel)
263: event7 - wheel state WHEEL_STATE_SCROLLING → WHEEL_EVENT_SCROLL_DIR_CHANGED → WHEEL_STATE_NONE
... event7 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
... event7 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_ACCUMULATED → WHEEL_STATE_SCROLLING
event7 POINTER_SCROLL_WHEEL +13.218s vert 15.00/120.0* horiz 0.00/0.0 (wheel)
event7 POINTER_SCROLL_WHEEL +13.253s vert 15.00/120.0* horiz 0.00/0.0 (wheel)
event7 POINTER_SCROLL_WHEEL +13.289s vert 15.00/120.0* horiz 0.00/0.0 (wheel)
which should not happen that uniformly on actual high res implementations if https://wayland.freedesktop.org/libinpu … l-api.html is to be believed. So something must throw the thing off kilter when the querying logic in https://github.com/torvalds/linux/blob/ … pp.c#L3974 is called, you can probably "fix" the issue by just not doing that one, will have to enable some debug logs to check what is actually happeing. Probably gonna call it a night for now, will check/test some more tomorrow/possibly at the weekend. Though FWIW from checking this could also just be an implementation detail of KWin Wayland in my case since proper high res handling will only land in 5.27 https://invent.kde.org/plasma/kwin/-/co … a8b4036112
FWIW the "about 8" aligns with what is configured if debug logging is enabled:
[ 4381.371067] logitech-hidpp-device 0003:046D:C091.0010: HID++ 4.2 device connected.
[ 4381.418934] logitech-hidpp-device 0003:046D:C091.0010: Detected HID++ 2.0 hi-res scroll wheel
[ 4381.434062] logitech-hidpp-device 0003:046D:C091.0010: wheel multiplier = 8
Last edited by V1del (2023-01-04 01:43:44)
Offline
https://www.reddit.com/r/LogitechG/comm … tech_g903/
The mouse supports altering the wheel mode and apparently the toggle button is prone to accidental use.
Does it impact the generated events?
Offline
No, they'll just have the "expected" higher frequency number of events (afaik this really isn't a software button and just impacts how free flowy the wheel is, it doesn't generate a software event when pressed ). Basically the mouse doesnt really scroll by ticks anymore but gets events in the middle between the ticks (if the "button" is relevantly locked). It seems like at least for this case we'd need to quirk/disable it on the kernel level again. From an "intentions" perspective I'm assuming it would (and maybe does on the mices that used to be explicitly enabled with quirks) switch to hi-res mode when the wheel is unlocked and back to ticks mode when not but I don't think this particular mouse actively changes anything of the sort.
Last edited by V1del (2023-01-04 09:25:40)
Offline
I can confirm that this is an issue with the kernel. After booting into lts, this behaviour has been fixed. V1del, if you can also replicate this workaround, that would suggest to me that there is a regression in the kernel, as this issue was not present in previous releases (although I am no expert on these matters).
Offline
Did some more checks, interestingly the issue doesn't pop up if you use the mouse wirelessly with the lightspeed pad/dongle that came with it, only in wired mode it seems to basically generate both the "hi-res events" and the normal full rotation click event at basically the same time. Wirelessly there's a clear distinction between the high res and the "click" event.
FWIW: https://bugzilla.kernel.org/show_bug.cgi?id=216885
Last edited by V1del (2023-01-05 08:51:25)
Offline
I could not get the quirks to work anymore so i used https://aur.archlinux.org/packages/xf86 … res-scroll instead which worked after a reboot.
Offline
Pages: 1