The scroll threshold is triggered by a single event exceeding the built-in threshold. This means it relies on the sampling rate of the device, devices with lower sampling rate are more likely to have high-enough deltas. Likewise, continuous motion just below the threshold never triggers scrolling. This can be simply reproduced by moving two fingers down on the touchpad, just slow enough that it doesn't trigger (reported by Benjamin at XDC) The trigger should be dependent on motion/time, not just per event.
(In reply to Peter Hutterer from comment #0) > The scroll threshold is triggered by a single event exceeding the built-in > threshold. This means it relies on the sampling rate of the device, devices > with lower sampling rate are more likely to have high-enough deltas. Ack to changing the threshold to a speed threshold, rather then a move length threshold. > Likewise, continuous motion just below the threshold never triggers > scrolling. Right, this is intentional, because if you want to say scroll only vertical and do a large vertical sweep, the motion will never be exactly 90 degrees to the bottom edge, iow it will always have some x component in there, and a little x component for each event since the movement is at say 88 degrees from the horizontal, we do NOT want to accumulate those x deltas as otherwise any attempt to purely scroll vertical will sooner or later cross the threshold and we will also start sending out horizontal scroll events.
I think there are two stages: triggering the initial scroll which can be distance-based so that a tentative movement can still trigger scrolling (e.g. if the user wants to scroll by a few pixels only they can't move too fast). Then there's the scroll direction lock, once vscroll starts there should be a slight bias against hscroll to start and that's where speed is better than distance. In the long run though we shouldn't be too worried about getting scroll locking to work perfectly in libinput. I think this is something where we aid a bit but the exact behaviour is up to the toolkit to handle when a scroll direction should be locked or not. It is something that may be different for each widget.
commit 2bbf4a0117624e005747d58aaadbed2a0af0a6d4 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Fri Nov 7 16:08:34 2014 +1000 evdev: use distance triggers to start scrolling This commit addresses the first stage as pointed out in the first paragraph in comment 2
Going to call this closed, I think what we have is good enough now. The new edge scrolling support also has a distance-based threshold.
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.