Bug 85991

Summary:	Change scroll thresholds to work as motion/time
Product:	Wayland	Reporter:	Peter Hutterer <peter.hutterer>
Component:	libinput	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium	CC:	benjamin.tissoires, jwrdegoede, peter.hutterer
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:	85988
Bug Blocks:

Description Peter Hutterer 2014-11-07 05:32:16 UTC

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.

Comment 1 Hans de Goede 2014-11-07 13:33:03 UTC

(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.

Comment 2 Peter Hutterer 2014-11-10 00:36:36 UTC

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.

Comment 3 Peter Hutterer 2014-11-13 02:07:07 UTC

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

Comment 4 Peter Hutterer 2014-11-25 23:01:58 UTC

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.