Comment 31 for bug 619403

(In reply to main.haarp from comment #17)
> Configurable acceleration on the input device driver level would solve this
> nicely. You could have fast scrolling when you need it, and even still
> retain slow but precise scrolling when you don't.

I feel this is solving the wrong problem. If the document is long enough that scrolling acceleration is needed, the application (or toolkit) should honor that and provide the appropriate methods - that may include acceleration.
libinput sits too low to have the semantic awareness here. For example, scrolling events during alt-tab switch between applications but libinput doesn't know that, it merely forwards the hardware events.

This is also the reason why libinput doesn't do kinetic scrolling, it merely forwards enough information that a caller can implement it accurately.

(In reply to Albert Zeyer from comment #19)
> You can make the same argument for normal mouse cursor movement, where mouse
> cursor acceleration is a pretty standard thing. And I think it makes even
> more sense for mouse wheel scrolling than it does for mouse cursor movement.

yes, but we've had multiple decades of pointer acceleration being a thing. mouse wheel acceleration is less ubiquitous, which is why we should review the reasons for doing it.

> Also, you would want to make the movement/scrolling as fast as possible. For
> mouse cursor movement, this might be less of a problem because the screen is
> usually of finite size and usually not so big anyway. That is why I think it
> is even more important for scrolling than for cursor movement. The scroll
> area can usually be much larger (e.g. a whole book) or even be infinite and
> you might want to skip over huge parts at once.

judging by the general push towards touch-sensitive interfaces in the industry and the interfaces feeding back into old-style interfaces, it seems a better solution here would be to have kinetic scrolling on the scroll wheel. Which I think enlightenment already does.