RFE - Touchpad scroll - Consider using an acceleration curve
This is a lower priority request for enhancement, and I'm willing to implement this one as well - as long as it can fit within libinput's design goals... which doesn't seem certain.
If this doesn't fit the libinput project, please don't hesitate to close as Invalid/Wontfix. Thanks for considering.
Current behavior
- Scroll movement exactly corresponds, proportionally, to movement of finger(s) on touchpad
- Advantages:
- Simpler and more reliable to implement; more universally consistent across hardware
- Small touchpads can still scroll far enough with small movements
- Toolkits/applications get unfiltered scrolling data
- Disadvantages:
- Less scrolling speed range is available
- Less refined movement at start of scrolls, sudden start instead of gradual
- When the scroll amount of large movements is enough, the scroll amount of small movements is too much
Desired enhancement
- Slightly decelerate slower finger movements and accelerate larger finger movements
- Use a small windowed average vector (like in
scroll-vectors
branch) to smooth motion subtly - Smoother start to scrolls, less visually jarring
Considerations
- This would be tricky to implement in a universally applicable way
- In a quick & dirty ugly hack, using a curve like this gave good subjective results (on one touchpad)
- Issues arose in testing on different sized touchpads; size matters a lot
- Performance is slightly different depending on toolkit (Gtk/Qt)
- Is this even the right level to put something like this? Could this be considered similar to pointer acceleration, or is scrolling fundamentally different, such that libinput needs to pass events unchanged to toolkits/applications?
- If libinput is not the right place to implement this:
- What would need to happen, in which other projects, to achieve this goal?
- How realistic is it to expect that could happen anytime soon?
- If "not very realistic":
- Is there a practical way I could make a separate application or library, to act as a shim between libinput and X11 or the Wayland compositor, and filter/transform scroll events?
- That might be a convenient way to allow people to install such a thing if they want it, without cluttering up libinput itself