[SOLVED] Wireless mouse periodically freeze after inactivity

lewinat0r · 2021-10-04 08:38:07

Update 3: (also see my reply #9 below) It seems that the issue is with the mouse alone (and possibly this particular mouse). Since this issue appears in both Raspberry Pi OS and Windows. I have requested a new one from the retailer and will update the question later.

======

Update 2: I tried other wireless mice, it turned out that they don't have the same issue. I said they have, but my memory served me wrong. Only one of them has lagging issue, but not the same one.

So, this is a issue comes with the mouse, not the system. But I will soon test it on Windows to see if the behavior depends on OS (the firmware may behave properly on Windows? not sure).

======

Update 1: I am starting to think this is not a sleep-mode issue (see the bold text below). I have put the mouse idle for 10 minutes, and it went into a mode where I have to wake up with a button click. That might be the actual sleep mode. (or are there two, a deep one and a normal one?)

======

Original post:

I posted this to superuser.com. Here I post the content again and added some details I found since I post the question.

I am using Arch Linux and a wireless mouse, in this case, an Inphic PM6 wireless mouse, on a laptop.

The behavior:

After a certain time (exact 60 seconds for the current mouse) of inactivity, if I move the mouse again, the cursor will freeze for ~100 milliseconds (most of the time around 120 ms) for every 383.8 milliseconds.

At the later part of the post, I will explain what I have done to analysis the behavior and how I got the exact period of 383.8 milliseconds.

A workaround:

Switch the mouse off and on again (why not ) will temporarily make the mouse work well, but issue still appear after the same time of inactivity.

The question:

Has anyone had the same issue? How to make the periodic, short freeze go away?

======

What is (not) related / What I have (not) tried:
- I tried to disable the usb autosuspend according to Power management on Arch Wiki, but it didn't work. My steps:
- Find the vendor and product id with lsusb:

Bus 001 Device 070: ID 1ea7:0064 SHARKOON Technologies GmbH 2.4GHz Wireless rechargeable vertical mouse [More&Better]

- Add this rules file to /etc/udev/rules.d/50-usb_power_save.rules

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1ea7", ATTR{idProduct}=="0064", ATTR{power/autosuspend}="-1"

- Refresh

udevadm control -R

- Unplug and plug the wireless receiver (or whatever it is called) and wait for 60 seconds, the issue appears again.
- I think the stutter (I am not sure if this is the right word, I am not a native speaker) is mostly related to the mouse's sleep feature for power-saving. Most wireless mouse has this feature.
I have once played a game non-stop for more than one hour, and there was no issue. I infer that's since the mouse has not turned into sleep mode.
- This is probably not related to software taking up CPU, or any particular software blocking the mouse. The issue occurs even when my computer is idling.
- I had this issue with other wireless mice, only I didn't dig into and do the analysis to them as below. I will look into those and update this post later.
- I haven't tried other operating systems or computer hardware. I have another Arch Linux desktop and a Raspberry Pi 4B with Raspberry Pi OS. I will try on those machines later, too.
- I haven't tried changing drivers or similar low-level software. This is because I am not familiar with this stuff, I don't know where to start.

======

Since I am a grad-student in science, I used my skill to analysis the results I get from `xev' command. These are the steps:

1. I run the following command, and move the mouse in circles inside the `xev' window (the point is moving the mouse non-stop) to get the time sequence of the mouse events:

xev | grep root | sed 's/.*time \([0-9]*\).*/\1/p' > data.txt

2. I used the following python code to plot the time span between two mouse events against time:

import numpy
import matplotlib.pyplot as plt
data = numpy.loadtxt('data.txt')
t = data - data[0]
difft = t[1:] - t[:-1]
plt.plot(t[1:], difft, lw=0.5)

3. I get the following image:

https://i.stack.imgur.com/G9lrG.png

Interpretation:

If the data points are large in the figure, that means there was a time span where the mouse didn't move at all (freeze), and the height means the length of that freeze time. The length between two freeze point is the period of the freezing.

So If you open the image link, you will see the mouse freeze for 110~120 milliseconds with an almost perfect period. I measured (in plt.show(), where I can get more accurate coordinates) that period to be exact 383.8 to 383.9 milliseconds, every time.

Last edited by lewinat0r (2021-10-08 15:35:23)

Ropid · 2021-10-04 09:27:07

Did you try the mouse on a different PC or did you try in Windows? I'm wondering if it's the mouse itself causing the issue. If the mouse itself is the reason for the problem, maybe the manufacturer has a firmware update for it on their website that fixes it.

On my Logitech wireless mouse here, the mouse goes into its own power-saving feature after several minutes of no use. Similar to what you describe, when moving the mouse again, it needs a moment to wake up and pointer will not move for a split second. There's no way to change that power-saving behavior from the PC side, the mouse itself is doing it.

lewinat0r · 2021-10-04 09:48:31

Ropid wrote:

Did you try the mouse on a different PC or did you try in Windows? I'm wondering if it's the mouse itself causing the issue. If the mouse itself is the reason for the problem, maybe the manufacturer has a firmware update for it on their website that fixes it.

Thanks for reply! I had tried on another Arch desktop, the issue was the same. Haven't tried on Windows yet, I don't have any Windows machine. I guess I have to try that in order to determine if it is related to OS. I tend to believe it should be fine on Windows, from my previous experience on Windows, wireless mice didn't have this issue.

Ropid wrote:

On my Logitech wireless mouse here, the mouse goes into its own power-saving feature after several minutes of no use. Similar to what you describe, when moving the mouse again, it needs a moment to wake up and pointer will not move for a split second. There's no way to change that power-saving behavior from the PC side, the mouse itself is doing it.

Probably we are having different issues? In my case the mouse keep freezing for a fraction of second (~0.1s) again and again in every some more fraction of second(~0.4s), not just once when waking it up.

Ropid · 2021-10-04 11:14:39

lewinat0r wrote:

Probably we are having different issues? In my case the mouse keep freezing for a fraction of second (~0.1s) again and again in every some more fraction of second(~0.4s), not just once when waking it up.

Yes, I don't have that problem you describe. My mouse works normally after it wakes up. I just wanted to explain that there's (probably) no way to disable that behavior by doing configuration on the PC, the mouse will always fall asleep after a while.

lewinat0r · 2021-10-04 11:55:55

Ropid wrote:

Yes, I don't have that problem you describe. My mouse works normally after it wakes up. I just wanted to explain that there's (probably) no way to disable that behavior by doing configuration on the PC, the mouse will always fall asleep after a while.

If by "that behavior" you mean the behavior you are seeing, I don't mind that behavior at all . But the stuttering is probably a bug that can be fixed. I am hoping the periodic freezing will be solved, and finally get the mouse to work normally.

seth · 2021-10-04 15:18:40

I think the stutter (I am not sure if this is the right word, I am not a native speaker) is mostly related to the mouse's sleep feature for power-saving.

Most likely.
Now use your looking skills as an eye equipped mammal and look at the xorg log and dmesg:
The interesting part is whether the mouse gets re-registered during those freezes (which I understand happen despite you being using the mouse constantly - we're not simply talking about the mouse waking up w/ a short delay, right?)

lewinat0r · 2021-10-04 15:59:12

seth wrote:

Most likely.
Now use your looking skills as an eye equipped mammal and look at the xorg log and dmesg:
The interesting part is whether the mouse gets re-registered during those freezes (which I understand happen despite you being using the mouse constantly - we're not simply talking about the mouse waking up w/ a short delay, right?)

Thank you for the reply. I think I should have done that in the first post. However, there is no new output when the mouse is periodically freezing, or when I switch on/off the mouse, only when I (un)plug the receiver.

Here are the output of 'tail -f $HOME/.local/share/Xorg.0.log' and 'sudo dmesg -W' after I plug in the receiver, switch on the mouse, wait for 60 seconds for the freeze to appear, move the mouse around, switch off the mouse and unplug it:

Xorg log:

[ 12399.114] (II) config/udev: Adding input device 2.4G Mouse (/dev/input/mouse2)
[ 12399.114] (II) No input driver specified, ignoring this device.
[ 12399.114] (II) This device may have been added with another device file.
[ 12399.223] (II) config/udev: Adding input device 2.4G Mouse (/dev/input/event19)
[ 12399.223] (**) 2.4G Mouse: Applying InputClass "libinput pointer catchall"
[ 12399.223] (II) Using input driver 'libinput' for '2.4G Mouse'
[ 12399.279] (II) systemd-logind: got fd for /dev/input/event19 13:83 fd 62 paused 0
[ 12399.279] (**) 2.4G Mouse: always reports core events
[ 12399.279] (**) Option "Device" "/dev/input/event19"
[ 12399.279] (**) Option "_source" "server/udev"
[ 12399.281] (II) event19 - 2.4G Mouse: is tagged by udev as: Mouse
[ 12399.281] (II) event19 - 2.4G Mouse: device is a pointer
[ 12399.282] (II) event19 - 2.4G Mouse: device removed
[ 12399.282] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb1/1-2/1-2:1.0/0003:1EA7:0064.000B/input/input32/event19"
[ 12399.282] (II) XINPUT: Adding extended input device "2.4G Mouse" (type: MOUSE, id 13)
[ 12399.282] (**) Option "AccelerationScheme" "none"
[ 12399.282] (**) 2.4G Mouse: (accel) selected scheme none/0
[ 12399.282] (**) 2.4G Mouse: (accel) acceleration factor: 2.000
[ 12399.282] (**) 2.4G Mouse: (accel) acceleration threshold: 4
[ 12399.284] (II) event19 - 2.4G Mouse: is tagged by udev as: Mouse
[ 12399.284] (II) event19 - 2.4G Mouse: device is a pointer
[ 12399.286] (II) config/udev: Adding input device 2.4G Mouse (/dev/input/event18)
[ 12399.286] (II) No input driver specified, ignoring this device.
[ 12399.286] (II) This device may have been added with another device file.
[ 12537.011] (II) event19 - 2.4G Mouse: device removed
[ 12537.013] (II) config/udev: removing device 2.4G Mouse
[ 12537.013] (**) Option "fd" "62"
[ 12537.014] (II) UnloadModule: "libinput"
[ 12537.014] (II) systemd-logind: releasing fd for 13:83

dmesg output:

[12398.908144] usb 1-2: new full-speed USB device number 17 using xhci_hcd
[12399.062171] usb 1-2: New USB device found, idVendor=1ea7, idProduct=0064, bcdDevice= 2.00
[12399.062181] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[12399.062185] usb 1-2: Product: 2.4G Mouse
[12399.074522] input: 2.4G Mouse as /devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb1/1-2/1-2:1.0/0003:1EA7:0064.000B/input/input31
[12399.074645] input: 2.4G Mouse as /devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb1/1-2/1-2:1.0/0003:1EA7:0064.000B/input/input32
[12399.075192] hid-generic 0003:1EA7:0064.000B: input,hiddev97,hidraw4: USB HID v1.10 Mouse [2.4G Mouse] on usb-0000:03:00.3-2/input0
[12536.983356] usb 1-2: USB disconnect, device number 17

seth · 2021-10-04 21:37:48

The mouse seems to have an on/off switch on the downside - does that restore functionality as well or do you have to re-plug the receiver?

lewinat0r · 2021-10-05 05:49:53

seth wrote:

The mouse seems to have an on/off switch on the downside - does that restore functionality as well or do you have to re-plug the receiver?

Simply switching it off and on can get it work properly, but it's temporary.

======

Actually I just tested this on Raspberry Pi OS and Windows, it seems that the mouse has this issue across all OSes. So this should be a firmware issue, or in this case, more possibly individual issue of this one mouse. It is so silly of me not to have tested it sooner. The mouse is just bought, so I have already requested a new one from the retailer. I will update and close the post after I receive and test the new one.

Thanks again so much for your time, seth!

seth · 2021-10-05 07:01:37

firmware issue, or in this case, more possibly individual issue of this one mouse

That's why I had you toggle its power switch and your findings there support that thory, since that aspect of the input event generation is isolated in the mouse. Good luck for the replacement.

lewinat0r · 2021-10-08 15:33:36

I got the new one, and confirmed that this one does not have the issue. Although, I don't know why the old one was behaving like that. Anyway, that is not important since it just happens for that mouse alone. I just have to hope nothing will trigger the issue in the future.

Marking this as solved.

Last edited by lewinat0r (2021-10-08 15:35:33)

Arch Linux

#1 2021-10-04 08:38:07

[SOLVED] Wireless mouse periodically freeze after inactivity

#2 2021-10-04 09:27:07

Re: [SOLVED] Wireless mouse periodically freeze after inactivity

#3 2021-10-04 09:48:31

Re: [SOLVED] Wireless mouse periodically freeze after inactivity

#4 2021-10-04 11:14:39

Re: [SOLVED] Wireless mouse periodically freeze after inactivity

#5 2021-10-04 11:55:55

Re: [SOLVED] Wireless mouse periodically freeze after inactivity

#6 2021-10-04 15:18:40

Re: [SOLVED] Wireless mouse periodically freeze after inactivity

#7 2021-10-04 15:59:12

Re: [SOLVED] Wireless mouse periodically freeze after inactivity

#8 2021-10-04 21:37:48

Re: [SOLVED] Wireless mouse periodically freeze after inactivity

#9 2021-10-05 05:49:53

Re: [SOLVED] Wireless mouse periodically freeze after inactivity

#10 2021-10-05 07:01:37

Re: [SOLVED] Wireless mouse periodically freeze after inactivity

#11 2021-10-08 15:33:36

Re: [SOLVED] Wireless mouse periodically freeze after inactivity

Board footer