linux-kernel - Re: Logitech high-resolution scrolling..

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 31 Oct 2018 14:47:52 +0100
From:   Nestor Lopez Casado <nlopezcasad@...itech.com>
To:     hcutts@...omium.org
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        peter.hutterer@...-t.net, jikos@...nel.org,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: Logitech high-resolution scrolling..

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@...omium.org> wrote:
>
> Thanks for the analysis, Peter.
>
> On Mon, 29 Oct 2018 at 23:27, Peter Hutterer <peter.hutterer@...-t.net> 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@...ux-foundation.org> 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