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 16:03:54 -0700 [thread overview]
Message-ID: <CA+jURcvAQWP-fMLxNBF=PZ7moJZgorjO0SGXn8xSWKt=k+oe1w@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wihpgjONY2iw5mO9gHcQHxRyj+aQcaX2qd9Tjf-MdGNZg@mail.gmail.com>
On Mon, 29 Oct 2018 at 15:01, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> That would work, yes.
OK, I'll write a patch for this. (It may be next week, though, as I
have a deadline on a separate project this week.)
> Except I think you *do* want the "reset on direction change" logic,
> because otherwise we still end up having the:
>
> > - we update remainder to -1
>
> where it now gets easier to next time go the wrong way, for no good
> reason. So now you only need another 6/8ths the other way to get to
> within 7/8ths of -8 and scroll back.
>
> In other words, the whole "round partial scrolling" also causes that
> whole "now the other direction is closer" issue.
>
> At 7/8's it is less obviously a problem than it was at 1/2, but I
> still think it's a sign of an unstable algorithm, where changes get
> triggered too easily in the non-highres world.
>
> Also, honestly, I'm not sure I see the point. *IF* you actually scroll
> more in one direction, it doesn't matter one whit whether you pick
> 1/2, 7/8, or whole multipliers: the *next* step is still always going
> to be one whole multiplier away.
>
> So I think the whole rounding is actually misguided. I think it may
> come from the very fact that you did *not* reset the remainder on
> direction changes, so you could scroll in one direction to -3, and
> then you change direction and go a "whole" tick the other way, but now
> it's just at +5, so you think you need to round up.
>
> With the whole "reset when changing direction", I don't think the
> rounding is necessary, and I don't think it makes sense.
Resetting on direction change would certainly make complete sense in
smooth mode. The reason that I'm reluctant to do it is for clicky
mode, where we think it's important that the low-res event happen at a
consistent point in the movement between notches (the resting
positions of the wheel). For example, imagine the following scenario
with a wheel multiplier of 8 and the threshold initially at 7/8ths of
a notch:
- I scroll one notch down. The low-res event occurs just before the
wheel settles in to its notch, leaving a -1/8th remainder, and then
(on most wheels) the ratchet mechanism settles the wheel 1/8th further
into its resting position, eliminating the remainder.
- I move the wheel 3/8ths further down, then change my mind and start
scrolling upwards.
If we reset on direction change at this point, then the "zero point"
will have moved, so that we trigger the low-res movement at -4/8ths
(at the peak of resistance between the two notches) instead of at
7/8ths. If we don't reset but allow the 3/8ths remainder to be
cleared, the trigger point stays at 7/8ths. It's a minor thing, to be
sure, but we think that keeping the on-screen response consistent with
the tactile feel of the wheel is important for the user experience.
Harry Cutts
Chrome OS Touch/Input team
next prev parent reply other threads:[~2018-10-29 23:04 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 [this message]
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+jURcvAQWP-fMLxNBF=PZ7moJZgorjO0SGXn8xSWKt=k+oe1w@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).