Touchpad-scrolling 'too fast' leads to no scrolling at all (libinput issue?)

Dear all,

Visualy scrolling commonly works fine on my system, no matter in which application and whether I use the mouse or the touchpad. However, the touchpad scrolling (2-finger scroll) has an annoying issue: Whenever I move my 2 fingers too fastly (e.g. from top to bottom of trackpad to bottom of trackpad within ~200ms), it has the effect that the focused window scrolls only a tiny bit, and in a jerky fashion.

Has anyone observed this issue (I couldn’t find anything, even after several web researches), and/or can suggest a libinput configuration that might fix this?

System: MBP M2 Air 15"
System: Asahi NixOS 24.11
WM: EXWM
Touchpad driver: libinput

Thank you for any suggestion

Try switching temporarily to xf86-input-synaptics (services.xserver.synaptics.enable) to see if the problem is exclusively with libinput. If not, it may be your touchpad driver.

1 Like

Thanks a lot for the suggestion @rnhmjoj. I finally managed to try synaptics, but it performs even more jerky (perhaps because it’s not configured sensitively enough).

Is there a way to print debug statements both from the touchpad driver and from libinput while scrolling, to see what is actually detected? (similar to xev or so)

There is, run

nix-shell -p evtest --run 'sudo evtest'

then select you touchpad from the list of devices and you should start receiving realtime events from it.

Thanks a lot @rnhmjoj! I now found the time to play around a bit.

  • In URXVT, the scrolling works as expected (no jerk-freezing behaviour)
  • In Chrome (and other GUI application), there is the previously described behaviour
  • The evtest readouts look good in both cases:

In Chrome (color code is gradient of position (i.e. movement; to help identify potential jitters):

In URXVT:

The issue seems to be more towards the application layer it seems. Do you have an idea where to dig next?

No idea. Did the problem appear recently? In that case it may be easier to bisect Nixpkgs than to wade through the stack of libraries between the kernel and chromium.

I experienced this problem always.

I did some more tests that might help:

The issue is also present in some other GUI applications (e.g. VSCode), but not in others (e.g. Thunar, Urxvt, Firefox). It’s also independent of the WindowManager (e.g. I tried in KDE and observe the same problem with VSCode and Chrome).

It’s just so weird that no-one else seems to suffer from this problem…

VSCode is an electron application, so it’s chromium too. It may be just a bug in chromium.