LKML Archive on
help / color / mirror / Atom feed
From: Harry Cutts <>
Cc: Peter Hutterer <>,,,,,
	Nestor Lopez Casado <>
Subject: Re: Logitech high-resolution scrolling..
Date: Tue, 30 Oct 2018 10:48:25 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Thanks for the analysis, Peter.

On Mon, 29 Oct 2018 at 23:27, Peter Hutterer <> 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
<> 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

  reply	other threads:[~2018-10-30 17:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-28 19:13 Linus Torvalds
2018-10-28 21:08 ` Linus Torvalds
2018-10-30 15:53   ` Mauro Carvalho Chehab
2018-10-29 13:18 ` Jiri Kosina
2018-10-29 15:16   ` Linus Torvalds
2018-10-29 18:32     ` Linus Torvalds
2018-10-29 19:17       ` Harry Cutts
2018-10-29 21:11         ` Linus Torvalds
2018-10-29 21:42           ` Harry Cutts
2018-10-29 22:00             ` Linus Torvalds
2018-10-29 23:03               ` Harry Cutts
2018-10-30  6:26                 ` Peter Hutterer
2018-10-30 16:29                   ` Linus Torvalds
2018-10-30 17:48                     ` Harry Cutts [this message]
2018-10-31 13:47                       ` Nestor Lopez Casado

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \
    --subject='Re: Logitech high-resolution scrolling..' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).