Disable button scroll timeout for extra mouse buttons
Summary
Disable button scroll timeout for extra mouse buttons. It is currently a compile-time magic number set to 200ms regardless of which button is being used for scrolling.
Feature details
When using button scroll, today we have a fixed hard-coded timeout of 200ms. So when we press+hold the configured scroll button, libinput waits 200ms before it starts to interpret pointer movement as scroll events.
It is not without reason: the designers probably considered that the scroll button usually is the same as the middle (wheel) button. So libinput needs the timeout to decide if the user is simply clicking the middle button or if the user wants to start scrolling.
However, nowadays mice with extra available buttons are very common and the user may want to dedicate one button to use exclusively for scrolling. In that case, the timeout serves no purpose anymore and is only annoying, since the scrolling doesn't respond immediately as the user would expect.
It is #defined as DEFAULT_BUTTON_SCROLL_TIMEOUT
at the file evdev.c
.
As for my personal case, I have compiled libinput hard-coding it to 0 and on my Logitech G703 mouse I assigned the extra button that is located just below the wheel to be the scroll button. I use it to scroll everywhere on my desktop, works smoothly. It is a joy to use it with immediate scroll response, and I can't live without it anymore.
So my request is to make libinput more intelligent and able to judge that a dedicated button is being used, thus disabling the the timeout if that's the case.
I propose evaluating the button number as criterium. If it is "Button 10" or higher, we can be sure it is an extra button with no default assignment.
Affected Hardware
Common mice with extra buttons
Implementation in Other Systems
I don't know about any other system that implements this.