Created attachment 185615 [details] Video of the Ctrl+A bug happening on Plasma 6.5.80. SUMMARY If you press a shortcut like Ctrl+C in a Wayland app, then release the modifier Ctrl before the letter, the key remains held down in XWayland and can randomly be sent to a X11 app when you click on it. STEPS TO REPRODUCE 1. In Legacy X11 App Support, ensure "Allow legacy X11 apps to read keystrokes typed in all apps:" is set to the default of "As above, plus any key typed while the Control, Alt, or Meta keys are pressed". 2. Open a Wayland window (like a KDE app) and a X11 window (like Flatpak Obsidian). 3. Focus the Wayland app, type Ctrl+C, and release Ctrl before C. 4. Click on the X11 app. OBSERVED RESULT Randomly a C keystroke will be sent to the X11 app. This may take many tries. To see what keystrokes are delivered to X11 apps, you can install Screenkey from your distro package manager or by running `uvx https://gitlab.com/screenkey/screenkey.git`, then use Window Rules to set the popup to "Keep above other windows", "No titlebar and frame", and "Accept focus" force = No. I found that if I release Ctrl before C, XWayland usually enters a state where it sends an endless string of C keystrokes to screenkey (these may not be visible until you move your mouse over a X11 app); I think the key repeats forever because kwin_wayland fails to deliver the C key release to XWayland. When you click on a X11 app, there's a chance a key repeat gets delivered to the app before XWayland realizes C is no longer being pressed and stops repeating it. EXPECTED RESULT XWayland apps should receive key release events regardless of modifier state, if the original key press event was received (eg. because modifier was held, or before changing the "Allow legacy X11 apps to read keystrokes typed in all apps:" option). SOFTWARE/OS VERSIONS This reproduces on Plasma 6.4.5, as well as 6.5.80 from KDE Linux 2025-09-21. Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.18.0 Qt Version: 6.9.2 Kernel Version: 6.16.10-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-8559U CPU @ 2.70GHz Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: Intel® Iris® Plus Graphics 655 Manufacturer: Intel(R) Client Systems Product Name: NUC8i7BEH System Version: J72992-303 ADDITIONAL INFORMATION The "possible duplicates" list pointed to Bug 478705, which has a command `xinput test-xi2 --root` to log received keyboard/mouse events in the terminal. By running this command and doing testing, I found that if we press C (not received) then Ctrl, then release C, xinput never receives the C release event even though Ctrl is being held. I wonder if it's kwin filtering the unpaired release before reaching XWayland, or XWayland/xinput rejecting a stray key release KDE mistakenly sends. Previous testing at https://bugs.kde.org/show_bug.cgi?id=484992#c34 and https://bugs.kde.org/show_bug.cgi?id=484992#c59.
FWIW I haven't succeeded at reproducing the issue with those exact steps. :/
When you launch `xinput test-xi2 --root` in a terminal and perform the steps before 4, do you at least get key repeats without C held down? (If you use Konsole as the Wayland app, you may need to type Ctrl-A to avoid killing the program.)
I started seeing this today in git-master, copying from Firefox to Obsidian Notes (flatpak)
I was able to reproduce this using exact steps in "STEPS TO REPRODUCE". The bug is totally reproducible, you just need to have patience. Try a lot of times, and you will succeed in this. Try various ways to type that "Ctrl+C". I. e. try to release C right after Ctrl. Also try to release C right after Ctrl, but not quite right after, etc. I. e. try various durations between releasing C and releasing Ctrl. I used Chromium 140.0.7339.127 (it is Wayland-native app by default in this version) and xterm (it runs under xwayland) as my test apps. Operating System: Debian GNU/Linux 13 KDE Plasma Version: 6.3.6 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2 Kernel Version: 6.12.43+deb13-amd64 (64-bit) Graphics Platform: Wayland Processors: 32 × 13th Gen Intel® Core™ i9-13950HX Memory: 64 GiB of RAM (62.5 GiB usable) Graphics Processor: Intel® Graphics Manufacturer: Dell Inc. Product Name: Precision 7780
(In reply to nyanpasu64 from comment #0) > SUMMARY Does this happen if you set "Allow legacy X11 apps to read keystrokes typed in all apps:" to "Never"?
If I set "Allow legacy X11 apps to read keystrokes typed in all apps:" to "Never", `xinput test-xi2 --root` never reports keystrokes for Ctrl *or* A entered in a Wayland app, so X11 apps can't get stray keystrokes through the mechanism I described. To confirm, I tried the "Ctrl+A + !Ctrl + !A, click in Obsidian" dance 20 times and did not receive a stray keypress, meaning the bug does not appear to happen.
(In reply to nyanpasu64 from comment #6) > If I set "Allow legacy X11 apps to read keystrokes typed in all apps:" to Thank you!
(In reply to nyanpasu64 from comment #6) > If I set "Allow legacy X11 apps to read keystrokes typed in all apps:" to And if you set to "Only Meta, Control, Alt and Shift keys"? (I'm attempting to come up with working configuration for me.) Thank you in advance
My preferred workaround is to set it to Always. But I *think* any option other than "any key typed when (modifiers)" is unaffected, since that's the only option that *conditionally* allows keystrokes to be sent to Xwayland (so a key release can be missed).
this may be similar to what I'm observing with https://bugs.kde.org/show_bug.cgi?id=511684 my setting is currently "only the meta, control, alt and shift keys", and "listening for mouse buttons" is checked - I need this combination to let Mumble capture push to talk whilst not being in focus, however alt+tab is randomly acting funky causing my mouse forward / back events to be sent to multiple windows and I have to refocus the bugged window to get it to stop I'll try the "as above, plus any key pressed while the control, alt, or meta key is also pressed" option, and failing that I'll try "always allowed"
In my case, the only option that stops the input from being sent to the xwayland windows as well is to set Legacy X11 app support to "disabled". In every other case the input is still being dispatched to the windows that are not in focus
*** Bug 511186 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8539
Git commit 2459c02ac61cfbf744af02ebcec369db38ac4eb9 by Vlad Zahorodnii. Committed on 09/12/2025 at 09:59. Pushed by vladz into branch 'master'. xwayland: Fix keysniffing repeating keys If the modifier key is released, the key filter may return false but we still want to send the release event for the regular key. M +17 -24 src/xwayland/xwayland.cpp https://invent.kde.org/plasma/kwin/-/commit/2459c02ac61cfbf744af02ebcec369db38ac4eb9
Git commit 51ccff2d00ff94d9c2bbe1614131373f8dc4d7a9 by Vlad Zahorodnii. Committed on 09/12/2025 at 11:33. Pushed by vladz into branch 'Plasma/6.5'. xwayland: Fix keysniffing repeating keys If the modifier key is released, the key filter may return false but we still want to send the release event for the regular key. (cherry picked from commit 2459c02ac61cfbf744af02ebcec369db38ac4eb9) Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org> M +17 -24 src/xwayland/xwayland.cpp https://invent.kde.org/plasma/kwin/-/commit/51ccff2d00ff94d9c2bbe1614131373f8dc4d7a9
(In reply to Vlad Zahorodnii from comment #14) > Git commit 2459c02ac61cfbf744af02ebcec369db38ac4eb9 by Vlad Zahorodnii. Thank you for fix! I use current stable release of Debian, i. e. Trixie. It uses plasma and kwin 6.3. So, please, backport the fix to 6.3
(In reply to Askar Safin from comment #16) > (In reply to Vlad Zahorodnii from comment #14) > > Git commit 2459c02ac61cfbf744af02ebcec369db38ac4eb9 by Vlad Zahorodnii. > > Thank you for fix! I use current stable release of Debian, i. e. Trixie. It > uses plasma and kwin 6.3. So, please, backport the fix to 6.3 You need to ask Debian developers to backport it. 6.3 is not supported by KDE anymore.