SUMMARY When suspending, keys pressed during the suspend do not get released on wakeup. STEPS TO REPRODUCE 1. Open a notepad 2. Press a keyboard key and immediately after press the sleep key in application launcher 2a. Alternatively use systemctl suspend to enter sleep mode 3. Wait for computer to enter sleep and then wake it up again 4. Log into the system and focus the notepad OBSERVED RESULT The key pressed during the suspend is spammed into the notepad as if it were still pressed. (enter if systemctl suspend was used, space or other if using application launcher) EXPECTED RESULT The key is not locked down on wakeup. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.11.6-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-9700 CPU @ 3.00GHz Memory: 31,3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2 Manufacturer: ASUS ADDITIONAL INFORMATION The issue does not affect SDDM, only appears once actually logged in. This is a regression, however i don't know what version broke it, probably in/after 6.2.0.
Cannot reproduce by doing `sleep 3 && systemctl suspend` in a terminal window and holding down a key until it suspends. When the system wakes up, everything is normal. Does that exact thing trigger it for you, or are the specific triggering conditions different?
That is very odd. The exact cases for me are: 1 - I don't even need to hold the key, the instant the "enter" key is pressed during confirmation of "systemctl suspend" is enough to trigger the bug, waking up and logging in leads to spamming of newlines. 2 - Holding space just for half a second before clicking "sleep" is also enough Following your reproduction attempt is also enough to trigger it. However I've come up with an idea while further testing it. The bug is commonly triggered in google chrome for me, and the editor i tested with is VS Code, both of these run through xwayland by default. I've tested it the following way: 1 - Run vscode and suspend system - key is spammed 2 - Run gedit and suspend system - key is NOT spammed 3 - Run vscode with --enable-features=UseOzonePlatform --ozone-platform=wayland - key is NOT spammed So the blame is probably not with chromium, but caused for me by chromium running through xwayland. However i don't have any xwayland text editor to test with. Can you try to reproduce it according to these instructions? However not sure anymore if this is caused by KDE, xwayland or somewhere in between... Side note, the window also doesn't have to immediately focus upon logging in. I usually test with yakuake, so once the terminal is closed, upon logging in the editor/browser is immediately focused. But i also tested it with Konsole and the spam is happening only after switching over to vscode, further confirming only a subset of windows is affected.
Aha,so it's an issue that only affects either XWayland apps or XWayland-using Chromium-based apps. That's an important clue indeed. However I can't reproduce it when trying in Discord, which is both Chromium-based and XWayland-using. Tried with all XWayland snooping modes (in System Settings > Application Permissions > Legacy X11 app support). Do the settings on that page affect it at all for you?
I've tried all 4 options and nothing has changed. (unless the options require a reboot) Also wanted to try with Discord, however after waking up it "spins" for a while before network connection gets established, so not sure how indicative that is, but there was no key spam once it ended up loading.
*** Bug 495466 has been marked as a duplicate of this bug. ***
I'm not able to reproduce on git-master on Solus using the steps in the original message, with VS Code or Discord I also can't reproduce with KDE Neon Testing (to also exercise differences in packaging) I also tested with Sticky keys: enabled / disabled Lock sticky keys: enabled / disabled