WIP: XWayland high-resolution scroll wheel support
Patchset to add high-resolution scroll wheels to XWayland. I'll need some comments here please, because it'll be tricky to get right. GTK will have to deal with the same issues, and probably everyone else.
- with high-resolution scroll wheels, a wheel may send
wl_pointer.axisevents without a
wl_pointer.axis_discretein the same frame (assuming that's how the compositors end up doing it)
- weston/mutter multiple a discrete event by 10 but wlroots takes the libinput value (usually 15).
- XWayland and GTK have the same 'bug' in that they assume that events without a discrete event stand on their own. Qt doesn't seem to handle discrete events so it's not affected here.
The immediate effect is that for hires scroll wheels we get small scrolls for each fraction, then a large scroll movement when the last fraction comes in with the discrete value set. e.g. we scroll 20%, 20%, 20%, 20%, 20+100%, totalling 200% of the distance it should go.
The second patch in this set ignores any non-discrete axis events from wheels, waiting for the discrete event to show up. This disables any hi-res scrolling but it gets rid of the 200% movement at least. Issues with that: it relies on the compositor to send discrete events which is not guaranteed .
This doesn't even cover the right handling for hires events which will run into the same issues that I ran into with the xf86-input-libinput driver - without a new API like the libinput v120 we cannot map values to parts of a scroll wheel movement.
And even with that new API, we'll have to do some stunts to be correctly backwards compatible because afaict, most client implementations are likely to see the same bug. In the compositor
- we cannot send discrete 0 + value nonzero without triggering the bug
- we could accumulate axis values until discrete is nonzero and send it out like lores events, but that would prevent hires from working
- we can stop sending discrete events, but that will change the behaviour of the mouse wheel (I think)
- we can start sending v120 events instead of discrete events, which requires more client version tracking in the compositor
Right now, the last two points seem to be the most sensible options, stop sending discrete events (they are optional anyway) and start sending v120 events instead (given the right wl_seat version in the client).
Any help/comments would be much appreciated, thanks!
Note: this is untested and just an RFC for now
 Could be fixed with a heuristic, if we accumulate $threshold values without seeing a discrete event, we assume we never get one of those and switch to the other code path.
[edit: expanded on the backwards compatibility issues]