Description of problem: In the past few weeks, I noticed several times that the scroll wheel on my Logitech M720 mouse was *extremely* slow. Just to scroll a web page a few lines I had to roll the wheel several times. By my estimate, it was something like 10x slower than usual (I had to scroll 10x the distance to see the same effect as usual). This was not related to my web browser, I saw the same problem in Nautilus, in gnome-shell overview, everywhere. When I powered the mouse off and back on (using a toggle on its bottom side), it fixed itself. (Also, cycling through input sources with a special button on the mouse fixed it). I only notice this very irregularly, like once or twice a week. So far, it never happened while I was actively using the PC, but always when it was in idle (the monitor in standby due to inactivity, but the system was running, not suspended) and I came back to the PC and starting working on it. After it woke up, sometimes, this problem occurred. It can of course be a hardware problem, but I never experienced this problem before, and I read that high precision scrolling is in the work in kernel/input stack for Logitech mice. Perhaps this can be related? I don't know how to debug this issue. Should I collect some info the next time this happens? Version-Release number of selected component (if applicable): Fedora 29 kernel-5.0.7-200.fc29.x86_64 libinput-1.12.6-1.fc29.x86_64 Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver Logitech M720 (connected via usb dongle) How reproducible: rarely Steps to Reproduce: 1. let your pc go idle, monitor go off 2. wake up the pc 3. sometimes the scroll wheel is slowed enourmously 4. turn the mouse off and on to fix it //Update: There's a workaround described in comment 67.
This is likely a kernel bug. Since kernel v5.0, we enabled the high-resolution scrolling capability of the mouse. This will allow libinput and gnome to provide smooth scrolling. However, the setting is not persistent. Whenever the mouse goes to sleep to save battery, the setting is reverted. The kernel is supposed to resend the setting when the mouse comes back, but it seems it doesn't from time to time. The question is now whether the kernel doesn't see the "connect" event from the mouse or if the kernel fails at sending the parameter to the mouse.
I just saw this again during working on PC, but haven't touched the mouse for some time (so it went to sleep). I noticed that every time the mouse reconnects, I see this in system journal: Apr 20 11:22:48 titan kernel: logitech-hidpp-device 0003:046D:405E.0006: multiplier = 8 And I verified that my scroll wheel is exactly 8x slower (I had to scroll 8 notches on the wheel to see one scroll event in the gnome-terminal).
Same issue here with a Logitech Performance MX mouse. A workaround seems to be to use Solaar to turn on "Smooth Scrolling", which restores the correct scrolling operation.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora 29 has now been rebased to 5.2.9-100.fc29. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 30, and are still experiencing this issue, please change the version to Fedora 30. If you experience different issues, please open a new bug report for those.
Still happening with kernel-5.2.9-200.fc30.x86_64.
I'm seeing this too on my M705. After a fresh boot I have to click the button that allows the wheel to spin fast & freely to have anything approaching a proper scrolling experience. I've googled all I know how to but is there not a way to override the kernel here?
Hi, I have a Logitech M125 mouse - and this has happened a few times, and more specifically, quite a lot today. The problem today was worse for scrolling down, than scrolling up. I checked the mouse with Windows 8.1 and no issues. After plugging the mouse back into the laptop, the issue is resolved. Other mice work ok with Fedora 30. The mouse is plugged in at boot time. As such, if this occurs, you may wish to disconnect the mouse, and reconnect to see if it resolves. Regards, Shadders.
This has to do with high resolution scrolling. If you run solaar you can disable it and it seems to be persistent for me.
Yes, this is also still happening for me with kernel-5.3.9-200.fc30 and Logitech M720 mouse.
I have been seeing this issue for quite some time now with my Logitech Anywhere MX mouse. Kernel: 5.3.11-200
This is the "hack" I use to make the mouse usable with Fedora 29 and 30: 1. Determine the device number of your "affected" mouse using `solaar show`: $ solaar show Unifying Receiver Device path : /dev/hidraw0 USB id : 046d:c52b ... 1: Wireless Illuminated Keyboard K800 Codename : K800 Kind : keyboard ... 2: Anywhere Mouse MX Codename : Anywhere MX Kind : mouse ... In my case, it is device 2. 2. Update the value for _DEVICE_ID in the following command-line and then execute it: _DEVICE_ID=2; \ while true; do \ if ! solaar config $_DEVICE_ID | grep -qE '^\s*smooth-scroll\s*=\s*True\s*$'; then \ solaar config $_DEVICE_ID smooth-scroll True; \ fi; \ sleep 20; \ done The command will run in a loop until you break out of it (CTRL+C, log out, shutdown, etc). It will first check to see if solaar returns True for the smooth-scroll property of your specified device. If it does not or if the command fails, it will then attempt to set smooth-scroll to True. It finally sleeps for 20 seconds. The major drawback to this hack is that if the sleep interval is too short, it prevents the mouse from sleeping. If the interval is long enough to allow the mouse to sleep, it could mean that you have bad scrolling for a period up to the interval once the mouse wakes up. It seems a 20 second sleep works well for me as it allows the mouse to sleep eventually while keeping the unbearable scroll issue mostly under control. And, as others point out, switching the mouse off and back on will also serve as a good workaround. But I do find that I have to do this many times an hour so my script makes it less annoying.
Turns out that solaar can try to guess the device you want so here is my updated command wrapped by a function I stuck in my .bashrc and that I can either execute manually or, is one so desires, could be executed in the background at login. function hack_bz_1701322() { _sleep_interval=25 if [ $# -gt 0 ]; then _DEVICE="$1" else _DEVICE="mouse" fi while true; do if ! solaar config "$_DEVICE" | grep -qE '^\s*smooth-scroll\s*=\s*True\s*$'; then solaar config "$_DEVICE" smooth-scroll True fi sleep "$_sleep_interval" done } However, the underlying issue that is causing this needs to be properly diagnosed and fixed. At the moment, this issue has added the unintended feature of the mouse randomly turning into a flying projectile.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs. Fedora 30 has now been rebased to 5.5.7-100.fc30. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31. If you experience different issues, please open a new bug report for those.
I still get this, in Fedora 31. I've installed Solaar and configured it to autostart, but sometimes the issue still occurs and I have to reset the switch in Solaar.
Yes, still happening even for me with kernel-5.5.7-200.fc31.x86_64.
I have had this issue with a Logitech M720 ever since upgrading to kernel 5 over a year ago. Still happening with 5.6.12-300.fc32.x86_64 on Fedora 32. The Solaar workaround mostly works, but sometimes I still need to manually toggle OFF/ON the mouse's power button or Solaar's Wheel Resolution option. As mentioned in comment #2, I also occasionally see system journal messages with "multiplier = 8"
Just chiming in to confirm this happens to me as well. Kernel 5.6.11-200.fc31.x86_64. To recover I yank out my USB receiver and put it back. Looking over my dmesg, I see lots of this last line regarding 'multiplier' occurring after I resume from laptop sleep, eg. [113023.176476] logitech-hidpp-device 0003:046D:406D.0011: multiplier = 8
This issue still occurs in Fedora 32 (5.6.15-300.fc32.x86_64), with Logitech M705 mouse.
Since this appears to be a kernel bug, does anyone have the upstream bug number so we can tell if there's actually any progress being made on this? If not, what's the best description of the problem to give them so they can track it down quickly?
For anyone else that comes across this Solaar has an option to reissue the settings on wake-up, but it need to be passed as a flag when starting solaar: https://github.com/pwr-Solaar/Solaar/issues/443
Hi, Using a Logitech M125 mouse - kernel is 5.7.15, and single mouse button clicks are sometimes registering a double mouse button clicks. Only started the past week or so. Cannot determine if any specific update has caused this - laptop used is Dell Inspiron 17, 5000 series. Regards, Shadders.
Shadders, that's an unrelated issue, so please file a separate bug for it. Second, this is very often a hardware issue, all my Logitech mice end up this way - their switches are of poor quality. So test with previous kernels where it worked fine for you (for a longer time, so that you can be sure) or use a different OS for a while. Only file the new issue when you're certain it's not a hardware issue. Thanks.
Shadders, you're experiencing this issue only if you see the "multiplier = 8" message in your kernel logs. Secondly, I know this is OT, but as opposed to Kamil, generally my Logitech mice have been very good to me hardware-wise over many years. I did have one mouse that started exhibiting weird switch behaviors due to hardware, but it was quite simple to open it up, clean all the contacts with alcohol, and put it back together again, for another several years of trouble-free operation.
Hi, Thanks for the guidance - apologies for the late reply. I changed mouse a week ago, since no error messages in journalctl, and no issues so far. Regards, Shadders.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
It's possibly still an issue on Fedora 33 (5.8.16-300.fc33.x86_64) with a Logitech MX Master 2S. After a reboot everything is back to normal. It's the first time the issue occurred & it never happened on Fedora 31 or 32. In my case I was watching a fullscreen video in Firefox. There are some libinput messages in the log, there are multiple entries of this kind: Nov 03 18:15:25 min gnome-shell[2776]: libinput error: client bug: timer event6 debounce: scheduled expiry is in the past (-4ms), your system is too slow Nov 03 18:15:25 min gnome-shell[2776]: libinput error: client bug: timer event6 debounce short: scheduled expiry is in the past (-17ms), your system is too slow Nov 03 18:16:23 min gnome-shell[2776]: libinput error: client bug: timer event6 debounce short: scheduled expiry is in the past (-5ms), your system is too slow Nov 03 18:17:02 min gnome-shell[2776]: libinput error: event6 - Logitech MX Master 2S: client bug: event processing lagging behind by 12ms, your system is too slow Nov 03 18:17:11 min gnome-shell[2776]: libinput error: event6 - Logitech MX Master 2S: client bug: event processing lagging behind by 27ms, your system is too slow Nov 03 18:17:13 min gnome-shell[2776]: libinput error: event6 - Logitech MX Master 2S: client bug: event processing lagging behind by 11ms, your system is too slow Nov 03 18:17:29 min gnome-shell[2776]: libinput error: client bug: timer event6 debounce: scheduled expiry is in the past (-7ms), your system is too slow Nov 03 18:17:29 min gnome-shell[2776]: libinput error: client bug: timer event6 debounce short: scheduled expiry is in the past (-20ms), your system is too slow
The issue is still present for my Logitech M720 on Fedora 33. kernel 5.8.17-300.fc33.x86_64
(In reply to thedatum+bz from comment #27) > The issue is still present for my Logitech M720 on Fedora 33. kernel > 5.8.17-300.fc33.x86_64 Yes, I can confirm that.
I haven't got a logitech and present the same issue: Bus 003 Device 002: ID 10c4:8105 Silicon Labs USB OPTICAL MOUSE dic 05 13:44:22 hhlp gnome-shell[1832]: libinput error: event3 - YSPRINGTECH USB OPTICAL MOUSE: client bug: event processing lagging behind by 11ms, your system is too slow dic 05 13:47:08 hhlp gnome-shell[1832]: libinput error: event2 - AT Translated Set 2 keyboard: client bug: event processing lagging behind by 22ms, your system is too slow 5.9.12-200.fc33.x86_64 Regards.,
*** Bug 1902671 has been marked as a duplicate of this bug. ***
because I can not see any video and my desktop freezes and I have to reset again, I did the following until this will be fixed: I've got a stable desktop for almost 36 hours... 1. goto koji 2. search by kernel 3. search an old kernel I select 5.6.14.100 form f30 4. verify which kernel you had installed with rpm -qa kernel\* 5. download it from koji 6. modify /etc/dnf.conf to limited=4 7. install it 8. with dnf versionlock plugin lock this kernel to ensure the desktop boot in this kernel every time without select it 9 done 10. wait # Note The message is still there but whithout freezing... Regards.,
I've seen this slow-scroll problem for the first time ever. I'm using Fedora 33 at the moment. My hardware is an AMD 3950X with 64 GB of RAM. Logitech MX Anywhere 2S, plugged into a USB HUB. Here are some journalctl errors: Feb 19 15:22:48 enoch gnome-shell[2481]: libinput error: client bug: timer event10 debounce: scheduled expiry is in the past (-5ms), your system is too slow Feb 19 15:22:48 enoch gnome-shell[2481]: libinput error: client bug: timer event10 debounce short: scheduled expiry is in the past (-18ms), your system is too slow Feb 19 15:24:56 enoch gnome-shell[2481]: libinput error: client bug: timer event10 debounce short: scheduled expiry is in the past (-7ms), your system is too slow Feb 19 15:26:06 enoch gnome-shell[2481]: libinput error: client bug: timer event10 debounce: scheduled expiry is in the past (-5ms), your system is too slow Feb 19 15:26:06 enoch gnome-shell[2481]: libinput error: client bug: timer event10 debounce short: scheduled expiry is in the past (-18ms), your system is too slow Feb 19 15:30:54 enoch gnome-shell[2481]: libinput error: client bug: timer event10 debounce short: scheduled expiry is in the past (-8ms), your system is too slow Feb 19 15:31:05 enoch gnome-shell[2481]: libinput error: event10 - Logitech MX Anywhere 2S: client bug: event processing lagging behind by 12ms, your system is too slow Feb 19 15:31:37 enoch gnome-shell[2481]: libinput error: client bug: timer event10 debounce short: scheduled expiry is in the past (-2ms), your system is too slow Feb 19 15:33:09 enoch gnome-shell[2481]: libinput error: client bug: timer event10 debounce short: scheduled expiry is in the past (-1ms), your system is too slow Feb 19 15:35:46 enoch gnome-shell[2481]: libinput error: event10 - Logitech MX Anywhere 2S: client bug: event processing lagging behind by 33ms, your system is too slow Feb 19 15:38:16 enoch gnome-shell[2481]: libinput error: event10 - Logitech MX Anywhere 2S: client bug: event processing lagging behind by 31ms, your system is too slow Feb 19 15:42:01 enoch gnome-shell[2481]: libinput error: client bug: timer event10 debounce short: scheduled expiry is in the past (-6ms), your system is too slow Feb 19 15:42:46 enoch gnome-shell[2481]: libinput error: event10 - Logitech MX Anywhere 2S: client bug: event processing lagging behind by 13ms, your system is too slow Feb 19 15:43:02 enoch gnome-shell[2481]: libinput error: event10 - Logitech MX Anywhere 2S: client bug: event processing lagging behind by 15ms, your system is too slow Feb 19 15:43:02 enoch gnome-shell[2481]: libinput error: event10 - Logitech MX Anywhere 2S: WARNING: log rate limit exceeded (5 msgs per 60min). Discarding future messages.
Oh by the way, I'm using kernel 5.10.15-200.fc33.x86_64.
Similar issues here with a Logitech MX Anywhere 2S Usually, scroll wheel speed is fine. But if I put the computer to sleep, then after resuming, I'd say 1 out of 10 times scroll wheel is slow. Unplugging / replugging the Unified Receiver or power cycling the mouse fixes it. This has been going for some time, since I started using sleep/resume a month or two ago. My current kernel version is: kernel-core-5.12.13-300.fc34.x86_64 Other HW info: Intel i7 9700K (not overclocked), ASUS PRIME Z390-A motherboard, plenty of RAM, SSD's.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still happens in Fedora 35 with kernel 5.14.16-301.fc35.x86_64
I haven't seen this problem for a long while now, since I reported it in February of 2021. I'm on Fedora 34 now, kernel 5.14.14-200.fc34.x86_64.
This issue still occurs regularly for me even with Fedora 34 and kernel 5.14.14-200.fc34.x86_64. Ever since kernel 5.x. It doesn't look like this will be resolved from Fedora's end, but needs to be addressed from the kernel side.
It occurs regularly to me as well (Fedora 35, kernel 5.14.16 at the moment).
I added a link to this bug in the kernel tracker: https://bugzilla.kernel.org/show_bug.cgi?id=203421
Based on conversations with a user who has similar hardware (Logitech mouse) it appears that the problem occurs when the linux/drivers/hid/hid-logitech-hidpp.c driver can't determine the wheel multiplier. Look for system log messages like: logitech-hidpp-device 0003:046D:XXXX.YYYY: Couldn't get wheel multiplier (error -110) This appears to be the result of a timeout when trying to find the wheel multiplier from the Logitech HID++ feature HIRES_WHEEL (0x2121). The question is why the timeout occurs. It is particularly odd that this call times out because the code appears to first set the wheel to high resolution and only then try to find out the multiplier. This unusual order may be an attempt to not be too affected if the device is not responding. This appears to be different from the first problem in https://bugzilla.kernel.org/show_bug.cgi?id=203421 where the scroll wheel stops working. It might be a good idea to file a separate kernel bug directly concerning the wheel multiplier issue. The bug report should include part of the system log with any appropriate messages.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
This issue is still present on Fedora 36 and kernel 6.0.11
I have experienced this on Fedora 37 as well. I don’t think I have encountered it yet on kernel 6.0.12, but it did happen on 6.0.11. Mouse: Logitech M705
I still have this issue on Fedora 37. Interestingly, I no longer see the `multiplier = 8` messages in the logs.
Similarly, I haven't seen the `multiplier = 8` message in quite some time. However, as mentioned in comment #43 a message that has been showing up occasionally over at least the past year is: logitech-hidpp-device 0003:046D:405E.0006: Couldn't get wheel multiplier (error -110)
The driver behind all this is at https://github.com/torvalds/linux/blob/master/drivers/hid/hid-logitech-hidpp.c In the code there is hid_dbg(hidpp->hid_dev, "wheel multiplier = %d\n", multiplier); which indicates that the message is only emitted when some debug flag is set. I believe that some Fedora kernels a few releases ago had some debug flag set, but that no recent ones except maybe for pre-release kernels have debug flag sets. The question is why you are occasionally getting the errors. I have an MX Master 3 and it has the same feature that the M720 has but I have never had this problem. It may just be that the M720 has a firmware glitch that causes it to occasionally respond with an error response. The way to check would be to turn on debugging (hid_dbg and dbg_hid), but I have no idea how this is done and you may even need a kernel with this enabled.
Solaar has a setting that modifies the same mouse feature that the driver uses for smooth scrolling. The driver and Solaar will both try to modify the feature, resulting in a race condition. If you are running Solaar you should change its Scroll Wheel Resolution setting to "Ignore this setting" by clicking the little lock icon for the setting.
> I believe that some Fedora kernels a few releases ago had some debug flag set, but that no recent ones except maybe for pre-release kernels have debug flag sets. I don't believe its because Fedora kernels had the debug flag set -- I believe its because the kernel used to log this at info level (and without the "wheel" part, which matches earlier reports): https://github.com/torvalds/linux/commit/e13762abf38ead29071407f32b9dcec38f21dc34. > logitech-hidpp-device 0003:046D:405E.0006: Couldn't get wheel multiplier (error -110) Just as a counterpoint, I *don't* see this message. The wheel mouse just gets slow, seemingly randomly. > Solaar has a setting that modifies the same mouse feature that the driver uses for smooth scrolling. The driver and Solaar will both try to modify the feature, resulting in a race condition. If you are running Solaar you should change its Scroll Wheel Resolution setting to "Ignore this setting" by clicking the little lock icon for the setting. The only reason I use Solaar is to work around this bug in the first place :-) By clicking that setting off and on, I can reset the scroll speed. Are you saying that the race with Solaar is now the cause of the issue? I've locked that setting out on Solaar now.
If you only use "solaar config ..." to modify device behaviour then there should be no race condition. If, however, you have Solaar running continuously so that it can restore changes you have made each time the device becomes active then there is the possibility of a race condition because both Solaar and the hidpp driver can change the high resolution bit of the HIRES WHEEL feature. The last change is the one that wins. So, as mentioned in the Solaar documentation, it is a good idea to set the Scroll Wheel Resolution to ignore. The setting is still around for those who need it.
> > logitech-hidpp-device 0003:046D:405E.0006: Couldn't get wheel multiplier (error -110) > > Just as a counterpoint, I *don't* see this message. The wheel mouse just > gets slow, seemingly randomly. To clarify, the issue occurs much more frequently than that message appears. Also, I'm not sure that the issue and that message occur simultaneously.
I have Solaar running continuously, and had set it to ignore "Scroll Wheel Resolution" back in December when Peter suggested it was causing race conditions. However, today I encountered the issue again. I checked Solaar, and "Scroll Wheel Resolution" was still set to ignored. So I’m not sure if the problem actually has anything to do with Solaar. Just in case: I’m currently using Solaar 1.1.8 and Linux 6.0.18.
I don't have Solaar on my system and this problem still happens. Solaar is not the cause.
I am having similar problems after upgrading from fedora 36 to 38. Sometimes the scroll wheel is faster than usual, sometimes it slows down to a crawl (usually after suspend/resume). This has persisted through the different kernel upgrades. I am using a logitech M705 and solaar is not installed on my system.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Still happens occasionally for me. I am running 6.7.9-200.fc39.x86_64 with a MX Master 3 over Bluetooth. Pushing the button on the bottom to cycle the signal through "1", "2", "3" and back to "1" fixes it.
I'm getting this issue after upgrading to FC40. My mouse will start scrolling at about 1/4 speed after my computer sits for a while, or after a suspend. I have to restart to fix it. MX Master 3. It didn't happen on FC39 for me, but now happens on FC40.
eric, try re-plugging the mouse instead of rebooting the whole pc. Not ideal, but should be enough to fix it. I can confirm this also with F40. Happens also over Bluetooth, and quite frequently. Cycling though input sources on my M720 fortunately resolves this issue (I guess that's an equivalent to re-plugging it physically).
I found the restarting the bluetooth service fixes the issue. Cycling through the mouse inputs, or restarting the mouse doesn't fix the issue for me. Someone in another forum said that there was a bluez update to FC38, 39, and 40 and that many users are seeing this issue. So it may be a newly introduced issue.
Just a note, here's a long ticket about this bug now affecting bluetooth connection as well: https://github.com/bluez/bluez/issues/778
I started experiencing the issue on Fedora 39 with a Logitech MX Anywhere 3 after the upgrade of the following: Upgrade bluez-5.73-3.fc39.x86_64 @updates Upgraded bluez-5.72-1.fc39.x86_64 @@System Upgrade bluez-cups-5.73-3.fc39.x86_64 @updates Upgraded bluez-cups-5.72-1.fc39.x86_64 @@System Upgrade bluez-libs-5.73-3.fc39.x86_64 @updates Upgraded bluez-libs-5.72-1.fc39.x86_64 @@System Upgrade bluez-obexd-5.73-3.fc39.x86_64 @updates Upgraded bluez-obexd-5.72-1.fc39.x86_64 @@System When the machine resume from s2idle, the wheel scrolling is super slow or even unresponsive. The only two fixes are: - disable/re-enable the Bluetooth; - modprobe -r hid_logitech_hidpp && modprobe hid_logitech_hidpp I don't blame the kernel here, I've been using 6.8.1 for a while before Fedora switched to 6.8.4 and I've never had any issues. The problem started after the upgrade of bluez-5.73-3 :/
Let's keep this bug related to the long-term issue with USB dongle connection, and discuss the recent bluez regression in the upstream ticket, see comment 63. It might, or might not be the same underlying issue. There's a very insightful comment from the Solaar maintainer there [1]. [1] https://github.com/bluez/bluez/issues/778#issuecomment-2042923166
Oh my. It's been five years. Since then I've - Changed my mouse - Moved to a different country across the world - Got a new job - Use MacOS for work - Stopped using Fedora for my personal computing needs and the bug is still there...
Thanks to comment 64, I can confirm that this problem is somehow related to hid_logitech_hidpp kernel module. But even without that module, my mouse still works completely fine (I found no drawbacks), and avoids this bug(!). So my current workaround is to blacklist hid_logitech_hidpp completely. Since I've done that, I haven't seen the issue again. The workaround: 1. Create /etc/modprobe.d/logitech-workaround.conf with this content: # A workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1701322 blacklist hid_logitech_hidpp 2. Run "sudo dracut -f" 3. Reboot
bluez 5.75 should fix the more recent issue. I doubt it helps with the dongle one, though it's curious that the same workaround helps.
I also see this issue sometimes. I'm not using Bluetooth, but the Logitech wireless connection (I do not know the name). Removing the receiver and plugging it back in into the computer solves the issue. The issue happens mainly after resume from suspend. See also: https://github.com/pwr-Solaar/Solaar/issues/951
(In reply to Kamil Páral from comment #67) > Thanks to comment 64, I can confirm that this problem is somehow related to > hid_logitech_hidpp kernel module. But even without that module, my mouse > still works completely fine (I found no drawbacks), and avoids this bug(!). > So my current workaround is to blacklist hid_logitech_hidpp completely. > Since I've done that, I haven't seen the issue again. > > The workaround: > 1. Create /etc/modprobe.d/logitech-workaround.conf with this content: > # A workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1701322 > blacklist hid_logitech_hidpp > 2. Run "sudo dracut -f" > 3. Reboot This is an interesting workaround. Since applying it, I have not noticed the issue reoccur so far. However, there is a drawback, in that the battery level indicator and low battery warnings no longer work in software. With hid_logitech_hidpp blacklisted, the logitech devices are no longer listed within MATE's Power Manager notification icon. It would be interesting to know whether this is the case with other Desktop Environments as well.