(II) event14 - Logitech USB Headset Logitech USB Headset: is tagged by udev as: Keyboard (**) Option "Device" "/dev/input/event14" (**) Logitech USB Headset Logitech USB Headset: always reports core events (II) systemd-logind: got fd for /dev/input/event14 13:78 fd 81 paused 0
#Logitech mouse lagging driver#
(II) Using input driver 'libinput' for 'Logitech USB Headset Logitech USB Headset' (**) Logitech USB Headset Logitech USB Headset: Applying InputClass "system-keyboard" (**) Logitech USB Headset Logitech USB Headset: Applying InputClass "libinput keyboard catchall" (**) Logitech USB Headset Logitech USB Headset: Applying InputClass "evdev keyboard catchall" (II) config/udev: Adding input device Logitech USB Headset Logitech USB Headset (/dev/input/event14) (EE) event3 - Logitech MX Master 3: client bug: event processing lagging behind by 15ms, your system is too slow (EE) client bug: timer event3 debounce short: scheduled expiry is in the past (-13ms), your system is too slow (EE) client bug: timer event3 debounce: scheduled expiry is in the past (-0ms), your system is too slow (EE) event2 - Logitech MX Keys: client bug: event processing lagging behind by 26ms, your system is too slow (EE) event2 - Logitech MX Keys: client bug: event processing lagging behind by 28ms, your system is too slow (EE) client bug: timer event3 debounce short: scheduled expiry is in the past (-11ms), your system is too slow (EE) client bug: timer event3 debounce short: scheduled expiry is in the past (-12ms), your system is too slow (EE) event3 - Logitech MX Master 3: WARNING: log rate limit exceeded (5 msgs per 60s). (EE) event3 - Logitech MX Master 3: client bug: event processing lagging behind by 12ms, your system is too slow (EE) client bug: timer event3 debounce short: scheduled expiry is in the past (-18ms), your system is too slow (EE) client bug: timer event3 debounce: scheduled expiry is in the past (-5ms), your system is too slow (EE) event3 - Logitech MX Master 3: client bug: event processing lagging behind by 32ms, your system is too slow (EE) event3 - Logitech MX Master 3: client bug: event processing lagging behind by 20ms, your system is too slow (EE) event3 - Logitech MX Master 3: client bug: event processing lagging behind by 26ms, your system is too slow (EE) event3 - Logitech MX Master 3: client bug: event processing lagging behind by 28ms, your system is too slow (EE) event2 - Logitech MX Keys: client bug: event processing lagging behind by 27ms, your system is too slow ↳ Logitech G903 Wired/Wireless Gaming Mouse id=17 ↳ Razer Razer BlackWidow Tournament Edition Chroma Consumer Control id=16
↳ Razer Razer BlackWidow Tournament Edition Chroma System Control id=11 ↳ Razer Razer BlackWidow Tournament Edition Chroma Keyboard id=9 ↳ Razer Razer BlackWidow Tournament Edition Chroma id=8 ⎜ ↳ Logitech G903 Wired/Wireless Gaming Mouse id=14 ⎜ ↳ Logitech Logitech G903 Wired/Wireless Gaming Mouse id=13 ⎜ ↳ Razer Razer BlackWidow Tournament Edition Chroma id=12 ⎜ ↳ Razer Razer BlackWidow Tournament Edition Chroma Consumer Control id=10 Nothing plugged in other than a yubi key, mouse, and keyboard. No Errors in Xorg.log other than the "mouse slow"/keyboard slow information. Right after rebooting, running nothing other than termite and i3 status, moving the mouse in quick circles can spike Xorg from ~2% to 50% of 1 CPU.
I've just added `drm_kms_helper.poll=0` to my boot entry, and while I haven't gotten the absurd-several-seconds-long lag since rebooting, moving the mouse in circles can spike firefox from <10% on a single CPU to 70%. I tried changing mouse poll to lower settings, but 1. xinitrc, no compositing, no power saving or screen locking etc save for i3status), screen, and a wired Logitech Logitech G903 Wired 1ms (1000hz) poll rate. I'm running a threadripper 1950X with a 2080ti, "raw" i3-wm (via startx and a barren. This has absolutely been happening to me too, glad I'm not alone. every few seconds, so presumably power-saving wouldn't kick in that rapidly. Also, when I experience the problem, I trigger it quickly, i.e. I would have thought if the mouse were power-saving and incapable of transmitting the signal, it would also be incapable of capturing the movement.
#Logitech mouse lagging software#
Having said that, if the initial mouse movement is "saved" and occurs a split second later, doesn't that suggest it's a software issue? If it's (hardware) auto-sleeping, then presumably that original movement would be lost. It's intermittent, and rare, which doesn't necessarily mean it's not a hardware issue, but it's certainly unclear! It's plausible however that this is a new problem with the mouse. I've had the mouse for a few years, and it's only exhibited this behaviour now, so I don't think it goes into power-saving mode by design.
Yes I guess that's plausible, but I'm suppose there's no way to tell for sure if it's a software or hardware problem.