LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Harry Cutts <hcutts@chromium.org>
To: torvalds@linux-foundation.org
Cc: jikos@kernel.org, benjamin.tissoires@redhat.com,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter Hutterer <peter.hutterer@who-t.net>
Subject: Re: Logitech high-resolution scrolling..
Date: Mon, 29 Oct 2018 14:42:42 -0700 [thread overview]
Message-ID: <CA+jURcvVAJbwazWBByh=GTEV-wC75mZA0oaiX0x4_89F_byM6A@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wh3VO9hD9hUBS-H2d4jjGuYuVTudshHsPe9p-5sYhFfGg@mail.gmail.com>
On Mon, 29 Oct 2018 at 14:12, Linus Torvalds <torvalds@linux-foundation.org>
> So what the half-multiplier did, assuming a multiplier of 8 (which is
> what my MX Anywhere 2S reports) would be:
>
> - remainder starts at 3
> - high-res is +1
> - now remainder is 3+1, and it triggers the >= half logic
> - 4/8 is 0, but then the code added 1 because high-res was positive,
> so the code decides to add 1
> - the code does a wheel update of 1, and updates remainder with -8,
> so now it's -4
>
> Next time around, if the high-res update is 0 or -1, it will go the
> other direction. And then it will oscillate.
>
> Notice how tiny movements of +1/-1 in the *high-res* count can
> translate into +1/-1 in the regular wheel movement.
Ah, I see what you mean. So, if we move the threshold to (multiplier -
1)/multiplier (7/8) in this case, I think the equivalent scenario
would be:
- remainder starts at 7
- high-res is +1
- remainder is now 7+1, triggering a low-res update
- 7/8 is 0, but we add one to the remainder in the check making it (7+1)/8 == 1
- we update remainder to -1
This way we're still at least 7/8ths of a notch from the threshold in
either direction, so we shouldn't get the oscillation problem. Does
that sound reasonable, or do you think I've missed something?
> I do not believe that you actually ever *used* that code, or if you
> did, you only did so with applications that were high-res aware and
> ignored the regular wheel entirely because you were testing in an
> environment with other changes than just the kernel.
I tested these changes with 5 different Logitech mice (see the
Logitech high-res support patch [0] for details), and did so mainly
with applications that were *not* high-res aware, using a mix of
clicky and smooth modes. Admittedly the MX Anywhere 2S was not one of
my test devices; I had assumed that its behaviour would be
sufficiently similar to that of the MX Anywhere 2 and the MX Master
2S.
Harry Cutts
Chrome OS Touch/Input team
[0]: https://patchwork.kernel.org/patch/10582935/
next prev parent reply other threads:[~2018-10-29 21:43 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 [this message]
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
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+jURcvVAJbwazWBByh=GTEV-wC75mZA0oaiX0x4_89F_byM6A@mail.gmail.com' \
--to=hcutts@chromium.org \
--cc=benjamin.tissoires@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.hutterer@who-t.net \
--cc=torvalds@linux-foundation.org \
--subject='Re: Logitech high-resolution scrolling..' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).