You are not logged in.
I have a Logitec wireless keyboard and mouse connected to a Logitec unifying receiver plugged into a normal USB port. As a whole it works very well but I've noticed every time I reboot, both keyboard and mouse starts having a really noticeable lag in response. The only way I could get the normal response back is by unplugging and plugging the USB receiver live online.
Is there a way to fix this? I am suspecting a bus issue but not entirely sure how to proceed. Any help will be appreciated.
Last edited by d_fajardo (2022-12-28 12:37:00)
Offline
please check https://wiki.archlinux.org/title/Logite … ess_device
Offline
Mine needs to be about 1200mm or less from the dongle or else a delay or intermittent. It also plays up (only sometimes) if there is another wireless mouse nearby.
Offline
I tried various ways but the problem persist. A few things are clear however:
The lag happens only happens on reboot. If I put computer to sleep, the mouse responds just fine on wakeup.
It's not really a lag but more like a delay. After booting, I end with my KDE environment. If I don't use the mouse for 5 seconds, then there's a delay restarting it to move. However once moving, as long as that 5 seconds of inactivity has not been violated, the mouse functions normally.
The only way to remove the delay is by unplugging and plugging back in the unifying device
Question, is it possible to create a udev rule to simulate unplugging and plugging back in of devices?
I also have a feeling this might be Solaar issue. I tried the git version but no change.
Offline
If I don't use the mouse for 5 seconds, then there's a delay restarting it to move. However once moving, as long as that 5 seconds of inactivity has not been violated, the mouse functions normally.
That's gonna be USB autosuspend for 99.9999% sure. The device might even respond badly to a single occurrence.
https://wiki.archlinux.org/title/Power_ … utosuspend
Offline
I tried various ways but the problem persist. A few things are clear however:
The lag happens only happens on reboot. If I put computer to sleep, the mouse responds just fine on wakeup.
It's not really a lag but more like a delay. After booting, I end with my KDE environment. If I don't use the mouse for 5 seconds, then there's a delay restarting it to move. However once moving, as long as that 5 seconds of inactivity has not been violated, the mouse functions normally.
The only way to remove the delay is by unplugging and plugging back in the unifying device
Question, is it possible to create a udev rule to simulate unplugging and plugging back in of devices?
I also have a feeling this might be Solaar issue. I tried the git version but no change.
Had same problem after installed power manager app PowerTop, your pc just power saving. And I can tell what after installing kernel 6.1.1 got problems too with logitech receiver ( scroll wheel was skipping scrolls in some apps like firefox). Installed LTS kernel fixed this too.
Last edited by Gytis (2022-12-26 17:04:23)
Offline
"LTS" and merely installing powertop in and by itself won't do anything on archlinux.
Offline
"LTS" and merely installing powertop in and by itself won't do anything on archlinux.
What?
Offline
"merely installing powertop in and by itself won't do anything on archlinux" - there's an autotune feature, but the package doesn't bring any service to activate it. Installing powertop just makes ouy have the powertop binary on your disk.
And you fixed "LTE" to "LTS" in your edit.
Offline
First: I was enabled powertop service, maybe OP has something similar enabled. This was made 100% same issues what OP are saying.
Second: kernel was different thing, I just saying 6.1.1 kernel somehow can't work correctly with Logitech mouse, because scroll wheel become buggy.
Offline
The arch powertop package doesn't ship a service you could enable.
Edit: Also that's not what you orginally claimed:
Had same problem after installed power manager app PowerTop
I assume you're using some arch derivate?
Last edited by seth (2022-12-26 22:00:46)
Offline
The arch powertop package doesn't ship a service you could enable.
Edit: Also that's not what you orginally claimed:
Had same problem after installed power manager app PowerTop
I assume you're using some arch derivate?
You wrong
https://wiki.archlinux.org/title/powert … y_settings
Last edited by Gytis (2022-12-27 05:07:05)
Offline
No I'm not, but I'll give you the benefit of the doubt that you essentially don't speak english.
The wiki article you linked explains how to add a auto-tune service because the package doesn't ship one
You have to actively do that.
merely installing powertop in and by itself won't do anything on archlinux.
Offline
No I'm not, but I'll give you the benefit of the doubt that you essentially don't speak english.
The wiki article you linked explains how to add a auto-tune service because the package doesn't ship one
You have to actively do that.seth wrote:merely installing powertop in and by itself won't do anything on archlinux.
Idk how you look, but creating this file it's same as enabling it. Powertop support it, it just install didn't create this file.
Offline
Powertop support it, it just install didn't create this file.
merely installing powertop in and by itself won't do anything on archlinux.
I'll give you the benefit of the doubt that you essentially don't speak english.
Offline
Thank you both for your lead. Uninstalling powertop solves the problem.
Offline
Did you auto-tune it or just use it to alter usb autosuspending?
Excluding the receiver in the auto-tune autosuspend settings will most likely suffice.
Offline
Did you auto-tune it or just use it to alter usb autosuspending?
Excluding the receiver in the auto-tune autosuspend settings will most likely suffice.
I'll give that a go. Thanks.
Edit: I simply uninstalled it.
Last edited by d_fajardo (2022-12-28 15:23:11)
Offline
Edit: I simply uninstalled it.
No, I meant whether you added the auto-tune service (ie. how do you trigger this w/ powertop)
https://github.com/fenrus75/powertop/issues/38
https://archlinux.org/packages/community/any/tlp/ might be a more comfortable alternative (though the same issue applies wrt the autosuspend condition)
iirc last time I was facing this I basically ran --auto-tune and then reset the value for the problematic device via sysfs manually.
Offline