KDE Plasma on Wayland: no mouse and keyboard after resume

English Install/Boot/Login
1

The KDE Plasma on Wayland session became really usable lately.
The only thing that keeps me from using it more often is a nasty problem with suspend to RAM and resume.
On my laptop I use to send it to suspend to RAM by closing the lid, and resume by opening it again.

After resume there is almost every time no mouse and no keyboard available to enter the password and unlock the session.
Sometimes I can revive the USB mouse by unplugging and re-plugging it. But I did not find a way to revive the built-in keyboard of the laptop.
That means, I have to shut down the laptop the hard way (press the power button for some seconds) and restart.

Any ideas, how to solve this problem?

Hendrik

2

I don’t have that problem. But perhaps that’s because I never suspend.

Can you at least use CTRL-ALT-F1 to get a terminal? If you can, then login there as root to reboot:

shutdown -r now

Or maybe it works to login there as yourself, kill the Wayland session with the “kill” command – use

ps -fu $USER

to see what is running.

Otherwise – yes, Plasma on Wayland seems mostly stable, though it has some defects.

3

I can’t CTRL-ALT-F1, because the keyboard is not working.

If I’m able to revive the mouse, I can unlock the session by using the virtual keyboard and click on the logout button.
After logging out from the Plasma on Wayland session, the keyboard starts working again.
And about 2 times out of, let’s say 30, the problem did not show up.
Configuring the system to not lock the screen after resume does not help either.

Maybe it’s a strange timing problem, but I’m out of ideas.

Hendrik

4

Good point. That should have occurred to me.

Another trick is to use “ssh” to access it from another computer. But you have to have another computer available to try that.

5

You could try Alt-SysRq- and s,u,b (ie: Hold Alt and SysRq keys – PrtSc if your keyboard does not show SysRq – and while holding type sub )

6

Interesting; this works.
But it reboots the system. That’s not really what I want to achieve with suspend/resume.

Hendrik

7

I’m wondering if a kernel boot parameter might be able to help with this hardware quirk. This may take a bit of research and experimentation to get right.
http://lightrush.ndoytchev.com/random-1/i8042quirkoptions

What is returned by the following?

dmesg | egrep "i8042|input"
8

It returns:

    2.798167] i8042: PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
    2.800688] i8042: Detected active multiplexing controller, rev 1.1
    2.802055] serio: i8042 KBD port at 0x60,0x64 irq 1
    2.802109] serio: i8042 AUX0 port at 0x60,0x64 irq 12
    2.802152] serio: i8042 AUX1 port at 0x60,0x64 irq 12
    2.802194] serio: i8042 AUX2 port at 0x60,0x64 irq 12
    2.802236] serio: i8042 AUX3 port at 0x60,0x64 irq 12
    2.832402] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
    3.731824] psmouse serio4: synaptics: serio: Synaptics pass-through port at isa0060/serio4/input0
    3.770251] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input8
    5.528216] input: PS/2 Generic Mouse as /devices/platform/i8042/serio4/serio5/input/input9
    5.823856] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/0003:03F0:134A.0001/input/input10
    5.824716] hid-generic 0003:03F0:134A.0001: input,hidraw0: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:1d.1-1/input0
   35.790147] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input11
   35.790321] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input12
   35.790442] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input13
   36.075855] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:00/LNXVIDEO:00/input/input14
   36.395796] input: PC Speaker as /devices/platform/pcspkr/input/input15
   36.407735] input: Fujitsu FUJ02B1 as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:06/FUJ02B1:00/input/input16
   37.092790] input: Fujitsu Application Panel buttons as /devices/pci0000:00/0000:00:1f.3/i2c-6/6-0019/input/input17

Thanks for the link to the list with the quirks options. I’ve read about it, but did not find a comprehensive list.
I tried all of the options, one at a time, no combinations, but non of them helped. Some (nokbd, reset) made it even worse.

To exclude interactions between the Wayland session and a running X server, I booted to runlevel 3 (multiuser.target) and started the Wayland session manually. Did not help either.

Hendrik

9

I have the impression that the drivers do not get unloaded properly at suspend, hence cannot load during resume. If such is the case, one can write systemd units that force unloading and reloading these drivers. Mind, I don’t see this issue either on my HP laptop.

10

If you have a USB keyboard and mouse attached, do they function ok following a suspend/resume cycle?

11

Also, following a failed resume and a subsequent restart, examine the journal log from the previous boot

journalctl -b -1

Try to find the point in at which a resuming took place, and look for any obvious problems. Some filtering for input-related messages might help with the trawling here. For example

journalctl -b -1 | egrep "input|hid|i8042"
12

To be a little more explicit here, if you drop to runlevel 3 with

systemctl isolate multi-user.target

or

telinit 3

and then suspend with

systemctl suspend

can you then resume to a working VT ok?

13

Yes. It was just a suggestion for a cleaner reboot than holding the power button.

14

The module i8042 is integrated into the kernel and can’t be unloaded. For the mouse I can reload hid-generic instead. This works. But I didn’t find a module for the keyboard.

Hendrik

15

For the system logs and more tests:

I have been looking into the system logs over and over. I don’t see any error messages, that could be related to this problem, or any obvious differences between working and not working suspend/resume cycles.
I tested the suspend/resume cycles in runlevel 3, all kinds of X sessions, Gnome on Wayland, Weston … it works.
The problem exists exclusively in Plasma on Wayland.

Hendrik

16

The systemd-suspend service provides a mechanism for executing scripts before suspending/hibernating, and again at resume…
https://blog.christophersmart.com/2016/05/11/running-scripts-before-and-after-suspend-with-systemd/
https://www.freedesktop.org/software/systemd/man/systemd-suspend.service.html

With respect to your keyboard, I wonder if something like the following (in a such a script) might work at resume to re-initialize the keyboard…

echo -n rescan > /sys/devices/platform/i8042/serio0/drvctl

or

echo -n reconnect > /sys/devices/platform/i8042/serio0/drvctl

*I’ve read of a similar approach used to get unresponsive touchpads re-probed.

17

Ok, then it isn’t a kernel-level issue. A bug report probably the best course of action.

https://wayland.freedesktop.org/libinput/doc/latest/reporting_bugs.html

18

Thanks! Today I tested the “rescan” method and it did the trick!

Hendrik

19

Thanks for the update. That is good to know.