From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nestor Lopez Casado Subject: Re: Logitech high-resolution scrolling.. Date: Wed, 31 Oct 2018 14:47:52 +0100 Message-ID: References: <20181030062657.GA5380@jelly> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: hcutts@chromium.org Cc: Linus Torvalds , peter.hutterer@who-t.net, jikos@kernel.org, Benjamin Tissoires , "open list:HID CORE LAYER" , linux-kernel@vger.kernel.org List-Id: linux-input@vger.kernel.org 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 wrote: > > Thanks for the analysis, Peter. > > On Mon, 29 Oct 2018 at 23:27, Peter Hutterer w= rote: > > 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 referenc= e > > 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 =C2=B11 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 s= till > > 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 woul= d > > 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 > 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