[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgwgmcqxChVXQb66itd__qJOBc7LBsJ+nRAM86qJH-S2Q@mail.gmail.com>
Date: Mon, 29 Oct 2018 08:16:18 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jiri Kosina <jikos@...nel.org>
Cc: Harry Cutts <hcutts@...omium.org>,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
linux-input@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
peter.hutterer@...-t.net
Subject: Re: Logitech high-resolution scrolling..
On Mon, Oct 29, 2018 at 6:18 AM Jiri Kosina <jikos@...nel.org> wrote:
>
> Benjamin indicated that Peter probably has found the issue in the code
> (failure to properly reset on direction change) that might be causing
> this.
So honestly, once I looked at that hid_scroll_counter_handle_scroll()
function, that's the first thing I tried - get rid of the "half-way
threshold" thing, and reset on direction changes.
It fixes the instability, and I don't see the "back-and-forth"
movements and I don't get the "move the mouse and it generates mouse
wheel events" any more.
It basically makes the wheel _work_ for me.
I'm not entirely convinced it's as good as it used to be, though. It
still feels like it might be a bit over-sensitive, but that may be
because now I'm just looking for it..
Patch I'm using attached. I'm inclined to just commit it, but if
somebody has a better idea, I can test alternatives too.
Linus
View attachment "patch.diff" of type "text/x-patch" (2208 bytes)
Powered by blists - more mailing lists