[SOLVED] Wireless mouse freezes randomly

DimK · 2026-05-06 19:54:07

Hi all,

The Problem
I am trying (!) to use an external mouse which works fine in other machines but on my Arch Linux laptop it keeps randomly freezing. It feels like it is activity based, like if I stop moving it for half a second it becomes unresponsive, but if I am constantly moving it then it does not freeze.
By "unresponsive" I mean that the cursor does not move for a maybe a second or two and then it gets "unstuck" and starts moving. During this time mouse clicks are also not registered. While the wireless mouse is frozen the track pad works without problems.
I have had this issue for as long as I have been using this setup (about 1 year) and it has been constantly there. I update the system quite regularly and never noticed the issue to be resolved.

Setup Info
Mouse: Logitech M325 (but I have noticed the issue with Logitech MX Master 3s connected with the USB dongle - did not try the bluetooth connection on the MX M3s)

Operating System: Arch Linux
KDE Plasma Version: 6.6.4
KDE Frameworks Version: 6.25.0
Qt Version: 6.11.0
Kernel Version: 6.18.25-1-lts (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 PRO 7540U w/ Radeon 740M Graphics
Memory: 16 GiB of RAM (14.3 GiB usable)
Graphics Processor: AMD Radeon 740M Graphics
Manufacturer: LENOVO
Product Name: 21K4S2YW00
System Version: ThinkPad T14 Gen 4

What I have tried
In the past I have tried disabling the auto suspend (from here: https://wiki.archlinux.org/title/Power_ … tosuspend) which was a suggestions in this topic: https://bbs.archlinux.org/viewtopic.php?id=258638 but without success. However, I am not even confident with what I was doing, so I wouldn't be surprised if I did something wrong.

I also tried X11 instead of wayland in the past, but the issue was still there.

Help
After failing to solve this issue for all this time, today I am asking for your help!
Any help in debugging this would be much appreciated here. Any logs to be looked at, any commands that can generate any useful info, or anything at all, is welcome!

Thanks a lot!

P.S. this is my first time posting. If I have messed this up in any way, let me know and please be nice

Last edited by DimK (2026-05-10 18:45:39)

seth · 2026-05-07 14:34:45

It's going to be some sort of power saving, but "stop moving it for half a second" doesn't hint at usb, more the device itself.
Does solaar cover the device and does it allow you to manipulate the power saving/timeout?

DimK · 2026-05-07 20:35:11

seth wrote:

Does solaar cover the device and does it allow you to manipulate the power saving/timeout?

I was not aware of solaar, so thanks! It looks like all Logitech devices with a unifying receiver (like this mouse) are covered by solaar but I cannot see any option on power saving or timeout. Not many options in general really...

Edit: having used the laptop for a few minutes after installing solaar, it does look like the issue has gone away! Not sure if that's expected, but will monitor for the next day or two and update here! Thanks!

Edit 2: nope!

Last edited by DimK (2026-05-07 20:57:08)

Liito-orava · 2026-05-08 08:04:06

I had kind of similar issue and as dumb as it may sound I found that it was actually that my desk had become so uneven that the sensor couldn't correctly pick up some of the movements. The troubleshooting steps for that should be pretty obvious.

Other than that it is probably a power saving/autosuspend kind of thing.

It looks like you tried already tried to disable usb autosuspend, but the Archwiki article and forum post seem to detail disabling autosuspend for one device.
To be sure I would recommend disabling it completely in the kernel command line:

usbcore.autosuspend=-1

Verify it is off via

cat /sys/module/usbcore/parameters/autosuspend

(should be -1)

Only do this as a troubleshooting step however, keeping usb autosuspend off completely is probably bad for energy efficiency.

DimK · 2026-05-08 21:26:15

Liito-orava wrote:

To be sure I would recommend disabling it completely in the kernel command line:
usbcore.autosuspend=-1

I am not sure how to do this. I tried adding this line in /etc/grub.d/40_custom but it looks like that's not the right way to do it. I used the verification method you mentioned and it still shows the default value 2 even after reboot. I have now removed that line from that file.

I then tried section #4 from this article: https://wiki.archlinux.org/title/Kernel_parameters and I can see the added command but still when I do

cat /sys/module/usbcore/parameters/autosuspend

I still get the default value 2.

I also added this line inside the quotes for GRUB_CMDLINE_LINUX_DEFAULT inside etc/default/grub, and even though this line remains there until after reboot, I do not see the parameter when I do

cat /proc/cmdline

and nor do I see the setting to -1 when I do

cat /sys/module/usbcore/parameters/autosuspend

If you have any good primer on setting kernel parameters that would be much appreciated, will do some more research to learn about this.

Last edited by DimK (2026-05-08 21:39:48)

seth · 2026-05-09 07:12:58

You mean https://wiki.archlinux.org/title/Kernel … ng_cmdline ?
Don't - edit the commandline in your bootloader configuration.
nb. that userspace power management tools like tlp and the ones pbovided by some DEs can and typically will alter that value at runtime - you'll have to configure any usb autosuspend behavior there (as well)

DimK · 2026-05-09 09:32:09

Yes, that's what I meant, and I did not manage to get it working so I reverted any edits.
What is the recommended way of editing kernel parameters?

The KDE plasma power management section does not have any USB autosuspend settings as far as I can see...

seth · 2026-05-09 14:48:37

Yes, that's what I meant

If you read the paragraph close you'll find that this only serves to fool some few and far inbetween userspace processes that might read the kernel commandline.
It's completely useless for this purpose.

What is the recommended way of editing kernel parameters?

That depends on your bootloader.
For the very specific task you can also just

echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend

Liito-orava · 2026-05-10 07:30:44

What I meant was passing the kernel parameter through the bootloader configuration, I apologize for any confusion.
Editing GRUB_CMDLINE_LINUX_DEFAULT should work, you might have forgot to update your grub.cfg using grub-mkconfig .
Probably still easier to just edit the grub.cfg manually like this

linux /boot/vmlinuz-linux root=... rw quiet splash usbcore.autosuspend=-1

See https://wiki.archlinux.org/title/Kernel_parameters#GRUB

As I mentioned before make sure you only do this for troubleshooting purposes.

Seth's suggestion should also work.

Last edited by Liito-orava (2026-05-10 07:32:04)

DimK · 2026-05-10 18:43:35

seth wrote:

If you read the paragraph close you'll find that this only serves to fool some few and far inbetween userspace processes that might read the kernel commandline.
It's completely useless for this purpose.

Thank you for pointing this one out! I hadn't realized it...

Liito-orava wrote:

See https://wiki.archlinux.org/title/Kernel_parameters#GRUB

Updating the grub.cfg, as shown on the article that you shared, Liito-orava, or here https://wiki.archlinux.org/title/GRUB#G … d_grub.cfg, worked!
After a reboot I was able to confirm that this returned -1

cat /sys/module/usbcore/parameters/autosuspend

This also confirmed that the issue was resolved as far as I see.

I then reverted the edits to GRUB_CMDLINE_LINUX_DEFAULT to bring it back to the default setting (and rebooted, which brought back the problem), and then I tried to make the original solution from this article work https://wiki.archlinux.org/title/Power_ … utosuspend

I think I have made it, and I don't see the problem currently.

I realized that when I first added the USB autosuspend rule, I copied exactly what was shown in the article:

ACTION=="add", SUBSYSTEM=="usb", ATTR{product}!="*Mouse", ATTR{product}!="*Keyboard", TEST=="power/control", ATTR{power/control}="auto"

to /etc/udev/rules.d/50-usb_power_save.rules
however, my mouse does not have the word "Mouse" in the name, so the above rule naturally won't work. I tried adding ATTR{product}!="Logitech, Inc. Unifying Receiver" (as seen from lsusb) but that did not work. However, it may be because I did not unplug and plug the dongle back in.

What Worked

Edit: /etc/udev/rules.d/50-usb_power_save.rules &

Add the following:

# blacklist for usb autosuspend
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="ABCD", ATTR{idProduct}=="WXYZ", GOTO="power_usb_rules_end"

ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
LABEL="power_usb_rules_end"

Where ABCD and WXYZ were seen as ABCD:WXYZ from lsusb
Source: https://wiki.archlinux.org/title/Power_ … utosuspend

Unplug the dongle and plug it back in. This one because this artictle: https://wiki.archlinux.org/title/Udev#Loading_new_rules states

Hot-pluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect, or at least unloading and reloading the ohci-hcd and ehci-hcd kernel modules and thereby reloading all USB drivers.

Thanks seth & Liito-orava for the help with debugging this!

tl;dr the original solution was correct - if only I had done it correctly

Last edited by DimK (2026-05-10 19:25:33)

Arch Linux

#1 2026-05-06 19:54:07

[SOLVED] Wireless mouse freezes randomly

#2 2026-05-07 14:34:45

Re: [SOLVED] Wireless mouse freezes randomly

#3 2026-05-07 20:35:11

Re: [SOLVED] Wireless mouse freezes randomly

#4 2026-05-08 08:04:06

Re: [SOLVED] Wireless mouse freezes randomly

#5 2026-05-08 21:26:15

Re: [SOLVED] Wireless mouse freezes randomly

#6 2026-05-09 07:12:58

Re: [SOLVED] Wireless mouse freezes randomly

#7 2026-05-09 09:32:09

Re: [SOLVED] Wireless mouse freezes randomly

#8 2026-05-09 14:48:37

Re: [SOLVED] Wireless mouse freezes randomly

#9 2026-05-10 07:30:44

Re: [SOLVED] Wireless mouse freezes randomly

#10 2026-05-10 18:43:35

Re: [SOLVED] Wireless mouse freezes randomly

Board footer