High-res axis support needs heuristics for buggy devices
Some devices (esp. those created by userspace through uinput) may enable REL_WHEEL_HI_RES
as part of an "enable all bits" code block. Those devices may never send high-resolution wheel events, leading to broken scroll. libinput currently uses the high-res bits as indicator whether we should ignore the old ones or not.
libinput needs some heuristics there, possibly: if we get a REL_WHEEL
event without ever seeing a REL_WHEEL_HI_RES
event, print a kernel bug with a link to the docs and switch to REL_WHEEL
instead. The doc should suggest a quirk to disable the event code.
The assumption is that high-res scrolling is at least as-fine grained as wheel scrolling, so we should always see a high-res event in the same frame or before the legacy event. There's a very niche case where we may see a wheel event before a high-res event but it's not worth worrying about, imo. Worst case, we can switch the detection to work on the second REL_WHEEL
event.
See #667 (closed) for an example of this bug in real life.