Bug 1701322 - scroll wheel sometimes extremely slow on Logitech M720
Summary: scroll wheel sometimes extremely slow on Logitech M720
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 39
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1902671 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-18 15:39 UTC by Kamil Páral
Modified: 2024-03-13 12:13 UTC (History)
43 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-12-13 15:12:58 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Kamil Páral 2019-04-18 15:39:20 UTC
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

Comment 1 Benjamin Tissoires 2019-04-19 09:36:27 UTC
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.

Comment 2 Kamil Páral 2019-04-20 09:27:49 UTC
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).

Comment 3 Raman Gupta 2019-05-22 13:08:04 UTC
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.

Comment 4 Justin M. Forbes 2019-08-20 17:45:05 UTC
*********** 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.

Comment 5 Kamil Páral 2019-08-21 09:50:04 UTC
Still happening with kernel-5.2.9-200.fc30.x86_64.

Comment 6 Richard Shaw 2019-10-22 02:05:05 UTC
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?

Comment 7 Shadders 2019-11-12 22:19:38 UTC
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.

Comment 8 Richard Shaw 2019-11-12 22:22:16 UTC
This has to do with high resolution scrolling. If you run solaar you can disable it and it seems to be persistent for me.

Comment 9 Kamil Páral 2019-11-13 12:27:57 UTC
Yes, this is also still happening for me with kernel-5.3.9-200.fc30 and Logitech M720 mouse.

Comment 10 Larry O'Leary 2019-11-21 15:28:30 UTC
I have been seeing this issue for quite some time now with my Logitech Anywhere MX mouse.

Kernel: 5.3.11-200

Comment 11 Larry O'Leary 2019-11-22 15:52:47 UTC
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.

Comment 12 Larry O'Leary 2019-11-22 17:00:34 UTC
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.

Comment 13 Justin M. Forbes 2020-03-03 16:36:01 UTC
*********** 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.

Comment 14 Ricardo Silva Veloso 2020-03-06 23:19:31 UTC
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.

Comment 15 Kamil Páral 2020-03-07 20:06:12 UTC
Yes, still happening even for me with kernel-5.5.7-200.fc31.x86_64.

Comment 16 thedatum+bz 2020-05-17 03:56:14 UTC
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"

Comment 17 pllauria 2020-05-21 02:37:45 UTC
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

Comment 18 brad.williams 2020-06-05 16:39:50 UTC
This issue still occurs in Fedora 32 (5.6.15-300.fc32.x86_64), with Logitech M705 mouse.

Comment 19 Mike Auty 2020-08-24 13:42:36 UTC
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?

Comment 20 Mike Auty 2020-08-24 13:58:04 UTC
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

Comment 21 Shadders 2020-09-08 17:31:49 UTC
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.

Comment 22 Kamil Páral 2020-09-10 13:32:58 UTC
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.

Comment 23 Raman Gupta 2020-09-10 13:53:33 UTC
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.

Comment 24 Shadders 2020-09-26 20:39:59 UTC
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.

Comment 25 Ben Cotton 2020-11-03 16:52:10 UTC
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.

Comment 26 Martin Pilarski 2020-11-03 17:42:44 UTC
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

Comment 27 thedatum+bz 2020-11-03 23:00:52 UTC
The issue is still present for my Logitech M720 on Fedora 33. kernel 5.8.17-300.fc33.x86_64

Comment 28 Kamil Páral 2020-11-04 13:18:01 UTC
(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.

Comment 29 Héctor Louzao 2020-12-05 14:21:08 UTC
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.,

Comment 30 Héctor Louzao 2020-12-16 11:57:38 UTC
*** Bug 1902671 has been marked as a duplicate of this bug. ***

Comment 31 Héctor Louzao 2020-12-16 12:05:20 UTC
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.,

Comment 32 Bruce Bigby 2021-02-19 20:49:56 UTC
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.

Comment 33 Bruce Bigby 2021-02-19 20:51:35 UTC
Oh by the way, I'm using kernel 5.10.15-200.fc33.x86_64.

Comment 34 Kostya Vasilyev 2021-06-30 18:50:54 UTC
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.

Comment 35 Ben Cotton 2021-11-04 13:44:24 UTC
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.

Comment 36 Ben Cotton 2021-11-04 14:13:54 UTC
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.

Comment 37 Ben Cotton 2021-11-04 15:11:31 UTC
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.

Comment 38 Kostya Vasilyev 2021-11-06 10:41:26 UTC
Still happens in Fedora 35 with kernel 5.14.16-301.fc35.x86_64

Comment 39 Bruce Bigby 2021-11-08 22:36:19 UTC
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.

Comment 40 thedatum+bz 2021-11-08 23:59:41 UTC
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.

Comment 41 Kamil Páral 2021-11-09 09:08:56 UTC
It occurs regularly to me as well (Fedora 35, kernel 5.14.16 at the moment).

Comment 42 Kostya Vasilyev 2021-11-09 11:56:18 UTC
I added a link to this bug in the kernel tracker:

https://bugzilla.kernel.org/show_bug.cgi?id=203421

Comment 43 Peter F. Patel-Schneider 2022-03-14 13:00:42 UTC
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.

Comment 44 Ben Cotton 2022-11-29 16:46:11 UTC
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.

Comment 45 Ben Cotton 2022-12-13 15:12:58 UTC
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.

Comment 46 thedatum+bz 2022-12-14 04:25:48 UTC
This issue is still present on Fedora 36 and kernel 6.0.11

Comment 47 andoryuuhonmono 2022-12-14 14:20:10 UTC
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

Comment 48 Raman Gupta 2022-12-21 18:26:11 UTC
I still have this issue on Fedora 37. Interestingly, I no longer see the `multiplier = 8` messages in the logs.

Comment 49 thedatum+bz 2022-12-21 18:59:28 UTC
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)

Comment 50 Peter F. Patel-Schneider 2022-12-21 20:49:26 UTC
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.

Comment 51 Peter F. Patel-Schneider 2022-12-21 21:02:23 UTC
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.

Comment 52 Raman Gupta 2022-12-21 21:14:44 UTC
> 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.

Comment 53 Peter F. Patel-Schneider 2022-12-21 22:26:38 UTC
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.

Comment 54 thedatum+bz 2022-12-22 00:12:23 UTC
> > 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.

Comment 55 andoryuuhonmono 2023-01-15 22:21:58 UTC
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.

Comment 56 Kamil Páral 2023-01-16 09:18:53 UTC
I don't have Solaar on my system and this problem still happens. Solaar is not the cause.

Comment 57 Rutger Noot 2023-06-10 13:21:05 UTC
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.

Comment 58 Aoife Moloney 2023-11-23 00:02:09 UTC
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.

Comment 59 Ken Dreyer 2024-03-13 12:13:21 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.