Enter key gets stuck / repeatedly triggers after Ctrl+P in VSCode and other apps on KDE Plasma (Wayland)

Help
,
1

I’m running into a strange input issue on KDE Plasma (Wayland) where the Enter key seems to get “stuck” or keeps triggering after using search/command palette .

System information

OS: Fedora Linux 44 (KDE Plasma Desktop)
KDE Plasma: 6.6.5
Kernel: Linux 7.0.10-201.fc44.x86_64
WM: KWin (Wayland)

Issue description

In VSCode, I can reproduce the issue like this:

  1. Press Ctrl + P

  2. Type a file name

  3. Press Enter to open the file

The file opens normally, but immediately after that, inside the opened file, the Enter key behaves as if it is still being pressed or repeatedly triggered.

It feels like the Enter key event is not being properly released after confirming the file selection.

The only way to stop it is to press Esc.

What makes this more confusing

  • I tested with a key event viewer/tool and it does not show Enter being physically pressed or held down.

  • The issue is not limited to VSCode:

    • It also happens in Windsurf

    • And Antigravity

  • It only seems to happen after using search/command palette style inputs (like Ctrl+P)

Expected behavior

After pressing Enter to confirm a selection:

  • The key event should trigger once

  • Then fully release with no residual input

Actual behavior

After pressing Enter:

  • The file opens correctly

  • But Enter behaves like it is still active

  • Causes repeated input / unwanted actions until pressing Esc

Additional troubleshooting tried

  • Ran VSCode using X11 mode via Electron flag:
ELECTRON_OZONE_PLATFORM_HINT=x11 code
  • Also forced X11 rendering using VSCode flags file:
echo "--ozone-platform=x11" > ~/.config/code-flags.conf
  • In VSCode, hardware acceleration was disabled by adding:
"disable-hardware-acceleration": true

to argv.json.

2

At first it sounded like this Plasma keyboard-related issue.

However, if you tried these mitigations…

…and they didn’t work, then it may not be the same.

3

Oi, sounds like my exact issue that I had but it’s strange that the proposed fixes in my post didn’t help you (check update below). We ultimately found out that having Plasma Keyboard selected as a virtual keyboard was the source of the issue. Do you have it selected? Search for virtual keyboard in system settings.

Also just to make sure:

run this exact command to run vscode:

code --ozone-platform-hint=x11 --enable-features=UseOzonePlatform

then check if it’s actually running under x11 with this command

qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole

You’ll see this window:

1780223942397256188199384236742
1780223942397256188199384236742640×640 25.7 KB

Check if vscode is inside X11 and not Wayland.

UPDATE: A quick search for why those fixes didn’t work for you makes me think that you’re using flatpak versions of these apps. Is that the case? It would answer why code-flags.conf didn’t work or passing the args didn’t work cause neither the conf nor the args were actually read.

4

i tried to switch to plasma x11 instead of wayland and this seems to fix the problem

5

Yes, essentially we’re forcing vscode and other apps to run under x11 with those flags but you shouldn’t have to change the compositor to x11 for the args to work. When you do the

qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole

after

code --ozone-platform-hint=x11 --enable-features=UseOzonePlatform

While running Wayland, what do you see in the X11 Windows category?

6

First, thanks for the command:

qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole

It helped me confirm whether VS Code was running under X11 or Wayland in KWin’s debug console.

Then I tested:

code --ozone-platform-hint=x11 --enable-features=UseOzonePlatform

This produced the following warnings:

Warning: 'ozone-platform-hint' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.

and it did not reliably change anything in the KWin debug console.

After that, I tried:

code --ozone-platform=x11

This time VS Code actually opened under the X11 windows category, and the issue disappeared.

Then I tried making it default using:

echo "--ozone-platform=x11" > ~/.config/code-flags.conf

but VS Code was still launching under Wayland when opened from KDE (icon / KRunner), so it wasn’t being applied.

To fully fix it, I forced it at the launch level:

Desktop entry:

mkdir -p ~/.local/share/applications && \
cp /usr/share/applications/code.desktop ~/.local/share/applications/ && \
sed -i 's|Exec=/usr/share/code/code|Exec=/usr/share/code/code --ozone-platform=x11|g' ~/.local/share/applications/code.desktop && \
sed -i 's|Exec=/usr/bin/code|Exec=/usr/share/code/code --ozone-platform=x11|g' ~/.local/share/applications/code.desktop && \
update-desktop-database ~/.local/share/applications

Binary wrapper:

sudo mv /usr/bin/code /usr/bin/code.real && \
sudo tee /usr/bin/code >/dev/null << 'EOF'
#!/bin/bash
exec /usr/bin/code.real --ozone-platform=x11 "$@"
EOF
sudo chmod +x /usr/bin/code
7

That’ll work, just a bit messy. Have you checked if your virtual keyboard is set to Plasma Keyboard?

Also have you tried actually checking the code-flags.conf file to avoid having the same args multiple times?

Paste the result of:

cat ~/.config/code-flags.conf
8

The things about the virtual keyboard i try to set it to None then when i open the window again it’s set to Plasma Keyboard again .

and about that command it shows this :
cat ~/.config/code-flags.conf

--ozone-platform=x11

9

The conf looks fine still weird that it doesn’t work consistently. For the Plasma Keyboard try removing it:

sudo pacman -R plasma-keyboard