Mouse buttons and keyboard unresponsive after idle time

Bug #1912670 reported by nick_s
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
xfce4-power-manager (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

If I leave my desktop (Xubuntu 20.04.1 LTS, Xfce xfdesktop4 4.14.2-1, Xorg 1:7.7+19ubuntu14) idle for a few minutes, the mouse buttons and most keyboard presses become unresponsive. My "system power saving" setting is disabled (set to "never") and "display power management" is set to blank after 15 minutes, but the problem seems to occur sooner than that. Unplugging and re-inserting the mouse after a few seconds has no effect.

The only keystrokes that have any effect are Ctrl+Alt+F1 for a terminal session (where I can type normally). Returning to the desktop with Ctrl+Alt+F7 the mouse and keyboard remain unresponsive as before. This occurs with kernel 5.4.0-62, and I also installed the 5.4.0-26 kernel and the problem happens with that too. When I reboot the machine everything works fine again, but after a few minutes of idle time, the same problem occurs again. I've only noticed the problem occurring in the last ~2-3 weeks.

When I leave a terminal window open on the desktop running the command:
  tail -f /var/log/Xorg.0.log
and allow lots of time for the problem to occur, no lines are appended in the terminal even after the problem has happened, but when I then use Ctrl+Alt+F1 and log in at the terminal console, the following additional lines appear in /var/log/xorg.0.log :
[ 3805.283] (II) event1 - Power Button: device removed
[ 3805.296] (II) event0 - Power Button: device removed
[ 3805.312] (II) event3 - Logitech USB Optical Mouse: device removed
[ 3805.344] (II) event4 - Eee PC WMI hotkeys: device removed
[ 3805.364] (II) event2 - AT Translated Set 2 keyboard: device removed

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xorg 1:7.7+19ubuntu14
ProcVersionSignature: Ubuntu 5.4.0-62.70-generic 5.4.78
Uname: Linux 5.4.0-62-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.14
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Jan 21 16:37:48 2021
DistUpgraded: Fresh install
DistroCodename: focal
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 NVIDIA Corporation GK208B [GeForce GT 730] [10de:1287] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. GK208B [GeForce GT 730] [1043:8501]
InstallationDate: Installed on 2020-05-17 (249 days ago)
InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
MachineType: System manufacturer System Product Name
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=linux
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-62-generic root=UUID=c8acacab-7716-4698-b0e0-6041467d4517 ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/13/2019
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 5406
dmi.board.asset.tag: Default string
dmi.board.name: PRIME X470-PRO
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: Default string
dmi.chassis.version: Default string
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr5406:bd11/13/2019:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEX470-PRO:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: System Product Name
dmi.product.sku: SKU
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx 20.2.6-0ubuntu0.20.04.1
version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

Revision history for this message
nick_s (nickstylianou) wrote :
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thanks for the bug report. This sounds a power management problem.

1. If you have 'tlp' installed the please uninstall it. It's known to cause bugs like this.

2. Try installing 'powertop' and then look in its 'Tunables' section. By changing some of those to 'Bad' (which is actually better than 'Good' in this case) you can stop them suspending so much.

3. The kernel team should have some more ideas. I will move this bug there...

affects: xorg (Ubuntu) → linux (Ubuntu)
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
nick_s (nickstylianou) wrote :

Thanks. Here are the results of your suggestions, plus some other things I tried:

1. 'tlp' was not installed.

2. I installed 'powertop' and checked its 'Tunables' section. There were 6 entries for "Autosuspend for USB device xHCI Host Controller" all set to 'Good' - I changed these to 'Bad'. The problem still occurred.

3. Further diagnostics eventually led to my trying the following:
    * added "usbcore.autosuspend=-1" to the GRUB_CMDLINE_LINUX_DEFAULT line in /etc/default/grub
    * ran: sudo update-grub
    * rebooted
    * cat /sys/module/usbcore/parameters/autosuspend
        [shows -1 as expected]
    * cat /sys/bus/usb/devices/usb[1-6]/power/autosuspend_delay_ms
        [now shows -1000 - (was previously 0) ]
but the problem still occurs.

4. Repeated the above GRUB change with the parameter 'autosuspend_delay_ms' rather than 'autosuspend'.
    * ls /sys/module/usbcore/parameters
        [shows an 'autosuspend' parameter but not an 'autosuspend_delay_ms' parameter]
    * sudo modinfo usbcore
        [shows: parm: autosuspend:default autosuspend delay (int)]
    * cat /sys/bus/usb/devices/usb[1-6]/power/autosuspend_delay_ms
        [now shows 0]
but the problem still occurs.

In all cases I still get the same five 'device removed' messages in /var/log/Xorg.0.log as originally reported, and the mouse and keyboard are unresponsive after a few minutes idle time.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Under the console, please run `evtest` and check whether events from mouse and keyboard are normal.

Revision history for this message
nick_s (nickstylianou) wrote :

In a terminal window on the desktop I run evtest... after a few minutes of idle time the desktop is unresponsive to any mouse clicks but evtest continues to report all mouse activity.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Thanks. That means it's not a kernel bug...

Maybe give GNOME desktop a try so we can isolate it's a bug in XFCE?

Revision history for this message
nick_s (nickstylianou) wrote :

Before I try GNOME desktop, I tried some additional things:

1) From the Ctrl_Alt+F1 terminal console, running 'sudo systemctl restart lightdm' restarts my desktop environment and everything is ok until a few minutes idle time causes the problem again.

