https://bugs.kde.org/show_bug.cgi?id=526968
Bug ID: 526968
Summary: After resume the main Enter key is stuck: applications
keep receiving Enter repeats and the key cannot be
recovered from the keyboard
Classification: Plasma
Product: kwin
Version First 6.7.5
Reported In:
Platform: CachyOS
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: input
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Created attachment 197029
--> https://bugs.kde.org/attachment.cgi?id=197029&action=edit
the test i made
I am on CachyOS (Arch Linux, kernel 7.2.9-2-cachyos) with Plasma 6.7.5 Wayland,
using a Razer Ornata V3 X keyboard (USB 1532:0294).
After the machine comes back from suspend, the main Enter key behaves as if
it were held down: applications keep receiving Enter, and nothing I do on the
keyboard brings it back. The numpad Enter keeps working, and so does every
other key. The only way I found to recover is to re-plug the keyboard or to
unbind/bind its USB port (I now do that automatically with a systemd-sleep
hook).
I looked at the raw event nodes and at the kernel key state while the problem
was active, and this is what I saw: My keyboard exposes two HID keyboard
interfaces: if00 (/dev/input/event6, silent during normal use) and if01
(/dev/input/event17, which is the one that actually carries the keys).
kwin_wayland holds both of them open.
- On event6 the kernel reports KEY_ENTER as held even though nothing is pressed
(EVIOCGKEY says "KEY_ENTER (28) held"). On that node I only ever see
- My keyboard exposes two HID keyboard interfaces: if00 (/dev/input/event6,
silent during normal use) and if01 (/dev/input/event17, which is the one that
actually carries the keys). kwin_wayland holds both of them open.
- On event6 the kernel reports KEY_ENTER as held even though nothing is pressed
(EVIOCGKEY says "KEY_ENTER (28) held"). On that node I only ever see
kernel autorepeat events, about 29 per second (6236 of them in one
capture), and not a single press or release event: the device sends nothing on
that
interface, so the release that should clear it can never arrive.
- On the other node (event17) press and release events arrive normally: I
pressed the main Enter key 6 times during that capture and all six pairs
reached the kernel. None of them cleared the stuck key, and the applications
still received nothing usable from it.
- To rule out suspend and my hardware, I reproduced the same state without
suspending anything. I used a throwaway uinput device that presses KEY_ENTER
once and never sends the release (exactly the state my keyboard was left in).
With that device holding Enter, a focused terminal that counts every key it
receives got 159 Enter events out of 3 injected presses (roughly 40 per
second), which is what I experience as "the key stays pressed". With nothing
held, the same 3 presses produced exactly 3 events, and after the uinput device
sent the release, 3 again. The uinput device has no repeat capability and only
sent one press, so the repetitions come from the compositor. So from the user's
point of view: when a key's release is lost (which happens to me on resume),
that key stays "down" for the rest of the session and is spammed into
applications, and there is no way to clear it from the keyboard.
Steps to reproduce
(without suspending, about 20 seconds):
1. Start a Plasma
Wayland session.
2. In a terminal run: cat > /tmp/enter-count.txt (every Enter I receive adds
one byte).
3. Run the attached script 11-script-objective-test.py. It creates two uinput
devices: one holds KEY_ENTER down and never releases it, the other taps
Enter.
- nothing held: 3 taps -> +3 bytes
- KEY_ENTER held on the first device: 3 taps -> +159 bytes
- after
the release: 3 taps -> +3 bytes
Expected
result: a key whose release was lost should not become permanently unusable.
Either the presses coming from another device should be delivered even if that
keycode is wrongly held on a different device, or the stale held state should
be dropped when it cannot be valid any more (for example on resume, or when a
device node stops sending events). Right now the key stays down and nothing the
user does on the keyboard recovers it.
Workaround, in case it helps someone else: echo -n 1-5 >
/sys/bus/usb/drivers/usb/unbind ; sleep 1 ; echo -n 1-5 >
/sys/bus/usb/drivers/usb/bind (1-5 is my keyboard's USB port). After that both
nodes are re-created, no key is reported as held and Enter works again straight
away, without logging out.
Attachments: the raw captures with the bug active, the kernel key state
before/after, lsof on the input nodes, my hardware/software details, the sleep
hook I use as a workaround, and the three small scripts I used for the
measurement above.
Related: bug 526575 (an unmatched Enter keyup is delivered to the previous
application after unlocking) and bug 526401 (a key left logically pressed
after resume, with autorepeat reaching applications). A similar problem in
another compositor was fixed in Hyprland by clearing the pressed-key list when
keyboard devices are destroyed (hyprwm/Hyprland#15962). I am happy to test
patches or to run more tests, for example with the out-of-tree razerkb module
unloaded, if that helps to separate the layers.
--
You are receiving this mail because:
You are watching all bug changes.
