Comment 34 for bug 619403

(In reply to main.haarp from comment #21)
> If acceleration depends on the toolkit/application, I fear it'll remain a
> toy for select applications on modern distros only.

it's a thin line between adding these features for legacy applications and screwing things up for new applications that could do it better themselves. the worst mistake we made along these lines was kinetic scrolling in the synaptics driver, in addition to the various bugs it also made it impossible for clients to implement it properly themselves. something like wheel acceleration would be the same, it is transparent to the point that it makes smart acceleration in a client virtually impossible.

(In reply to Claudius Ellsel from comment #22)
> So if handling this in libinput causes problems, maybe there is a different
> central place where to implement it.
> How do Windows or MacOS handle this, as it is probably working without
> issues there?

Win/MacOS have less toolkits to worry about *and* they control almost the whole stack :)
it'd be possible to add it as additional data in libinput but then you still require the compositor to pass the data on. Which requires a) updates to the software and b) a wayland protocol to send that data on which again requires a), so legacy applications are still out in the void.