Mouse wheel scrolling speed becomes slow after sleep

[ciello]

Hello! I’m an immigrant from Windows looking forward to switch to Tumbleweed as my main OS. Been loving it so far, but there are some hiccups, the worst being a mouse issue.

My mouse and keyboard receiver is plugged into an USB port of my monitor. When I put Tumbleweed to sleep, if I turn off the monitor then back on when I’m ready to wake up the computer the mouse wheel will have its speed greatly decreased to something like 0.5 lines per scroll.

The full sequence of events causing the issue:

• Put the Tumbleweed to sleep.
• Turn off the display.
• Turn it back on.
• Awake the computer by pressing the power button (as peripherals plugged into the display always stop responding until the computer is back on; that’s normal behavior in any OS I’ve used).
• The lock screen comes up, mouse and keyboard work as usual, but the scrolling speed will be off.

It can be “fixed” by either rebooting or turning the display off and back on twice: The first time it won’t come back, receiving no signal, the second time it’ll work properly, receiving signal and with mouse scrolling speed fixed.

The issue doesn’t happen if I simply turn the display off and back on while the computer is awake. It has to be asleep to trigger it.

Although I’m power user on Windows I’m still nearly helpless on Linux. I took a peek at the mouse settings but there’s nothing about the wheel. I can’t see anything relevant on journalctl but I’m not a good judge yet.

I’m on openSUSE Tumbleweed 20240621, KDE distro. It’s a 2 days old fresh install.

[ciello]

Update: I didn’t manage to fix the underlying issue, but came up with a workaround to easily reset the receiver usb.

1. I got the vendor id via lsusb.
2. Then I added it to this one-liner:
   usb_id=`awk -F'/' '{print $6}' <<< "$(grep VENDOR_ID_GOES_HERE /sys/bus/usb/devices/*/idVendor)"` && echo "$usb_id" |sudo tee /sys/bus/usb/drivers/usb/unbind && echo "$usb_id" |sudo tee /sys/bus/usb/drivers/usb/bind

Assuming you only have a device with that vid, the above script will retrieve the current device id attached to it then unbind and bind again – the equivalent to physically removing and plugging the device or in my case turning the display off (powering down the device) and on again.

Regarding the issue itself, I found no clues through xinput. It never changes and ignores any wheel speed prop I set anyway.

Another dead end is kcminit. I noticed it’d run kcminit /usr/lib64/qt6/plugins/plasma/kcms/systemsettings/kcm_mouse.soafter powering down the usb, but it’s useless without rebinding the usb, and once you rebind kcminit will run automatically.

[marel]

It looks like you are on KDE, “kcminit”.

In my mouse settings I see:

Is that “0.60” changing after sleep? Is may the pointer acceleration changing?

[ciello]

It’s not the pointer it’s the wheel, for which there’s no option in the settings. Everything else about the mouse is fine after waking up, including the pointer.

My settings show a pointer speed of 0.00 by the way. It doesn’t change when the glitch happens.

Meanwhile, these are the xinput props for the mouse (which also never change values when the wheel is glitching):

Device 'Microsoft Microsoft® 2.4GHz Transceiver v7.0 Mouse':
        Device Enabled (204):   1
        Coordinate Transformation Matrix (206): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        libinput Natural Scrolling Enabled (358):       0
        libinput Natural Scrolling Enabled Default (359):       0
        libinput Scroll Methods Available (360):        0, 0, 1
        libinput Scroll Method Enabled (361):   0, 0, 0
        libinput Scroll Method Enabled Default (362):   0, 0, 0
        libinput Button Scrolling Button (363): 2
        libinput Button Scrolling Button Default (364): 2
        libinput Button Scrolling Button Lock Enabled (365):    0
        libinput Button Scrolling Button Lock Enabled Default (366):    0
        libinput Middle Emulation Enabled (367):        0
        libinput Middle Emulation Enabled Default (368):        0
        libinput Rotation Angle (340):  0.000000
        libinput Rotation Angle Default (341):  0.000000
        libinput Accel Speed (369):     0.000000
        libinput Accel Speed Default (370):     0.000000
        libinput Accel Profiles Available (371):        1, 1, 1
        libinput Accel Profile Enabled (372):   0, 1, 0
        libinput Accel Profile Enabled Default (373):   1, 0, 0
        libinput Accel Custom Fallback Points (374):    <no items>
        libinput Accel Custom Fallback Step (375):      0.000000
        libinput Accel Custom Motion Points (376):      <no items>
        libinput Accel Custom Motion Step (377):        0.000000
        libinput Accel Custom Scroll Points (378):      <no items>
        libinput Accel Custom Scroll Step (379):        0.000000
        libinput Left Handed Enabled (380):     0
        libinput Left Handed Enabled Default (381):     0
        libinput Send Events Modes Available (342):     1, 0
        libinput Send Events Mode Enabled (343):        0, 0
        libinput Send Events Mode Enabled Default (344):        0, 0
        Device Node (345):      "/dev/input/event5"
        Device Product ID (346):        1118, 1970
        libinput Drag Lock Buttons (382):       <no items>
        libinput Horizontal Scroll Enabled (383):       1
        libinput Scrolling Pixel Distance (384):        15
        libinput Scrolling Pixel Distance Default (385):        15
        libinput High Resolution Wheel Scroll Enabled (386):    1

Could be lack of support for the model, but pretty much the only props that do anything are the enable/disable ones. I’ve tried to change the libinput Scrolling Pixel Distance (goes from 10 to 50 if I recall correctly) and nothing changes when the wheel is glitching nor when it’s not.

So it’s not very helpful in tracking the issue either.

[marel]

Searching for “linux scroll wheel speed” gives pretty good information solving this.

You might need “sudo zypper se imwheel” but that is not everything you also need a config file for that seen the Internet and let us know if it works. Would be even better so share you config here once you made it so others can benefit.

[ciello]

Thanks, but I’m not sure how imwheel is a better workaround than rebinding the usb. It won’t help debug the issue, it’s just a different method to fixing the mouse after the fact and more contrived imho.

I don’t need a package geared towards tweaking the scrolling speed per app, the scrolling already behaves exactly as I wish unless it’s glitching after the sleep, and for that now I already have a temporary solution.

[marel]

Clear.

Would not surprise me if this is a hardware problem of the mouse given the information you provided. Would be good to see if you can reproduce the problem with another (brand) mouse.

[ciello]

Yeah, might be the mouse. It’s a Microsoft mouse and keyboard kit for a start (I get the irony!).

It could also be just weirdness for plugging it into the display usb. Sometimes devices just hate to be plugged into a hub getting powered down in the middle of a sleep.

In any case I’ve added the rebind script to a service running on wake up, so the entire thing is automated now.