On Mon, 16 Jul 2018 at 21:40, Peter Hutterer <peter.hutterer@xxxxxxxxx> wrote: > On Wed, Jul 11, 2018 at 03:50:32PM -0700, Harry Cutts wrote: > > 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.) > > I really like defining it through mm instead of an angle, I wish I'd have > thought of that for libinput. Having a fixed physical reference defined as > part of the axis is great because it removes the need for EVIOCGABS > equivalents on the REL axis. The question is: where is the resolution stored > and how or whether it is reported. You could get away without exposing it to > userspace at all but you'd then remove the notion of a "wheel click" on that > axis. Userspace would have to match the highres motion with the REL_WHEEL > data to guess how much motion constitutes a click. Or just accept that world > has changed and wheel clicks are out of fashion now :) > > That's not bad, but it should be noted somewhere that this changes the > notion of scroll wheel axes away from the traditional clicks. Mostly > pointing this out to make sure that that is the intention here. Good point. Yes, there won't be a notion of a "click" on the high resolution axes, although if something in userspace wants "clicky" behaviour they can always look at the legacy low-resolution axes instead. > > 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). > > remainders are tricky. Small movements can happen within the treshold > boundaries or across the threshold and produce different results. > > Assume the above 8 threshold level and assume a continuous movement up/down > by 5 units. Start with a remainder of 2 and you get 7/2/7/2/7/2 - userspace > gets high res up/down events but no REL_WHEEL. Start with a remainder of 5 > and you get 10/-3/2/-3/2/-3 - userspace gets both high res and REL_WHEEL > events for every transition across the threshold. Since the remainder isn't > visible, it's hard to predict for the user. I'm not sure I understand your examples. Maybe I wasn't clear in describing my method. In the first, the method I described would send a REL_WHEEL event for every other REL_WHEEL_HI_RES event (when the remainder exceeds 8), which approximates the scrolling speed (5/8ths of a notch per event) pretty well. In the second example I think the remainder should be 2/7/4/1/6/3, which does give a different pattern of REL_WHEEL events. > This is a general problem with click-less wheels anyway and not a killer, > but do add this to the TODO list of things to sort out in case it's not > already on there. > > Resetting the remainder on directional changes is probably the easiest > solution here but the usefulness depends on whether the data can be messy > (i.e. whether wheels can send unintended negative scroll events). This is something I want to experiment with once I have a preliminary solution working; I should have labelled my example here as more of a rough idea than a fixed method. The mouse I've tested so far (the Logitech MX Master 2S) only sends +1 or -1 for each event (with events being more frequent), which would mean that cases like this wouldn't happen, but there certainly could be mice which behave differently. > > 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. > > tbh, my hopes for drivers getting this always right are ... limited, so > we'll end up with a hwdb-like quirk database *somewhere*. Because six months > after you added the driver for the ACME Supermouse, the newly released > Supermouse 2 can use the same driver but has a different resolution. > > So - either a kernel update for everyone or a userspace quirk through the > hwdb. The latter is a lot easier to handle but it requires an ioctl. Yes, I definitely see your concern here. I will add ioctls for setting this factor (as well as the resolution factor used when sending the REL_WHEEL events). > So summary: > * mm instead of angle is good > * having 1/256mm as fixed base resolution is good > * we need an ioctl to fix/correct some devices > * we need "implementation-defined" remainder handling What do you mean by "implementation-defined"? Defined by the driver implementation? > > [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, Harry Cutts Chromium OS Touch/Input Team -- 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
