Late init of USB mouse

I'm not sure whether this is a problem or I'm just impatient.

My USB mouse takes quite long after a system startup. The session manager is up and asks for a login, I can do so using the keyboard and kwin initializes. Then it takes some more seconds and finally the mouse becomes responsive.
There is also a USB gamepad but xow is not installed so I may have a different problem than USB keyboard and mouse(s) took minute to start working on login. Solution here
I just unplugged the gamepad but there is no change.

[🔴] × journalctl | grep ^Okt\ 27 | grep 'Linux version 5.14.14-zen1-1-zen\|mouse'
Okt 27 18:36:54 garuda1 kernel: Linux version 5.14.14-zen1-1-zen ([email protected]) (gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #1 ZEN SMP PREEMPT Wed, 20 Oct 2021 21:35:17 +0000
Okt 27 18:37:07 garuda1 kcminit_startup[4254]: Initializing  "kcm_mouse" :  "kcminit_mouse"
Okt 27 18:37:26 garuda1 kernel: mousedev: PS/2 mouse device common for all mice
Okt 27 18:37:27 garuda1 kcminit[6035]: Initializing  "kcm_mouse" :  "kcminit_mouse"

You might want to check the Arch Wiki for adding early startup support for your bluetooth devices.

The Arch Wiki has much documentation regarding Bluetooth.

1 Like

There is another user having problems with bluetooth but in my case it's an off-the-shelf USB mouse. You know, the ones with a cable. :wink:

You must enable early startup for BT devices. The procedure is well documented on the Arch Wiki. Better yet, just divest yourself of bluetooth peripherals as they are nothing but trouble.

Buy yourself a Logitech mouse that uses their older unified receiver technology rather tban Bluetooth. I use a wireless Corsair keyboard as well, but I do not use their Bluetooth version. Just avoid buying Bluetooth if you want to use Linux and your life will be much simpler. Bluetooth is an inferior technology that most manufacturers do not provide adequate support for in Linux. Most companies only devote their resources to providing driver support for Windows.


As I mentioned before: The mouse I use a USB mouse with a cable. There is no bluetooth involved.

My apologies, I misread.

Try kernel change , use "linux-lts" kernel and check

Using the linux-lts does not change anything here. It still initializes the mouse very late in the start-up process.

Okt 30 08:13:51 garuda1 kcminit[1937429]: Initializing  "kcm_mouse" :  "kcminit_mouse"
Okt 30 08:38:06 garuda1 kernel: Linux version 5.10.75-1-lts ([email protected]) (gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP Wed, 20 Oct 2021 11:02:09 +0000
Okt 30 08:38:24 garuda1 kcminit_startup[4004]: Initializing  "kcm_mouse" :  "kcminit_mouse"
Okt 30 08:38:37 garuda1 kernel: mousedev: PS/2 mouse device common for all mice
Okt 30 08:38:38 garuda1 kcminit[5988]: Initializing  "kcm_mouse" :  "kcminit_mouse"

Have you tested an alternate mouse & alternate USB port.

1 Like

I only have USB mice but neither another one nor another port (another hub in the Linux USB config) changed anything. I'm pretty sure it's the order and timing of the initialization in either the systemd or KDE.
Just today I had another phenomenon: the USB mouse did not function when the PC woke up (I used the sleep function). That worked fine several times before and makes me think there is a timing maybe timeout issue.

The sleep issue sounds more like a power saving issue. I have a script that will refresh your mouses detection on the USB bus that will usually get it functioning again. You can also change your settings to prevent your mouse from being put to sleep. On a desktop that's usually not a problem, on a laptop that's obviously not great.

If you run the mouse refresh script as a systemd startup service it might correct your late initialization problem. I am only on my cell ATM, when I get to my home computer I can post more information for you. You can also search for this info, as I have quite a few posts on this topic on other Linux forums.

Of course scripting and services would only be a workaround, but if it corrects your issues you may find it satisfactory.


Any reset scripts would be appreciated.

Update regarding the tests: It happens with either of my USB mice, USB ports, lts and zen1 kernel and still after the latest updates. Now it's getting weird: After some testing and rebooting I forgot to unplug the old mouse but plugged in the newer one. To be clear I rebooted with two USB mice attached and et voilà I could control the cursor even on the login screen without waiting for about half a minute. On the other hand today the mice were initialized (LEDs on in the mouse case) but the cursor was frozen while the keyboard (USB as well) worked fine.
This all looks like a problem with its own random number generator and diagnosing the problem is really a PIA as it's so unpredictable.

I found a reset script that works in case the mouse/mice stop working. It's still unclear to me what is causing the problem in the first place as it only affects the USB mouse but not the USB keyboard (fortunately).

#! /bin/bash

for i in /sys/bus/pci/drivers/[uoex]hci_hcd/*:*; do
[ -e "$i" ] || continue
echo "${i##*/}" > "${i%/*}/unbind"
echo "${i##*/}" > "${i%/*}/bind"

A note for others running into that issue:
The above script works for me and if you search for and systemd you're going to find tbg's post like Keyboard and mouse not working after suspend - Technical Issues and Assistance - Manjaro Linux Forum


Sorry for not posting that for you. I've a lot on the go ATM and doing that for you kind of slipped between the cracks. I'm glad to see your search skills are top notch and that you managed to find it on your own.

The services on that old thread would need to be altered to work with KDE. You could use a startup and/or a suspend service running that script to run it automatically.

On the same archived website I also have a very long systemd service thread with many examples of services I (and others) have written.

Worth checking out if you need some help writing services:

If you have already written a service and it is working for you please post it here for reference.

1 Like

Thanks. I don't have a systemd service yet. The hiccup only occurs from time to time and for the time being I'd rather keep an eye on it, maybe get some more details along the way.
When it gets too annoying I probably am going to go the service route.

As a side note: It's quite interesting to run a system that does not target device and application stability as the primary priority. I run into some problems I haven't had in decades like losing a mouse or an audio device, stuttering video playback or lost monitors on the fly. It keeps you on your toes and you learn quite a lot. :wink:

These types of issues are generally not that common, but drivers are generally only written for the big commercial OS's (Windows & Apple). Therefore hardware issues are far more common in the Linux world.

On the positive side, because Linux is designed to be easily modifiable by the user a workaround can usually be found. With the commercial OS's this is not the case at all. If you encounter a hardware problem with something there you are at the mercy of their tech dept to find a fix for you (could be a long wait).

At least with Linux if you have the will, there is usually a way to overcome your issue.

1 Like

Oh, just to be clear, I was talking about Linux. I touch Windows only when there is absolutely no other way and while OSX makes a very reasonable development platform for Java the additional hardware costs is a bit too much for me - apart from the fact you mention as well that Linux gives you total freedom while OSX gives you some because of the freebsd-based system.

What I meant is some strange phenomena I haven't seen in Linux for decades like the current thing that feels like a buffering to the headset but that's for another thread when I find out more.

You must realize Garuda is far more cutting edge and experimental than most other distros you will encounter in common usage. The Garuda Devs find it boring to stick to the old/staid technologies that have been around for a decade or more. The philosophy of the Garuda Devs is to always be testing the newest developments for improvements.

In the case of the distro's audio components there have been several major changes in the last 6 months or so. For some people the changes have worked out great with major improvements. For others this has resulted in headaches that require reconfiguring/replacing the new audio packages. It's always luck of the draw with these kind of upgrades. Most people will experience no issues, but a percentage will always have some hiccups when major changes are made to their audio setup.

Research recent audio issues and their fixes on the forum. It is highly likely that the answer for you has already been posted on the forum.


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.