LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Nestor Lopez Casado <nlopezcasad@logitech.com>
To: hcutts@chromium.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	peter.hutterer@who-t.net, jikos@kernel.org,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: Logitech high-resolution scrolling..
Date: Wed, 31 Oct 2018 14:47:52 +0100	[thread overview]
Message-ID: <CAE7qMrpdNxbbN3PX5=GASm1U_N4Phd_diDrsagC+GSTo=cvhsQ@mail.gmail.com> (raw)
In-Reply-To: <CA+jURctDNnVjKEZD6jm3ACv1r8_Me9f+6T_aRiApR=Nd_+upvw@mail.gmail.com>

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@chromium.org> wrote:
>
> Thanks for the analysis, Peter.
>
> On Mon, 29 Oct 2018 at 23:27, Peter Hutterer <peter.hutterer@who-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@linux-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

      reply	other threads:[~2018-10-31 13: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
2018-10-31 13:47                       ` Nestor Lopez Casado [this message]

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='CAE7qMrpdNxbbN3PX5=GASm1U_N4Phd_diDrsagC+GSTo=cvhsQ@mail.gmail.com' \
    --to=nlopezcasad@logitech.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=hcutts@chromium.org \
    --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).