Bug 104569

Summary: Touchpad two-finger scrolling is 2x the velocity of cursor movement
Product: Wayland Reporter: Daniel van Vugt <daniel.van.vugt>
Component: libinputAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED NOTOURBUG QA Contact:
Severity: normal    
Priority: medium CC: nate, peter.hutterer
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Daniel van Vugt 2018-01-10 07:48:25 UTC
Touchpad two-finger scrolling is 2x the velocity of cursor movement. This is annoyingly fast, particularly if you're trying to offer "natural scrolling". It's not natural if things move twice as fast when after the second finger touches.

Initially I put this down to just something that needed fine tuning somewhere. But now I realize I can get a nice saner speed of scrolling if I keep one finger still and move the other. So it seems like the two-finger scroll velocity is scaled by the number of fingers you move. Or the sum of fingers that are moving.

I think this needs to be changed such that when moving both fingers the scroll speed is the same as when keeping one still and moving one.
Comment 1 Peter Hutterer 2018-01-16 06:39:34 UTC
The scroll speed is the average across finger movement, so if both fingers move by 100 units down, the movement is 100 units. If two fingers are down and only one moves 100u, the movement is 50u. Happy to hear suggestions on how to improve this.
Comment 2 Daniel van Vugt 2018-01-16 06:53:54 UTC
Thanks. I'm slightly surprised it is averaged because that means the average of two fingers scrolling something appears to have double the velocity of one finger moving the cursor. This implies it's not the gesture recognition that needs improving but just the velocity, which could be done anywhere in the stack. So I'll need to try some more things to see if it's best tweaked somewhere like Xwayland or GTK instead.

My goal is to have two finger natural scrolling moving the scroll area at about the same speed as one finger would move the cursor. Presently it feels like double that so scrolling with one finger stationary appears to give a more natural speed, similar to macOS or ChromeOS. I know fixed/floating-point scroll axes are not usually in the same units cursor motion, but we can get the perception closer than it is just by halving the scroll velocity somewhere.
Comment 3 Peter Hutterer 2018-01-16 07:18:05 UTC
libinput promises that the data matches the cursor movement, so a Ncm finger movement generates the same coordinate data as an Ncm scroll movement. scrolling itself is unaccelerated though, so it'll be less than the finger movement, but the coordinate systems are the same.

Check with libinput debug-events if the data matches. If not, it's a libinput bug, otherwise it's higher up the stack.
Comment 4 Daniel van Vugt 2018-01-16 07:22:15 UTC
That's more odd then, since the opposite is happening. It sounds like scrolling should be slightly slower than cursor movement, but it appears to go faster.
Comment 5 Peter Hutterer 2018-01-16 23:47:45 UTC
You're observing this on the libinput level or in the applications? You need to verify this first on the libinput level, running libinput debug-events and then comparing the motion deltas with the pointer axis deltas from a comparable two-finger scroll events.

I just stared at the code for a while and it is virtually the same minus the acceleration applied to finger motion. Compare tp_gesture_post_pointer_motion() and tp_gesture_handle_state_scroll(), they're almost identical. The only speed difference would happen for very slow motions where the pointer has deceleration applied but scrolling doesn't.
Comment 6 Daniel van Vugt 2018-02-15 12:03:30 UTC
Sorry I haven't had time to get back to this properly yet.

An interesting observation though: In bug 105108 I noticed the jitter on the Yoga 11S touchpad becomes amplified during two-finger scrolling. So it appears the two fingers are getting added instead of averaged.
Comment 7 Daniel van Vugt 2018-02-24 08:47:57 UTC
OK, I think I can see libinput outputting correctly averaged scroll values.

It seems this is mostly a bug in GTK, and possibly also Chromium. The former has some scary magic numbers in scaling its scrolling velocity :P

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.