You are not logged in.
Pages: 1
Hi everyone,
I've installed and customized LogiOps in order to use my brand new MX Master 3s mouse and everything works fine except for an odd behavior with the scrolling. Specifically, when I start scrolling, the first "tick" scrolls by several pixels (I'm not sure exactly how many), while subsequent scrolls in the same direction are more precise. The same thing happens if I wait a few seconds and then resume scrolling in the same direction or if I start scrolling in the opposite direction. This is quite annoying because it's impossible to scroll - for example - by just 2-3 pixels only.
Has anyone else experienced this issue, or does anyone have any suggestions on how to fix it?
Thanks in advance for your help!
P.S. I experience the same issue even without LogiOps.
Last edited by fedro (2024-05-20 08:20:21)
Offline
Sounds like a side-effect of the high resolution enablement patchset. If you blacklist hid-logitech-hidpp and reboot/replug the device, is the behavior more aligned with what you expect?
Offline
Sounds like a side-effect of the high resolution enablement patchset. If you blacklist hid-logitech-hidpp and reboot/replug the device, is the behavior more aligned with what you expect?
well... blacklisting that module _does_ solve the initial accumulation, but it totally disables hires scrolling and now each tick scrolls so fast that it is almost unusable :-|
Offline
So you actually want the highres support, but the initial scroll does behave differently from subsequent ones? Maybe compare the info you get while scrolling with hid-logitech-hidpp active and without it when logging with
sudo libinput debug-events --verboseI'm suspecting you want to get rid of the WHEEL_STATE_ACCUMULATING_SCROLL events that happen when switching direction, you should be able to filter those out with libinput quirks https://wayland.freedesktop.org/libinpu … uirks.html
Offline
I'm suspecting you want to get rid of the WHEEL_STATE_ACCUMULATING_SCROLL events that happen when switching direction, you should be able to filter those out with libinput quirks https://wayland.freedesktop.org/libinpu … uirks.html
that seems to be the problem...
log with hidpp enabled:
2: event16 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
4: event16 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_ACCUMULATED → WHEEL_STATE_SCROLLING
-event16 POINTER_SCROLL_WHEEL +0.035s vert 0.53/64.0* horiz 0.00/0.0 (wheel)
event16 POINTER_SCROLL_WHEEL +0.053s vert 0.33/40.0* horiz 0.00/0.0 (wheel)
event16 POINTER_SCROLL_WHEEL +0.062s vert 0.20/24.0* horiz 0.00/0.0 (wheel)
event16 POINTER_SCROLL_WHEEL +0.228s vert 0.13/16.0* horiz 0.00/0.0 (wheel)
event16 POINTER_SCROLL_WHEEL +0.263s vert 0.20/24.0* horiz 0.00/0.0 (wheel)
event16 POINTER_SCROLL_WHEEL +0.272s vert 0.13/16.0* horiz 0.00/0.0 (wheel)
event16 POINTER_SCROLL_WHEEL +0.281s vert 0.13/16.0* horiz 0.00/0.0 (wheel)
event16 POINTER_SCROLL_WHEEL +0.289s vert 0.20/24.0* horiz 0.00/0.0 (wheel)
and without hidpp:
2: event16 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
... event16 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_DIR_CHANGED → WHEEL_STATE_NONE
... event16 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
... event16 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_ACCUMULATED → WHEEL_STATE_SCROLLING
-event16 POINTER_SCROLL_WHEEL +0.000s vert 3.00/360.0* horiz 0.00/0.0 (wheel)
event16 POINTER_SCROLL_WHEEL +0.017s vert 2.00/240.0* horiz 0.00/0.0 (wheel)
event16 POINTER_SCROLL_WHEEL +0.026s vert 3.00/360.0* horiz 0.00/0.0 (wheel)
event16 POINTER_SCROLL_WHEEL +0.044s vert 3.00/360.0* horiz 0.00/0.0 (wheel)
i am trying to figure out how to filter those events, as it seems to be the cause of my problem. any ideas? i can't find anything related to it on the libinput docs
Offline
Pages: 1