RFC libinput high-resolution wheel scrolling

[Peter Hutterer]

On 25/1/19 21:54 , Carlos Garnacho wrote:
> Hi!,
> 
> I surely missed the gitlab ping, hope this makes up for it :).

thanks. as much as I prefer the gitlab workflow, it makes it even more 
impossible to guess at how many people actually see what you're doing in 
terms of patches... at least with a mailing list I know it lands in a 
few inboxes.

> On Fri, Jan 25, 2019 at 6:28 AM Peter Hutterer <peter.hutterer at who-t.net> wrote:
>>
>> I'm sending this here to get some more exposure. The kernel will get
>> high-resolution scroll wheels with the 5.0 release. The details are in the
>> blog post linked below [1], but the short summary is that we now get
>> REL_WHEEL for full clicks and REL_WHEEL_HI_RES for fine-grained events.
>>
>> The units REL_WHEEL_HI_RES are: 120 is one logical wheel click, a fraction
>> thereof indicates a wheel movement by that. The 120 value comes from the
>> Windows Vista API btw.
>>
>> So an event sequence for a 20 degree wheel movement on my Logitech MX
>> Anywhere 2S is this:
>>
>> EV_REL REL_WHEEL_HI_RES 15
>> EV_SYN SYN_REPORT
>> EV_REL REL_WHEEL_HI_RES 15
>> EV_SYN SYN_REPORT
>> EV_REL REL_WHEEL_HI_RES 15
>> EV_SYN SYN_REPORT
>> EV_REL REL_WHEEL_HI_RES 15
>> EV_SYN SYN_REPORT
>> EV_REL REL_WHEEL_HI_RES 15
>> EV_SYN SYN_REPORT
>> EV_REL REL_WHEEL_HI_RES 15
>> EV_SYN SYN_REPORT
>> EV_REL REL_WHEEL_HI_RES 15
>> EV_SYN SYN_REPORT
>> EV_REL REL_WHEEL_HI_RES 15
>> EV_REL REL_WHEEL 1
>> EV_SYN SYN_REPORT
>>
>> In short, we get 7 event frames with hi-res only, then one frame with both
>> hi-res and the low-res event.
>>
>> libinput's API has libinput_event_pointer_axis_get_value() and
>> libinput_event_pointer_axis_get_value_discrete(). For wheel events, the
>> former returns the rotation angle, the latter the number of logical clicks.
>> Currently, this means you'd get e.g. 15/1 for most mice, or 20/1 for some
>> others. With the kernel above, you now get 7 events with 2.5/0, one event
>> with 2.5/1, i.e. the value must be accumulated if you want click-based
>> scrolling (this is already the case for non-wheel scroll events).
>>
>> I tried integrating this into the xf86-input-libinput driver and it was...
>> tricky. That driver needs to know everyhing ahead of time but with the
>> current API you don't know the full click angle until you get the first
>> discrete event. AFAICT, both mutter and weston would have similar issues
>> when adding the above.
>>
>> The solution I came up with, see [2], is to forward the 120 value with a new
>> API: libinput_pointer_axis_get_value_v120()
> 
> I wonder if normalizing the value between [0..1] would have any
> drawbacks, or returning the inverse (eg. 8 for "this is an 8th of a
> click") if you want to stick to integers. 120 is a smart value (many
> multiples and whatnot), but seems strange to let a "magical number" to
> sink this much deep in api.

tbh, I'm not too worried about magic number proliferation since this is 
in the windows API so every hw manufacturer already has to accommodate 
for it (and that's been the case for a decade now). And the kernel 
exposes this API now as well.

normalizing would work but the available multipliers don't lend 
themselves to "nice" floating points (e.g. 1/6 or 1/12).

the inverse (1/8 of a click) works as long as every movement is less 
than a full click - that's not the case for fast movements where you may 
get a v120 value of 240 (or 180, a click and a half) within one event frame.

so in both cases the alternative isn't as flexible as the 120 value.

Cheers,
   Peter


> 
>>
>> For the MX Anywhere 2S, each event thus now gives me three values:
>> 7 events with 2.5/0/15 and 1 event with 2.5/1/15.
>>
>> For the caller, this means:
>> - easy enough to calculate the click angle from the first event where needed
>>    (no generic caller actually cares about this though, it's a rather
>>    specialised case).
>> - easy to do click-angle-independent pointer movement
>>
>> Seems to be easy to integrate into weston/mutter. There shouldn't be any
>> need for wayland protocol updates either, we can just do the fraction of the
>> movement so instead of 10 per event, we now send 10/120 * v120 value. So we
>> need the compositors to handle a new API, but at least the wayland client
>> side doesn't change.
>>
>> Any comments? Anything I've overlooked?
> 
> Semantics aside, I think the reasoning sounds good.
> 
> Cheers,
>    Carlos
>