Scroll events still being sent after the fingers are raised

[joeytwiddle]

If I do a fast two-finger scroll on a trackpad, I notice the events are sent eased, and they continue to appear for some time after my fingers has left the pad. (This can be observed in xev as a slowing stream of button 4 or 5 events.)

This easing is a nice feature for smooth scrolling, but it has some issues.

• If you press the Control button while the events are still being received, the window will receive Ctrl-WheelUp/Down events, which many applications process as a zoom request (shrink or enlarge view).
• If you move your mouse away from the window while the events are still being received, they will be send to the newly focused window!

This behaviour can be somewhat disruptive. A common example of this is scrolling to the top of a browser tab and then hitting Ctrl-PageDown to visit the next tab.

I would be curious to see how apps behave if we were to send all the events as soon as possible, or with a faster repeat rate.

Is this behaviour coded into focaltech-dkms, or elsewhere in the stack? Do you know any way to configure the easing or the repeat rate?

[hanipouspilot]

This behavior is not in the kernel driver. It is in a user space. If you use xorg-synaptics, you can try libinput instead.

Or you can look into synaptics options.

[joeytwiddle]

I see. synclient allows me to configure Vert and HorizScrollDelta, but I don't see any options there for repeat rate.

I might have found some relevant code in xserver-xorg-input-synaptics. But it looks like libinput will replace it in future! How to switch to libinput: Fedora / Ubuntu

[hanipouspilot]

Ubuntu 15.10 has libinput in repositories. For other distros you can use this manual:

http://askubuntu.com/a/651008/167850

[joeytwiddle]

Many thanks hanipouspilot! :cake:

I was interested to discover that Nautilus is already doing very fine-grained scrolling on my system, which means it is already possible, just Chrome, Firefox and xterm aren't doing it yet.