lkml.org 
[lkml]   [2018]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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@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

\
 
 \ /
  Last update: 2018-10-31 14:48    [W:0.383 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site