Re: RFC libinput high-resolution wheel scrolling
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 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Upcoming release
On 1/18/19 4:20 PM, Derek Foreman wrote: > Hi all, > > It's been quite some time since our last weston release, and there's > been some discussion of getting the next one out in the January to March > timeframe (this would be the last release to have an autotools build, btw). > > Does anyone have objections to an early February freeze and a March > release? Anyone with large series near completion? > > Also, I'd like to float the idea of removing the fbdev backend for this > release (or the next). The bulk of the interesting features target the > drm backend, and it feels like fbdev can sometimes be a bit of a pain to > update when changes are required elsewhere. Any strong opinions either way? Ok, I've heard no complaints, and we really are overdue... There's been some reasonable pushback against dropping fbdev immediately, so let's leave that in for this release. As to the release schedule, maybe: February 1, Alpha February 15, Beta March 1, RC1 March 8 as a first potential final release date. Is this too soon to enter freeze? It's not a lot of warning. Wayland has had enough changes that I think another joint release makes sense. Thanks, Derek ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC libinput high-resolution wheel scrolling
Hi!, I surely missed the gitlab ping, hope this makes up for it :). On Fri, Jan 25, 2019 at 6:28 AM Peter Hutterer 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. > > 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
