Improve hardcoded delay value for button scrolling
Summary
When using button scrolling, a hardcoded delay of 200 milliseconds between button down and scroll events being emitted makes fast scrolling gestures feel clunky and sometimes fail entirely. Let's discuss what this timeout value should be.
Feature details
When using button scrolling (where holding a chosen button down translates pointer movement into scroll events), there is a hardcoded delay of 200 milliseconds (in src/evdev.c) during which the pointer is immobilised, but scroll events are not yet emitted. This delay forms part of the design allowing the chosen button to perform both its normal function and the button scroll function. It acts to prevent minor mouse movement during what is intended to be a normal click from swallowing the click event and instead emitting scroll events. (It is likely that a pointing device will experience minor movement during a normal button press; that is what this delay is attempting to work around.)
200 milliseconds is a long time. I have used dedicated utils in the past to provide this functionality on other operating systems, and those utils do not attempt to preserve the button's original function, and thereby have no need of a delay. Using those utils, it's easy to press the scroll button and immediately begin scrolling, which feels quite natural. Attempting this gesture with the 200 ms delay in place is much more clunky; the intended scrolling often does not happen at all (for quick "one page" scroll flicks, which for me take less than 200 ms).
I discussed this a bit with @whot over email, and he suggested we could discuss perhaps changing the timeout length, as the 200 ms value was chosen seemingly arbitrarily and has never changed.
I've compiled libinput with the delay reduced to 50 ms, which feels fairly natural for scrolling, but starts to lose the intended "anti-jitter" effect. I'm not sure whether a value exists which would both enable natural scrolling gestures and preserve the button's original function. Perhaps we need to concretely determine how much anti-jitter is needed?
Affected Hardware
Any pointing devices that use button scrolling are affected.
The feature in its current state benefits devices such as mice, but devices such as trackpads and trackballs actually see little benefit because it is easy to press a button with absolutely no pointer movement.
Implementation in Other Systems
Other utils typically don't attempt to preserve the button's original function, and so don't have a delay in place.