You are not logged in.
My mouse wheel scrolling has degraded after update to kernel 5.0 and subsequent point releases this year.
Before upgrade (kernel 4.20.13) mouse worked as expected, one scroll event per wheel click,
Now on kernel 5.0.6 it is one scroll event per 18 wheel clicks, which is one wheel rotation.
Mouse is "Microsft Microsoft Wireless Desktop Receiver 3.1A Mouse".
Normal : one event per wheel click - ~200ms
event7 POINTER_BUTTON +14.19s BTN_LEFT (272) released, seat count: 0
event7 POINTER_AXIS +15.94s vert 15.00/1* horiz 0.00/0 (wheel)
event7 POINTER_MOTION +15.95s 0.53/ 0.00 ( +1.00/ +0.00)
event7 POINTER_AXIS +15.98s vert 15.00/1* horiz 0.00/0 (wheel)
event7 POINTER_AXIS +16.01s vert 15.00/1* horiz 0.00/0 (wheel)
event7 POINTER_MOTION +16.05s 0.35/ 0.00 ( +1.00/ +0.00)
event7 POINTER_AXIS +17.55s vert 15.00/1* horiz 0.00/0 (wheel)
event7 POINTER_AXIS +17.58s vert 15.00/1* horiz 0.00/0 (wheel)
event7 POINTER_AXIS +17.60s vert 15.00/1* horiz 0.00/0 (wheel)
event7 POINTER_AXIS +17.98s vert 15.00/1* horiz 0.00/0 (wheel)
event7 POINTER_AXIS +18.01s vert 15.00/1* horiz 0.00/0 (wheel)
Degraded : one event per wheel rotation - 18 clicks - ~1.1 sec
event4 POINTER_MOTION +1.44s 2.00/ 1.00 ( +2.00/ +1.00)
event4 POINTER_MOTION +1.45s 2.00/ 0.00 ( +2.00/ +0.00)
event4 POINTER_MOTION +1.46s 1.00/ 0.00 ( +1.00/ +0.00)
event4 POINTER_AXIS +4.54s vert 15.00/1* horiz 0.00/0 (wheel)
event4 POINTER_AXIS +9.49s vert 15.00/1* horiz 0.00/0 (wheel)
event4 POINTER_AXIS +10.58s vert 15.00/1* horiz 0.00/0 (wheel)
event4 POINTER_AXIS +11.65s vert 15.00/1* horiz 0.00/0 (wheel)
event4 POINTER_AXIS +12.76s vert 15.00/1* horiz 0.00/0 (wheel)
event4 POINTER_AXIS +13.88s vert 15.00/1* horiz 0.00/0 (wheel)
Some more detailed info from libinput, xinput is at this link : https://paste.ubuntu.com/p/PJhnp9JGNr/
I am running arch on desktop PC, currently up to date. I have no scroll-wheel problem with a USB wired Microsoft mouse. Have been googling this issue for a couple of months now with no success.
Is there is any more information I can provide that might help to focus on this issue?
There appear to be some possible changes in kernel 5 relating to high resolution wheel scrolling for kernel .v4.21, did this roll into v5 maybe and is there a legacy issue with some old hardware?
I need some clues on where to dig deeper, if that is useful.
Last edited by jeffm (2019-04-29 02:29:39)
Offline
Please use code tags when pasting to the boards: https://wiki.archlinux.org/index.php/Co … s_and_code
Offline
Update: more testing today to add to the above information. I had some live USB distros handy so I thought I'd check the hunch that kernel 5.0 is my problem.
booted up on live USB (kubuntu 1904 daily) kernel 5.0.0-7; same scrolling problem with wireless mouse, usb mouse OK
booted on live USB (kubuntu 1810) kernel 4.18.0; wireless mouse works OK
tested wireless mouse on my Dell laptop running up to date arch (kernel 5.0.6); wireless mouse degraded like on my desktop
Still a hunch.
I don't want to buy another mouse, I would rather get to the root cause of this problem.
My next step when I get motivated is to compile latest 5.1rc kernel to see if a fix has eventuated.
Offline
Offline
thanks seth
Yes, I read that post yesterday. It seems similar to my problem. Since the post was solved as a worn-out hardware issue I decided to start a new thread.
I do not see any evidence of 'spurious button debouncing' in any of my Xorg logs.
I have 3 MS wireless mice and they all behave the same. I have a similar vintage MS USB wired mouse which works fine.
On reading through the change logs in kernel.org I see some changes to HID: input: use the Resolution Multiplier for high-resolution scrolling dated 2018-12-07, for module hid-input.c.
I am not a programmer, but it appears to me the changes are additions to change the mouse wheel multiplier wheel click behaviour.... or maybe I am on the wrong track?
But quite definitely, with the 3 MS wireless mice, I get one mouse-click wheel event every 18 clicks - which is one wheel rotation.
Separate mice on separate PCs, same degraded behaviour with kernel v5. All worked fine with 4.19 /4.20.
Offline
Just wanted to add that I also see some issue with slow scrolling using mouse wheel with my Logitech wireless mouse (connected via USB receiver) since kernel 5.0. But in my case it usually works initially, but starts degrading after some use. Sometimes several hours, sometimes shorter, I have not yet found a pattern. I can "fix" it temporarily by unplugging my USB mouse and plugging it in again.
My suspicion so far is also that it is related to the high-resolution scrolling patches. But so far I have not found a way to trigger or reproduce this reliable, and also I have found something obvious in the logs.
Offline
I have just compiled and ran 2 kernels - no .config changes same as my previous kernels :
4.20.17 [EOL] - wireless mouse works as expected - one event per wheel click
5.1-rc4 - wireless mouse degraded - one event per wheel rotation (18 clicks)
So conclusion is that my Microsoft wireless mouse works correctly with latest 4.20 kernel, and not after that.
This is rather disappointing and no doubt will affect others over time.
Offline
You might want to make bug reports for that. This is a new feature, whose consequences might not yet have been fully explored. FWIW I own a logitech G502 that benefits from these patches but I haven't yet ran into an issue. From what it looks like these patches might not yet do the right thing specifically on wireless devices.
Offline
I also have this mouse "Microsft Microsoft Wireless Desktop Receiver 3.1A Mouse" and the scroll became unusable with the latest kernels.
Offline
update.
I have done some hacking of the kernel 5.1-rc6 code for the driver hid-input.c.
I modified a few lines and recompiled the kernel. Result was the mouse is now useable.
The lines modified are detailed here in my comments to a very similar bug - https://bugs.archlinux.org/task/62035#comment178768
As I stated in that post, I don't understand mouse drivers or C code in detail. But I was able to improve the mouse behaviour to something close to normal, just by searching through the code and finding the Hi Res feature additions after 4.20 kernel.
Note there is no regression testing on this so other mice models might not like this hack.
But for now I will sit on this and see how things develop in 5.1.
Offline
https://patchwork.kernel.org/patch/10913251/ may be pulled for 5.1 but I do not think that is the same issue.
You might want to report your issue on linux-input@vger.kernel.org
Offline
thanks, I might do that.
I take it from the comments in these patches they the developers are onto the MS mouse problems and it likely be fixed in the near future. The comments seem to relate to my problem.
I think my dirty hack just over-rode everything in the hid-input driver and allowed the scroll wheel to run as 'lo_res'.
Offline
If you wanted to test it assuming your working tree is 5.1-rc6
git stash # to store your local changes
git remote add hid git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git #add his as a remote
git fetch hid
git merge hid/for-5.1/upstream-fixes #merge the branch with the commits of interest
Offline
I applied patch from here - https://patchwork.kernel.org/patch/10913251/ - to kernel 5.1-rc6 and recompiled with unchanged .config.
this patch addresses hid-core.c and hid-input.c driver modules
output of sudo libinput debug-events shows POINTER_AXIS events for every wheel click, so mouse scroll is normal for these mice that I have tested:
"Miicrosoft Standard Wireless Desktop mouse" - wireless
"Wheel Mouse Optical 1.1A USB and PS/2 Compatible" - USB
"OPTICAL MOUSE" - ?? generic brand - USB
"Microsoft Wireless Optical Mouse 2000" - wireless
The solution appears to be coming in future kernel 5.x release so I have marked this as [SOLVED]
Offline
Probably, I should create a new thread for my issue, but its cause seems to be the new kernel code too. The wheel in my mouse stopped working completely. Downgrading the kernel to version 4.20.13-arch1-1-ARCH fixes the issue. The mouse wheel works in Windows. "xev" and "evtest" do not report wheel events with the new kernel and report wheel events with the aforementioned old kernel. The mouse is A4Tech GLaser optical mouse.
we are not condemned to write ugly code
Offline
my MS wireless mouse scroll wheel problem is fixed in current arch kernel 5.2.1-arch1-1
the relevant kernel code was in hid-core.c and hid-input.c
so from my perspective, is solved.
Offline
Probably, I should create a new thread for my issue …The mouse is A4Tech GLaser optical mouse.
Yes, and also please search before posting: https://bbs.archlinux.org/viewtopic.php?id=247731
Offline