8

Sometimes, randomly (as far as I can tell) I can't click anything (can still move the pointer). I have to restart the computer to have it running again. Same thing is happening on 2 computers, one is Xubuntu, another is Lubuntu. One is 18.04, another is 20.04. But it also happened on plain Ubuntu as well. What's going on? It gets really annoying. One mouse is Logitech, another one is from Microsoft. Both are wireless. Btw, important note, the mousepad stops responding to clicks as well during that time. Thanks a lot.

edit: usually happens after I login after logging out / suspending the computer.

mrSuperEvening
  • 164
  • 2
    Please narrow down your details. You mention two computers, what does each run (Lubuntu uses a different desktop for 18.04 & 20.04, and Xubuntu is all GTK3 in 20.04 but only part GTK3 in 18.04). Wireless mouses can be interfered with by RF interference so have you explored around your boxes? but please narrow down OS details. – guiverc Oct 21 '20 at 07:57
  • Do you experiment these issue without plugging your wireless mices ? If not, do you still experiment these issues in differents spots (work, home, etc) ? If you do, can you check if that happens both wifi on and off ? (Since these behaviors are random, I expect you can't answer all that right now ;) ). Also, edit your thread with more details about your computer (inxi -SPARM -GCDN -v1 -xGCRS) and the mices, and how the wireless of your mices works (usb plug ? directly on your PC ?). Also, what about wired mices ? – B. du Garay Oct 23 '20 at 17:56
  • Have you looked into all sources of interference? PC's wifi, electric fields nearby, bluetooth, wifi cameras, cell phones, microwave ovens, toys, game console controllers, all those other talking(silly) devices people have planted around their homes??? Have you checked that you don't have a bunch of wireless devices using the same channel? Does it happen when the mouse is in close proximity to the receiver vs further away? .....and most of all, verified that this is only happening with wireless mice? Additionally I'd test the behavior with touchpad disabled in bios. – WU-TANG Oct 27 '20 at 02:21
  • Do you happen to use Chrome as your primary browser? And does it usually happen while moving Chrome windows? – rtaft Oct 28 '20 at 13:34
  • is your screen actually freezing? open a terminal(or two) and leave a tail -f on your syslog and/or Xorg(if you have one) log, to try to spot any anomalies. – WU-TANG Oct 28 '20 at 15:10

4 Answers4

2

I get this issue on systems that use the onboard graphics. Typically an application, often Chrome when moving the window, will get stuck and the window manager stops responding. When this happens, CTRL-ALT-F1 and run top, and the window manager and the application will both be pegging the CPU. Often I can just kill the application that is causing this issue, then CTRL-ALT-F7 back over to the UI and the mouse works again. If it takes a long time to CTRL-ALT-F1 it's usually a good indicator your CPU is maxed.

rtaft
  • 1,825
  • I don't think "onboard graphics" is a common term. "Dedicated GPU" or "Integrated GPU" are the terms I'm mostly used to seeing. Either way Chrome or Firefox were always snappy for both GPUs in my experience. I wonder if you have a problem that warrants a new question? – WinEunuuchs2Unix Oct 29 '20 at 23:36
  • It warrants a bug report if I could actually reproduce it reliably. I encounter this maybe once every 500-1000 hours of use on my laptop, but never on my desktop. – rtaft Oct 30 '20 at 19:51
  • Laptop design is more complicated than desktops it seems. Especially ACPI stuff. – WinEunuuchs2Unix Oct 31 '20 at 18:44
1

To the excellent comments from my colleagues, can you check what is the status of your memory?.

free -h

The reason is that you can expect random processes to be killed if memory is starving, but also I've seen core parts of the system going mad (or stressed) under heavy swap to disk.

I don't think is a hardware problem, as you can move the mouse, I think the x manager gets a lock and doesn't accept more commands, but we need to get some information to see clearly.

Can you also check the logs to see if the Kernel has killed any process or you have something hang?.

cat /var/log/syslog | grep -i "kill\|hang\|mem"
cat /var/log/kern.log | grep -i "kill\|hang\|mem"

Also check dmesg, is a good place to see problems with the USB devices and the swap:

dmesg -T | grep -i "USB\|swap" | less

Do you see anything extrange in:

less /var/log/Xorg.0.log

Do you use NFS or iSCSI or ZFS? Certain timeouts on network sharings are locking. Also certain hard drive errors, which I doubt as it is happening in two different computers.

When this happens can you go to the terminal with CTRL + ALT + F1 , F2 F3 F4 F5 or F6?.

Have you observed if this happens after the screen is auto locked?. The energy saving sometimes is troublesome. Is your USB receiver connected to the computer or to an external monitor with USB? (energy saving).

Cheers

Carles Mateo
  • 1,577
  • 6
  • 12
1

I've had a similar problem with a single computer. What fixed it was putting the USB dongle on an extension USB cord (~3 ft.) so that dongle (1) is away from the computer, and (2) has relatively clear path of transmission to the mouse.

I am guessing that the computer generates electrical noise that can interfere with the signal. Also, before moving it, there was a thick wooden table top between the dongle and the mouse. Haven't had any problems since.

I also wonder whether, if both your computers are running at the same, there could be further interference. However, better dongle placement could help with that too.

Craig Hicks
  • 829
0

Many people have had this problem and reloading the mouse drivers is a common solution.

From this answer I posted awhile back:

This bug is reported in launchpad: Elantech touchpad stops working after suspend. After suspend the OP tries # modprobe -r psmouse and # modprobe psmouse and it doesn't work. But what if psmouse was removed before suspend and inserted after suspend?

If this works manually then you can automate by creating a new file in the /lib/systemd/system-sleep/ directory containing:

#!/bin/sh

case $1/$2 in
  pre/)
    echo "Going to $2..."
    # Place your pre suspend commands here, or exit 0 if no pre suspend action required
    modprobe -r psmouse
    ;;
  post/)
    echo "Waking up from $2..."
    # Place your post suspend (resume) commands here, or exit 0 if no post suspend action required
    sleep 2
    modprobe psmouse
    ;;
esac

It is known after a suspend the psmouse module can't be removed. We also know it can be removed and inserted before a suspend. So this technique removes it before suspend. After resume insert it and hopefully the kernel won't reject it.

The sleep 2 command is from my own problems where systemd and kernel (via gnome or APM) were both sleeping and waking up. I needed to redirect pulseaudio sound back to the TV due to a bug introduced in Ubuntu 16.04/pulseaudio 8.0. The 2 second delay was necessary for kernel and systemd to finish waking up. Still haven't figured out the dual suspend and dual resume yet....

WinEunuuchs2Unix
  • 102,282