SUMMARY Since Plasma 6.6.3, modifier keys (specifically Ctrl) are frequently "swallowed"/ignored when using remote desktop sharing via KRFB on a Wayland session. This regression makes remote desktop work and administration workflows nearly impossible, as essential shortcuts like Ctrl+C, Ctrl+V, or Ctrl+N fail to trigger. Interestingly, a different bug existed prior to 6.6.3 where the Ctrl key would occasionally become "locked" (stuck) during remote sessions. It is possible that a fix for the "stuck key" issue introduced this new "swallowed key" regression. The issue is specific to the KRFB (VNC) + Wayland combination. It does not occur on X11, nor does it occur when using KRDP. However, KRDP is not yet a viable alternative for many production environments due to current limitations and compatibility issues with the Windows 11 mstsc client. STEPS TO REPRODUCE 1. Start a Plasma Wayland session (reproduced on 6.6.3 and 6.6.4). 2. Configure and start KRFB for remote access. 3. Connect from a remote machine using any VNC client (e.g., KRDC or TigerVNC). 4. Attempt to use keyboard shortcuts in any application (e.g., Ctrl+N in Kate, Ctrl+C in Konsole). Optional (Comparison): 5. Log out and switch to an X11 session. 6. Repeat steps 2–4; observe that shortcuts work perfectly. OBSERVED RESULT Modifier keys are intermittently ignored. Pressing Ctrl+C often results in a literal 'c' being typed or a '^C' string in a terminal, rather than a copy command. The modifier state seems to be lost or cleared before the companion key is registered by KWin. EXPECTED RESULT Modifier keys should be passed through reliably, as they are in X11 sessions and via KRDP. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon (neon-user-20260430-1324) / Debian Testing (Forky) KDE Plasma Version: 6.6.3 and 6.6.4 KDE Frameworks Version: 6.25.0 Qt Version: 6.10.2 Graphics Platform: Wayland ADDITIONAL INFORMATION This issue significantly impacts the usability of Plasma for remote desktop work and administration. While KRDP is under active development, KRFB remains the primary tool for VNC-based remote access. The fact that this works on X11 but fails on Wayland suggests a regression in the Wayland input injection stack (potentially involving kwin_wayland, xdg-desktop-portal-kde, or libei).
Same in: $ apt-cache policy krfb krfb: Installed: 4:25.12.3-0ubuntu1 Candidate: 4:25.12.3-0ubuntu1 Version table: *** 4:25.12.3-0ubuntu1 500 500 mirror://mirrors.ubuntu.com/mirrors.txt resolute/universe amd64 Packages 100 /var/lib/dpkg/status $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 26.04 LTS Release: 26.04 Codename: resolute
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9253
Git commit 885ed3e1bbaba6bc12ea6e2b54126bd7c4bfdbda by David Edmundson. Committed on 02/06/2026 at 10:08. Pushed by davidedmundson into branch 'master'. fakeinput: Keep modifiers when handling keysyms The requirements for turning keysyms into keycodes are complicated. If the keysym is "F" vs "f" we need to handle pressing and unpressing shift before delivering the keycode. However, we still need existing modifiers like control, alt, meta to work based on key combinations. This patch avoids unsetting existingly held modifiers and takes a union. It does mean that sending some keySyms with modifiers explicitly held down may not translate correctly, but it's hopefully a happy medium. We also have to ensure when the user explicitly presses a modifier we don't unset the changes the user made. M +22 -0 autotests/integration/fakeinput_test.cpp M +25 -3 src/backends/fakeinput/fakeinputbackend.cpp https://invent.kde.org/plasma/kwin/-/commit/885ed3e1bbaba6bc12ea6e2b54126bd7c4bfdbda
Git commit 78769490b6d2d831f4cbac385380fe659f677a76 by David Edmundson. Committed on 02/06/2026 at 11:02. Pushed by davidedmundson into branch 'Plasma/6.7'. fakeinput: Keep modifiers when handling keysyms The requirements for turning keysyms into keycodes are complicated. If the keysym is "F" vs "f" we need to handle pressing and unpressing shift before delivering the keycode. However, we still need existing modifiers like control, alt, meta to work based on key combinations. This patch avoids unsetting existingly held modifiers and takes a union. It does mean that sending some keySyms with modifiers explicitly held down may not translate correctly, but it's hopefully a happy medium. We also have to ensure when the user explicitly presses a modifier we don't unset the changes the user made. (cherry picked from commit 885ed3e1bbaba6bc12ea6e2b54126bd7c4bfdbda) Co-authored-by: David Edmundson <kde@davidedmundson.co.uk> M +22 -0 autotests/integration/fakeinput_test.cpp M +25 -3 src/backends/fakeinput/fakeinputbackend.cpp https://invent.kde.org/plasma/kwin/-/commit/78769490b6d2d831f4cbac385380fe659f677a76
Git commit c186a75b78e142068649b4df452a45e28734bd26 by Vlad Zahorodnii. Committed on 16/06/2026 at 06:45. Pushed by vladz into branch 'Plasma/6.6'. fakeinput: Keep modifiers when handling keysyms The requirements for turning keysyms into keycodes are complicated. If the keysym is "F" vs "f" we need to handle pressing and unpressing shift before delivering the keycode. However, we still need existing modifiers like control, alt, meta to work based on key combinations. This patch avoids unsetting existingly held modifiers and takes a union. It does mean that sending some keySyms with modifiers explicitly held down may not translate correctly, but it's hopefully a happy medium. We also have to ensure when the user explicitly presses a modifier we don't unset the changes the user made. (cherry picked from commit 885ed3e1bbaba6bc12ea6e2b54126bd7c4bfdbda) Co-authored-by: David Edmundson <kde@davidedmundson.co.uk> M +22 -0 autotests/integration/fakeinput_test.cpp M +25 -3 src/backends/fakeinput/fakeinputbackend.cpp https://invent.kde.org/plasma/kwin/-/commit/c186a75b78e142068649b4df452a45e28734bd26