Arch Linux

Another way of restoring correct action of the mouse:
# modprobe -r usbhid && sleep 5 && modprobe usbhid

I have the same problem, but erratically. I use xmonad, kernel 5.0.0.

Same thing here. In fact, it also appends when I don't touch my mouse for a while (sleep mode of the mouse ?)
I think it's related to high-resolution scrolling module implemented in the kernel 5.0.

What I did to solve this:

I installed resetmsmice (available in AUR) and I used systemd to launch it after each suspend (following https://askubuntu.com/questions/92218/how-to-execute-a-command-after-resume-from-suspend)

I can confirm scroll wheel behaviour of MS wireless mouse on kernel 5.0 also 5.1rc4.
No delay after boot in my case and unplugging receiver makes no difference.
The 3 abovementioned workarounds did not help in my case.
My workaround is to roll back kernel to 4.20.13 and wait for a fix in 5.0 or 5.1. Unfortunately I now have a few ignored packages as a result.

sudo rmmod hid_logitech_hidpp

to desactivate the new high resolution scrolling module work.

Same problem here, Kernel Vanilla 5.0.7.
Microsoft Wireless Mouse 1000.
And I don't have the module "hid_logitech_hidpp" listed in lsmod.

resetmsmice did work for me. I also have the feeling that it is related to kernel 5.0, but no high resolution scrolling module loaded.

I just tried resetmsmice trom AUR. I note that it is a fix for certain MS mice that scroll 'abnormally fast' on dual-boot systems.
I have a dual-boot arch/win10 system. MS wireless mouse scrolls abnormally slow and after much googling I cannot find a workaround.

As an example, in order to comfortably scroll from top to bottom of this web page (25 April), I need 60 mouse scroll movements. With a USB wired mouse it takes 3 movements.
In libinput debug-events, I get one POINTER_AXIS event every 18 wheel clicks, instead of every 1 click. (arch kernel 5.0.9)

I suspect the code in kernel 5.x, ../drivers/hid/hid-input.c is the cause of this poor scrolling behaviour, rather than device-specific hires modules. from reading the changelogs, it looks like hires code was added Dec 2018.

I have compiled 5.0 and 5.1-rc kernels with hid-input.c hacked and the mouse scroll behaviour changes, but not in a controlled way.
Trouble is , I do not understand mouse drivers or the algorithms in this module, so I am only guessing by trying different multiplier numbers at lines 1242/1244. I changed the 120 divisor and multipliers from 120 to 40. Now I get an POINTER _AXIS event every 6 clicks instead of 18 !!

code =
hi_res = value * 120/usage->resolution_multiplier;

usage->wheel_accumulated += hi_res;
lo_res = usage->wheel_accumulated/40;
if (lo_res)
usage->wheel_accumulated -= lo_res * 40;

If anyone is interested I can provide more details.

I have only Arch Linux installed on a laptop, which originally came with Ubuntu. I have a MS Wireless Mouse 3500. I don't have hid_logitech_hidpp in lsmod. modprobe'ing usb_hid from the first reply seems to work for me.
I don't have Windows installed on the laptop at all.

I did blacklist the psmouse module though, because it seemed to conflict with the touchpad driver.

I couldn't remove usbhid, because it was in use. Instead, this helped:

# modprobe -r hid_logitech_dj && sleep 5 && modprobe hid_logitech_dj

I have the same issue since some month now with a Microsoft Mouse 1000. Isnt there a bugreport upstream? Has anyone tried the patch from @jeffm? It would be nice if that issue could be fixed :-)

NicoHood,

There was no patch by me, as such.

Just a dirty hack to the hid-input.c kernel module which I then compiled to custom kernel on my pc and which partially fixed my particular mouse problem.

There was a bug report upstream - https://bugzilla.kernel.org/show_bug.cgi?id=202909 - and the kernel experts eventually fixed it in kernel 5.2.

rgds

I cannot reproduce the issue. Is it still valid for you?

Yes! The faulty behaviour is still present, if I disable my fix:

/usr/lib/systemd/system-sleep/10-mouse-fix.sh

#!/bin/bash

case $1/$2 in
pre/*)
# echo "Going to $2..."
/usr/bin/rmmod usbhid
;;
post/*)
# echo "Waking up from $2..."
/usr/bin/modprobe usbhid
;;
esac

# uname -a
Linux orava 5.16.8-arch1-1 #1 SMP PREEMPT Tue, 08 Feb 2022 21:21:08 +0000 x86_64 GNU/Linux

It's already March 2023 and this bug is still exactly the same.

> It's already March 2023 and this bug is still exactly the same.

And continuing to whinge it about here achieves nothing. It's clearly an upstream issue and must be reported to the kernel folks. Arch cannot fix this because it's not an Arch packaging bug.