Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#62035 - USB mouse wheel behaviour changed after suspend

Attached to Project: Arch Linux
Opened by Tuomas Jäntti (qwertypoke) - Saturday, 16 March 2019, 23:55 GMT
Task Type Bug Report
Category System
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 3
Private No

Details

Description:

After boot wireless mouse wheel works as desired: Each small step of the wheel results in a step of vertical scrolling. After suspend one single step of vertical scrolling requires about a whole round of the wheel. The amount of wheel steps required is not constant. It varies: 10-30 steps.

Recovering desired usage can be obtained by either rebooting or pulling out the USB-receiver and pushing it back in. Switching the mouse off and on does not restore correct behaviour.


Additional info:
* package version(s)
I really do not know what part of the system is relevant. Please ask for relevant version info.
GUI: Xfce 4.12 kernel 5.0.2
Mouse: Microsoft Wireless Mobile Mouse 3500
* config and/or log files etc.
I will provide these as desired.
* link to upstream bug report, if any

Steps to reproduce:

1) Boot machine: mouse wheel is responding normally
2) Suspend and wake-up: Mouse wheel response is faulty
This task depends upon

Comment by Tuomas Jäntti (qwertypoke) - Sunday, 17 March 2019, 00:32 GMT
Another way of restoring correct action of the mouse:
# modprobe -r usbhid && sleep 5 && modprobe usbhid
Comment by kbt (kbt) - Tuesday, 19 March 2019, 09:51 GMT
I have the same problem, but erratically. I use xmonad, kernel 5.0.0.
Comment by Mathieu Provençal (Amathadius) - Sunday, 24 March 2019, 21:36 GMT
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.
Comment by kbt (kbt) - Tuesday, 26 March 2019, 17:33 GMT
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)
Comment by jeff morcom (jeffm) - Wednesday, 10 April 2019, 12:50 GMT
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.
Comment by Mathieu Provençal (Amathadius) - Thursday, 11 April 2019, 17:00 GMT
sudo rmmod hid_logitech_hidpp

to desactivate the new high resolution scrolling module work.
Comment by Leo (l8789) - Thursday, 18 April 2019, 14:10 GMT
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.
Comment by Ingo Siegert (thebigear) - Thursday, 25 April 2019, 07:11 GMT
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.
Comment by jeff morcom (jeffm) - Thursday, 25 April 2019, 07:50 GMT
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.
Comment by Marcin Mielniczuk (marmistrz) - Tuesday, 21 May 2019, 20:36 GMT
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.

Loading...