Mouse scroll wheel barely works after suspend

[Paul Tansom]

After a resuming from a suspend the mouse scroll wheel is almost, but not quite, non functional. If you scroll quickly for a while you do get a slight movement of the scroll bar to show that there is some level of communication, but nothing remotely usable.

The fix is to use the following commands to remove the hid_generic module and reinstate it:

sudo rmmod hid_generic
sudo modprobe hid_generic

Following this all works as expected until the next suspend.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: linux-modules-5.0.0-13-generic 5.0.0-13.14
ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6
Uname: Linux 5.0.0-13-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: paul 1905 F.... pulseaudio
 /dev/snd/controlC1: paul 1905 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Sun Apr 21 19:02:00 2019
Dependencies:

EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=8032c5f7-74fd-4a23-92cb-5ad7d0642a9f
InstallationDate: Installed on 2017-12-15 (491 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
MachineType: LENOVO 20238
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-13-generic root=UUID=63abd1a6-61ac-485b-9448-47d635ee8808 ro quiet splash vt.handoff=1
RelatedPackageVersions:
 linux-restricted-modules-5.0.0-13-generic N/A
 linux-backports-modules-5.0.0-13-generic N/A
 linux-firmware 1.178
SourcePackage: linux
UpgradeStatus: Upgraded to disco on 2019-04-20 (1 days ago)
dmi.bios.date: 10/20/2014
dmi.bios.vendor: LENOVO
dmi.bios.version: 79CN50WW(V3.09)
dmi.board.asset.tag: No Asset Tag
dmi.board.name: INVALID
dmi.board.vendor: LENOVO
dmi.board.version: 31900058Std
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Lenovo G510
dmi.modalias: dmi:bvnLENOVO:bvr79CN50WW(V3.09):bd10/20/2014:svnLENOVO:pn20238:pvrLenovoG510:rvnLENOVO:rnINVALID:rvr31900058Std:cvnLENOVO:ct10:cvrLenovoG510:
dmi.product.family: IDEAPAD
dmi.product.name: 20238
dmi.product.sku: LENOVO_MT_20238
dmi.product.version: Lenovo G510
dmi.sys.vendor: LENOVO

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Kai-Heng Feng (kaihengfeng)]

Is this a regression? Does this issue happen to previous kernel releases?

[Paul Tansom (aptanet)]

I did not have this problem prior to upgrading to 19.04. The upgrade process was an upgrade from 18.04 to 18.10 with an immediate upgrade to 19.04 (after a clean reboot), so there was no usage of 18.10 as a desktop environment to compare with. The 18.04 install was kept up to date.

I have tested using the installed linux-image-4.18.0-17-generic kernel and found that there are no problems. During the test process I have noted that there are no problems if the suspend is initiated manually using the top right 'menu' to suspend instead of shutdown or reboot. There is a problem, however, if the suspend is initiated by simply closing the laptop.

[Paul Tansom (aptanet)]

Updating to 19.10 hasn't fixed the problem, but I have just replaced my mouse and found the issue is no longer there with the new one. The original was a Microsoft Wireless Mobile Mouse 1000 (045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth) and the new one is a Logitech M220 (046d:c534 Logitech, Inc. Unifying Receiver).

Not a fix, but a work around perhaps and extra info for any debugging. I still have the Microsoft one to test any fixes posted here.

[Paul Tansom (aptanet)]

I've now tested the Microsoft mouse on my desktop computer and the scroll wheel works find after a suspend / resume, so this looks to be a clash with the hardware in the laptop - a Lenovo G510.

[Tim Starling (tstarling)]

This is sporadically reproducible for me. It's probably a hardware quirk. I have Ubuntu 20.04 with Linux 5.4.0-37-generic. I'm using a "Microsoft Mobile Mouse 4000" which presents itself as 045e:07b2 "Microsoft Corp. 2.4GHz Transceiver v8.0 used by mouse Wireless Desktop 900". The issue only occurs when the transceiver is plugged into a desktop USB hub (MBHUB-43ST presenting as VIA Labs 2109:2813). When it is working, inspecting the event stream with cat /sys/kernel/debug/hid/.../events while slowly scrolling gives a series of events of size 3:

report (size 10) (numbered) = 1a 00 00 00 00 00 03 00 00 00
Button.0001 = 0
Button.0002 = 0
Button.0003 = 0
Button.0004 = 0
Button.0005 = 0
GenericDesktop.X = 0
GenericDesktop.Y = 0
GenericDesktop.Wheel = 3
Consumer.HorizontalWheel = 0

Fast scrolling gives events that are some multiple of 3.

After suspend/resume, the events have a size of 1:

report (size 10) (numbered) = 1a 00 00 00 00 00 01 00 00 00
Button.0001 = 0
Button.0002 = 0
Button.0003 = 0
Button.0004 = 0
Button.0005 = 0
GenericDesktop.X = 0
GenericDesktop.Y = 0
GenericDesktop.Wheel = 1
Consumer.HorizontalWheel = 0

My reading of the source implies that the kernel is not scaling these events, the numbers are coming straight from the hardware.

The power light on the desktop hub briefly goes off as the laptop enters suspend. This doesn't always happen but seems to be correlated with the mouse breaking.

Removing and re-adding the usbhid kernel module does fix it, but I suspect that's because the device is reset rather than because of any state in the kernel.