<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - Change scroll thresholds to work as motion/time" href="https://bugs.freedesktop.org/show_bug.cgi?id=85991#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - Change scroll thresholds to work as motion/time" href="https://bugs.freedesktop.org/show_bug.cgi?id=85991">bug 85991</a> from <a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>