SUMMARY Ever since upgrading to Plasma 6 (now currently on 6.0.2), my Mx master 3's scroll wheel has started to slow down to a crawl and slighly erratically on every application after a limited period of usage, most notably after a screen lock. This is fixed after a reboot, but the issue will consistently reappear again. This issue previously happened very rarely (maybe once a month) on Plasma 5, and I attributed it to the mouse itself. In these past cases, switching off and on the mouse fixed it, but now it doesn't. STEPS TO REPRODUCE 1. Have a Mx master 3 (not sure if any other mouse with a free/unlocked scrollwheel is affected) 2. Let the computer idle and automatically screen lock 3. Go back in: now the scrollwheel will be unusably slow Relevant external reports, all also mentioning that it started to happen after the Plasma 6 release: https://github.com/pwr-Solaar/Solaar/issues/2404 https://www.reddit.com/r/archlinux/comments/1bekbon/arch_kde/ I have been trying to catch something in journalctl, but I haven't found anything around the time before & after the issue happens.
Is this on wayland or x11?
This is on the Wayland session, I haven't tested it on X but I will try to see if it happens there too
Using Solaar, I cannot trigger this by locking the screen, but by restarting the mouse or letting it go into standby mode. The issue seems to be not exactly with the scroll speed configuration (which determines how far a scroll event moves) but the disabled hires scrolling mode, which causes scroll events to be emitted only about twice per revolution,
(In reply to Jonathan from comment #3) > Using Solaar, I cannot trigger this by locking the screen, but by restarting > the mouse or letting it go into standby mode. The issue seems to be not > exactly with the scroll speed configuration (which determines how far a > scroll event moves) but the disabled hires scrolling mode, which causes > scroll events to be emitted only about twice per revolution, True! I just tested this, and the fact that it went to standby around the same time my screen was set to lock was a coincidence. I just let the mouse idle while using the computer and indeed I was able to replicate it this way. There is nothing relevant in journalctl around the time it went on standby, although when I moved the mouse again I could only see the following in journalctl (the mouse is connected via bluetooth): Mar 19 11:40:12 mostriyo bluetoothd[1788]: Device is already marked as connected Also: In my case, I don't use Solaar/logiops at all
I can confirm this on the following system: Operating System: Manjaro Linux KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.6.22-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz Memory: 62,5 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: LENOVO Product Name: 20L6S6D100 System Version: ThinkPad T480 Using the MX Anywhere 3 mouse.
I can also confirm this on Fedora 40, on Wayland. 6.0.2 as well. I litterally have to roll the mousewheel like mad if I want to scroll. My scrolling finger is growing muscles! XD
Some testing revealed that the issue persists after kwin_wayland restarts, so this problem is on a lower level. Please report this to the kernel developers for further investigation
I'm going to reset this to bluez-qt, seems more related to this. I did some more additional testing: As the bug reporter said, this occured at first when the system goes in suspend mode (Meta+L, let the screens turn off) for a while. But I was also able to reproduce this without letting the system go to sleep/lock, by simply turning off the bluetooth mouse using the power toggle behind it. So, as I do have a backup mouse, I decided to go in system settings, in the bluetooth settings, and turned off bluetooth. Waited 10 seconds, and turned it back on. No more bluetooth. The mouse no longer connects. Going in the system logs, I see the following: Mar 20 13:38:15 steve-desktop systemsettings[6479]: kf.bluezqt: PendingCall Error: "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."
So, this is unlikely to be KDE's fault. I tried to restart the bluetooth service, and after about 20 seconds, it restarted and bluetooth came back. Maybe a problem with bluetoothd?
The scrolling issue is certainly not caused by bluez-qt, that is not involved with bluetooth mouse input (except for pairing). > Mar 20 13:38:15 steve-desktop systemsettings[6479]: kf.bluezqt: PendingCall Error: "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." This suggests that bluez is somehow stuck/broken