2) In the Xfce desktop panel I removed the Power Manager Plugin. I also used 'ps -ef | grep power' to identify the xfce4-power-manager process id, and killed it with sudo kill, such that no xfce4 power management processes are listed by ps.
After allowing many minutes of idle time, the problem does *not* occur.

3) I booted into the default desktop environment from the bootable Xubuntu 20.04.1 LTS USB stick (the same stick I installed from back in May 2020). The problem doesn't occur, even though xfce4-power-manager is running.

Does this give any further clues?

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Thanks, that indeed means it's an XFCE bug.

affects: linux (Ubuntu) → xfce4-power-manager (Ubuntu)
Revision history for this message
nick_s (nickstylianou) wrote :

For the time being my workaround is to disable xfce4-power-manager by:

1) Going to Settings → Session and Startup → Application Autostart and unticking the "Power Manager (Power management for the Xfce desktop)" item in the list.

2) Removing the "Power Manager Plugin" item from the desktop panel

This at least prevents the problem from happening, until a fix is issued. I can only assume that the problem was introduced in an update during the last few weeks, as it wasn't happening previously.

Revision history for this message
David Capello (davidcapello) wrote :

I was able to reproduce this bug on Xubuntu 20.04.4 LTS. But disabling xfce4-power-manager and removing the Power Manager plugin didn't work. Also as the "evtest" still receives mouse events (in a xfc4-terminal), it looks more like a problem in lightdm, xfwm4, or X11 server itself.

Is there a way to restart the WM without losing the X11 windows of all running applications? Or is there something I could test to give you more information? (e.g. running a debug/verbose version of xfwm4/lightdm)

Revision history for this message
David Capello (davidcapello) wrote :

I can add some extra information:

* This bug happens with xfwm4 4.16.1git.a78385f34

* The only thing that works: if the Applications menu is open when
  the hang occurs (e.g. I open the Applications menu and keep it
  opened, and leave the computer for 5 or 10 minutes), when I got back
  the mouse events (including buttons) work in the menu, even I was
  able to start the "Xfce4 About" app from the menu, but after that,
  mouse buttons (and the keyboard) don't work anymore.

Revision history for this message
nairbv (nairbv) wrote (last edit ):

> But disabling xfce4-power-manager and removing the Power Manager plugin didn't work.

this didn't work for me either... a few minutes later it was stuck again. I'm on a fresh install of xubuntu 22.04.

ctrl-alt-f1'ing to a terminal and killing xfce4-screensaver restored my ability to use the UI (for now at least).

Revision history for this message
sif_yuan (sify21) wrote :

killing xfce4-screensaver works for me too

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.