Unfortunately I've been unable to identify the cause other than I have an application that runs, in what appears to be a Xorg scheduler (task manager shows worker, then a shed job), then the mouse stops. It is an optical mouse so I can see the light go out, when it comes back on the mouse works again. I tried adding a rule for UDEV stating the following in /etc/udev/rules.d in a file named 10-local. rules

ACTION=="add", KERNEL=="3-2", SUBSYSTEM=="usb", ATTR{idVendor}=="045e", ATTR{idProduct}=="0040", ATTR{removable}=="no"

This does not have any effect, and I might not have the parameters correct in the rule. I've read some of the responses, but none of them seem to point to a solution for me anyway, maybe I'm just blind. Not much has changed on my system for years, but this problem seems to have happened after an Ubuntu update was sent and loaded.

lsusb shows the following. Bus 003 Device 042: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical

The system spends some time creating a new device for the mouse, and the device ID changes whenever it quits working.

A good solution might be to configure the USB port to never change as this is where the mouse is plugged into for ethernity. I've tried a different mouse too. The keyboard still works, but it is used the old PS/2 port.

Any ideas would be appreciated. I'm not Linux literate, but competent enough to fumble my way through when needed.


Sounds like a USB auto-suspend issue in your case. Kernel boot option usbcore.autosuspend=-1 should be tried to verify.

See: fix-linux-mouse howto

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.