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: 33
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: 2021-04-16 07:33 UTC (History)
35 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


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.


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