Hi guys, I've read the discussion, I think I understand the problem and I'll get back to this thread with more information as soon as I've got some internal feedback. BTW, lovely to see so many MX Anywhere 2 users :) -nestor On Tue, Oct 30, 2018 at 6:48 PM Harry Cutts <hcutts@xxxxxxxxxxxx> wrote: > > Thanks for the analysis, Peter. > > On Mon, 29 Oct 2018 at 23:27, Peter Hutterer <peter.hutterer@xxxxxxxxx> wrote: > > IMO this is a lost battle because you cannot know when the ratchet is > > enabled or not (at least not on all mice). Users switch between ratchet and > > freewheeling time and once you're out of one mode, you have no reference > > to the other mode's reset point anymore. > > It would be a lost battle, if it weren't for the fact that on all the > mice I've tested, putting the wheel back into clicky mode causes the > wheel to jump to the nearest notch resting point, which should mean > that the remainder resets to 0 (or maybe ±1 if the mechanism is worn). > > > So my suggestion is to combine Linus' reset with your approach and use the > > center-point for the trigger. This gives us a few events to slide and still > > do the right thing, and any direction change will reset anyway. Biggest > > drawback is that the first event after a direction change is triggered > > faster than the next event. Otherwise it feels correct to me, both in > > free-wheeling and in ratchet mode now. > > This sounds like a reasonable approach if we find that we can't keep > the triggering point consistent. > > > Also, WTF moment: I managed to get the mouse into a state where it would > > only give me 1 hi-res event per notch movement but failed to reproduce that > > again. > > Interesting; let me know if you manage to reliably reproduce it. The > only time I've encountered this in the past was when connecting to the > mouse over BLE, where we don't seem to be able to detect if the mouse > is power cycled (meaning that the mouse resets to low-res mode but the > kernel is still expecting high-res reports). I held off on enabling > high-res scrolling over Bluetooth for this reason. > > On Tue, 30 Oct 2018 at 09:29, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > I wonder if there's some docs on what Logitech does internally in the > > mouse. It might involve a timeout (ie "if not moving for a while, do > > the rounding _and_ reset), which would probably be too expensive to do > > on the host side. > > I've been wondering this as well. Nestor (CCed), is there anything you > can tell us about this? > > Harry Cutts > Chrome OS Touch/Input team
