[Solved] Keyboard and mouse not working after resuming from suspend.

matthew_moppett · 2022-01-11 07:09:04

The problem

I have a Lenovo Ideapad s145 laptop running the Sway window manager. Whenever I suspend to ram and then wake my computer up, the window manager does not receive any input from my keyboard, touchpad, or mouse. The system is not frozen; it reconnects to wifi and then shows the wifi icon, for example. It just won't respond to user inputs except for the magic sysrq commands.

Workarounds

If I disconnect the mouse and plug it back in again, the mouse (but not keyboard or touchpad) starts working again. Using the mouse, I can log out from my Sway session and be returned to the console (tty 1), and at this stage my keyboard starts working again: I can log in at the console, which automatically logs me in to a new Sway session where all my input devices are working perfectly.

In addition, since the problem doesn't seem to affect the console, I can work around the problem by switching to a new tty before I suspend (i.e. using ctrl-alt-f5), logging in at that tty, and typing `systemctl suspend` there. When I resume after doing this, my keyboard works fine, and I can then type `chvt 1` to get back to my Sway session, where both keyboard and mouse work normally.

Update
I can fix the keyboard and USB mouse problem by restarting them with a script run after every resume from suspend, as detailed in my replies below. That doesn't fix the touchpad, but it's now working well enough for me to mark this issue as solved. Of course, I'd still be grateful if anyone could suggest a way to restart the touchpad as well -- or better yet, fix the root cause of the problem.

What I've tried so far

After a bit of googling about this issue, I have experimented with adding both `i8042.reset i8042.nomux i8042.nopnp i8042.noloop` and `atkbd.reset=1` to the `GRUB_CMDLINE_LINUX_DEFAULT` line in `/etc/default/grub` and then running `grub-mkconfig -o /boot/grub/grub.cfg` and rebooting, but neither of these options resolved the issue.

System logs

Output of running

 systemctl suspend; sleep 60; journalctl --since "2 minutes ago"

and waking the computer up in the middle of the sleep period: gist.

Output of running

 systemctl suspend; sleep 60; journalctl --since "2 minutes ago"

waking the computer up in the middle of the sleep period, and disconnecting then reconnecting the mouse: gist.

Output of running

 systemctl suspend; sleep 120; journalctl --since "3 minutes ago"

waking the computer up in the middle of the sleep period, and logging in and out of the Sway session as described above: gist.

Output of running

echo start_from_here | sudo tee /dev/kmsg; systemctl suspend; sleep 30; sudo dmesg > dmesg.tmp

and suspending/resuming: gist.

Nothing in these logs seemed to be directly related to the issue to my (admittedly untrained and frankly clueless) eye.

System information

OS: OS: Arch Linux x86_64
Kernel version: 5.15.13-arch1-1
DE: Sway 1:1.6.1-2

Output of `lsmod`: gist
Output of `sudo lspci -v`: gist

Any help would be appreciated.

Last edited by matthew_moppett (2022-01-23 14:51:07)

matthew_moppett · 2022-01-14 14:49:25

Update: I now have a partial solution/workaround for this issue. I've set up a systemd service to run the following commands on resuming from suspend:

rmmod atkbd
modprobe atkbd reset=1

This resets my keyboard driver, which seems to fix the problem with my keyboard. Strangely enough, it also seems to fix my mouse problem about 30% of the time (and for the other 70%, I just have to pull out the USB plug and reinsert it to get my mouse working properly). My touchpad, however, still doesn't work after returning from suspend.

I'm not sure if I should mark this post as solved, since I'd still like to find some way of fixing my mouse and touchpad as well -- ideally something that addresses the root cause of the issue. I think my mouse driver is `is xhci_hcd`, but that driver seems to be pre-compiled into my kernel and I don't know how to reset it. And I have no idea what my touchpad driver is.

Last edited by matthew_moppett (2022-01-23 14:31:27)

matthew_moppett · 2022-01-23 14:46:37

Instructions for resetting the atkbd driver and USB mouse on resume from suspend

This procedure worked for me:

Put the following script somewhere sensible. I put it at `/usr/local/bin/reset-input-devices.sh`.

#! /bin/sh
# Reset the keyboard driver and USB mouse 
        
modprobe -r atkbd
modprobe atkbd reset=1
echo "Finished resetting the keyboard."
        
# Reset every USB device, because we don't know in advance which port
# the mouse is plugged into. Send errors to /dev/null to avoid 
# cluttering up the logs.
for USB in /sys/bus/usb/devices/*/authorized; do
    eval "echo 0 > $USB" 2>/dev/null 
    eval "echo 1 > $USB" 2>/dev/null
done
echo "Finished resetting USB inputs."

Since it has to be run as root, you should be careful with permissions, i.e.:

$ sudo chown root:root reset-input-devices.sh
$ sudo chmod 744 reset-input-devices.sh

To make this script run after resuming from suspend, we can use a systemd service. Let's say that the script above is at /usr/local/bin/reset-input-devices.sh. Now we need to create a service file in the /etc/systemd/system/ directory -- let's call it /etc/systemd/system/reset-input-devices-after-sleep.service. It should look like this:

# This service is used to work around an apparent bug that freezes 
# keyboard and mouse inputs after waking from sleep.
            
[Unit]
Description=Reset the keyboard and mouse after waking from sleep
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target
            
[Service]
ExecStart=/usr/local/bin/reset-input-devices.sh
CPUWeight=500
           
[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

Then enable the service so that it is ready to respond to a return-from-suspend event both now and after every new boot:

$ systemctl enable --now reset-input-devices-after-sleep.service

marcin123 · 2024-05-29 00:35:06

I had the same issue with bluetooth mouse on Surface Pro 7. However, by bluetooth driver was not `atkbd`, instread it was `btusb`.

To check which driver is actually used, do `lsusb -t`

lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 008: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 010: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 010: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 10000M

To reset `btusb` after suspend

sudo rmmod btusb
sudo modprobe btusb

or just making it automated as explained earlier in the thread.

Arch Linux

#1 2022-01-11 07:09:04