| Summary: | Sticky keyboard keys when waking up from suspend | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Richard Tippl <richard.tippl> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | elles.robert, kde, kdedev, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.2.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Richard Tippl
2024-11-10 18:19:24 UTC
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 |