On Wed, 18 Jul 2018 at 20:44, Peter Hutterer <peter.hutterer@xxxxxxxxx> wrote: > 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: > > > > 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. Ah, you meant alternating 5 units up and 5 units down. Yes, I see what you mean. > > > * 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. Sounds good. Let's just specify that REL_(H)WHEEL will output /an/ approximation of the high-resolution movement, without specifying what approximation. Before I send out the patches I'll experiment a bit and see what seems good and intuitive to me and my team. 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
