On July 13, 2018 2:51:58 AM PDT, Benjamin Tissoires <benjamin.tissoires@xxxxxxxxx> wrote: >On Thu, Jul 12, 2018 at 12:50 AM Harry Cutts <hcutts@xxxxxxxxxxxx> >wrote: >> >> Hi all, >> >> I'm currently working on supporting high-resolution scrolling, such >as is found >> on a growing number of mice from Logitech and Microsoft. Below you'll >find my >> proposal for reporting these events through evdev in a >backwards-compatible way. >> I'd appreciate any input you might have. For a quick summary, just >read the >> "Proposed solution" section. > >Hi Harry, > >FYI, there was also a discussion regarding High res events last year, >lead by Mauro: >https://www.spinics.net/lists/linux-doc/msg44752.html > >The outcome was not clear and this is why we never merged the series. >IIRC, the discussion ended up on how are we going to forward the >REL_WHEEL resolution, and there is no simple answer to that. Right, the issue Peter raised is that we do not really have good units of measure or data in general for relative events, such as ABS_X/Y. I think for wheel events we can come up with a reasonable units of measure. > >> >> Thanks, >> >> Harry Cutts >> Chromium OS Touch/Input Team >> >> >> Background >> ========== >> >> A lot of modern mice (mostly from Logitech but also from Microsoft) >support >> high-resolution (sometimes called high-precision) scrolling, which is >normally >> eight times as precise as standard scroll events. The Linux kernel >does not >> currently support this feature, so the mice remain in low-resolution >mode. >> >> Objective >> ========= >> >> Report high-resolution scrolling events to user-space libraries and >applications >> (e.g. libinput, Chromium OS's Aura, LibSDL...). >> >> Requirements: >> 1. Should be backwards-compatible, that is, an application which is >unaware of >> the existence of high-res scrolling should still behave normally >(instead of, >> for example, scrolling 8 times faster on an 8x resolution mouse). >> 2. Should support horizontal scroll wheels (like the one on the >Logitech MX >> Master). >> 3. Should handle higher-resolution scroll wheels that may be produced >in future >> without requiring additional user-space changes. >> 4. Should be vendor-agnostic. >> >> Proposed solution >> ================= >> >> When in high-resolution mode, evdev would report scroll wheel >movements at high >> resolution on new axes (e.g. REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES). >For >> backwards compatibility, however, evdev would continue to report >events on >> REL_WHEEL and REL_HWHEEL, after adjusting for the mouse's scroll >resolution. > >Generally speaking, forwarding twice the same event with different >resolution is a bad idea. This may introduce errors with the blind >evdev xorg driver. These are 2 brand new events so older usesrpace should be ignoring it as it has no idea what they are. It is the same as when we introduced multitouch axes and they did not disturb drivers that were expecting older singletouch events. > >Cheers, >Benjamin > >> >> On the high-resolution axes, movement would be reported as the >distance moved by >> the user's finger, in 256ths of a millimetre. For a wheel this would >be >> calculated using the radius of the wheel and the angle through which >it has >> turned. While it might seem more intuitive to report the angle that >the wheel >> has rotated, this would require the user-space library to scale the >values to >> account for the size of the wheel, as otherwise mice with very small >wheels >> would seem to scroll very fast. (See "Alternatives considered" below >for more >> discussion of this.) >> >> For example, if the mouse scroll resolution is 8x and the user >scrolls 16 mouse >> units up (which translates into 8mm of movement), evdev would report >a >> REL_WHEEL_HI_RES movement of 2048 (8mm * 256) and a REL_WHEEL >movement of 2. The >> resolution of the REL_WHEEL_HI_RES axis would be reported as 128 >(0.5mm). An >> input library which supported high-resolution scrolling would ignore >REL_WHEEL >> and use REL_WHEEL_HI_RES instead, while one that didn't would ignore >> REL_WHEEL_HI_RES (since it wouldn't know it existed) and just use >REL_WHEEL. >> >> Reporting remainders >> -------------------- >> >> Of course, the movements aren't always going to be exact multiples of >> low-resolution units, in particular when the wheel is in freewheel >mode. In the >> example above, what should evdev report on REL_WHEEL if the movement >is 11, or >> 15? The mouse that I tested (a Logitech MX Master 2S) reports >frequent scroll >> events with small magnitudes, meaning that simply rounding the number >on each >> event would stop any scrolling from happening at all (as each event >would be >> rounded to 0). >> >> Instead, we can accumulate the remainder across multiple events until >it is >> greater than one (low-res) notch. For example, we get the following >scroll >> events in quick succession from an 8x wheel: >> >> Value | Remainder | Cumulative | REL_WHEEL units reported >> ------+------------+------------+------------------------- >> 19 | 19 % 8 = 3 | 3 | 2 >> 14 | 6 | 9 - 8 = 1 | 2 (1 from this event, plus 1 from >the >> | | | accumulated remainder) >> 11 | 3 | 4 | 1 >> >> After these events we have an accumulated remainder of 4 left. We >should >> probably also store the timestamp of the last scroll event, and >discard the >> accumulated remainder if it was last added to some time ago (maybe >100ms). >> >> Alternatives considered >> ======================= >> >> Different high-resolution reporting units >> ----------------------------------------- >> >> Current scroll events (on REL_(H)WHEEL axes) are reported as the >number of >> "notches" that the wheel moved. The angle between these notches >varies by mouse, >> but is typically assumed to be 15 degrees unless an hwdb entry [0] >specifies >> otherwise. High-resolution mice (at least from Logitech) report >movements as >> fractions of a notch when in high-resolution mode. Given that we will >be adding >> a new pair of scrolling axes for which backwards compatibility need >not be >> considered, this is a good opportunity to standardise the unit in >which >> scrolling is reported. >> >> The most obvious unit to use would be an angular one, representing >the angle >> through which the wheel has been rotated, and this is indeed how >libinput >> reports scroll events. However, there is variation in the size of >scroll wheels >> [1], which would cause the scroll speed to vary by mouse unless this >was >> accounted for by a similar set of scaling factors in something like >hwdb. >> >> Using distance moved instead removes the need for the user-space >library to >> scale for the wheel size. It does require the device driver to know >or guess the >> wheel size. For devices which do not expose this in any way (which is >all of >> them, as far as I know) the driver can either look the size up in a >hard-coded >> table or assume a sensible default. >> >> Using existing event codes but specifying the resolution >> -------------------------------------------------------- >> >> libinput already takes into account the angle represented by one >notch of the >> scroll wheel by reading the MOUSE_WHEEL_CLICK_COUNT or >MOUSE_WHEEL_CLICK_ANGLE >> properties (or their _HORIZONTAL variants) from udev/hwdb. These are >currently >> only set for relatively minor adjustments, like for a mouse with 20 >degree >> clicks instead of the default 15 degree, but we could set >> MOUSE_WHEEL_CLICK_COUNT as high as 65535. Ideally, of course, systemd >et al >> wouldn't have to maintain lists of mice and their scroll resolutions, >so we >> could report the resolution using the resolution field of the >REL_(H)WHEEL event >> codes for newer user-space libraries to use. >> >> I don't think we should use this approach, because it fails >requirement 1. I had >> thought that would be OK if all major input libraries respected the >hwdb >> properties, but LibSDL, a cross-platform library used by a lot of >games >> (including Valve’s Source engine [3]) does not. If we changed the >resolution >> being reported by evdev scrolling in these games would break, and >updating >> LibSDL would not fix the problem because games generally compile >libraries into >> the binary. >> >> [0]: >https://github.com/systemd/systemd/blob/master/hwdb/70-mouse.hwdb >> [1]: For example, the Apple Mighty Mouse has a very small scroll >ball. >> [2]: Citation: "Porting Source to Linux: Valve’s Lessons Learned", >NVIDIA, >> retrieved on 2018-07-11 from >> >https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/Porting%20Source%20to%20Linux.pdf Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
