On Tue, Jul 17, 2018 at 01:02:37PM -0700, Harry Cutts wrote: > 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. hmm, back to that second example, let me know if I'm wrong here: My example calculation: remainder | wheel delta | cumulative | click triggered? | leftover ================================================================== 5 | 5 | 10 | up | 2 2 | -5 | -3 | down | -3 -3 | 5 | 2 | up | 2 Your calculation (I think): remainder | wheel delta | cumulative | click triggered? | leftover ================================================================== 5 | 5 | 10 | up | 2 2 | -5 | 7 | | 7 7 | 5 | 12 | up | 4 4 | -5 | 9 | down | 1 1 | 5 | 6 | | 6 6 | -5 | 11 | down | 3 So either way, our wheel clicks are a mess, IMO. With a theoretical reset of the remainder on direction change, the above would only produce the initial up event, then nothing. It would thus require the user to move a fixed amount after changing directions to trigger a click but keep the remainder otherwise to be correct. I think this may be worth trying out, it's *probably* the most intuitive behaviour. > > 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? no, I meant as in "we don't need to write a spec for this", this is implementation-defined behaviour and if we get it wrong we can fix it later to something more useful. Cheers, Peter -- 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
