Bug 513419

Summary:	Plasma Wayland stops receiving any keyboard input in certain apps
Product:	[Plasma] kwin	Reporter:	Mithrannussen <rmedeirosflavio>
Component:	input	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	NEEDSINFO WAITINGFORINFO
Severity:	major	CC:	duha.bugs, rmedeirosflavio
Priority:	NOR	Keywords:	immutable-base-system, wayland-only
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	NixOS
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Journalctl log log prior to switching virtual desktop log after switching virtual desktop second log prior to switching virtual desktop second log after switching virtual desktop

Description Mithrannussen 2025-12-15 22:47:15 UTC

Created attachment 187688 [details]
Journalctl log

Hi!

I am having an issue that has been bothering me too much since the 6.4 release, and it continued until in the 6.5.4 bugfix update.

Running the Plasma Wayland Session, everything is as expected, except that at certain times a few applications simply stop receiving any keyboard input (either from the laptop or from my external usb keyboard). Everything outside those programs works, the Plasmashell, other apps and the TTY sessions.

The affected windows are still visible and can be normally interacted with mouse input.

A few observations:

The problem does not occur in the X11 session.

It does not happen on any other Wayland-based tiling WM I tried (Niri and Hyprland) or Cosmic and Gnome.

It wasn't an issue prior to the 6.0 release.

Not only that, but it isn't exclusive to my distribution (NixOS 26.05). Already tested on Arch and Fedora 43/Fedora Kinoite 43 and had the same issue.

Doesn't seem to be related to apps running on Xwayland mode (currently the only xwayland program I have running is the Steam Client, which is unaffected). The running apps that isn't accepting any keyboard input are a Qt-based WhatsApp client and Discord/Vesktop, but I've already encountered the same issue with Brave-browser.

I executed xlsclients to determine any xwayland running program.

I think it isn't related to Nvidia open-kernel modules (I should test it more, though).

It isn't a kernel issue, tried the default kernel in Fedora and Arch and with them both the same issue appear.

-----------

Currently, no affected program is Flatpak. But I previously encountered the issue with ZapZap and Discord installed as Flatpaks.

Running journalctl-r I found no significative error lines, other than the following which are heavily repeated throughout the log:

plasmashell[2852]: vaExportSurfaceHandle failed

I found the following bug report that seems to describe something slightly similar to what I am facing, other than the fact the rest of my OS remains functioning normally, and I have no issue when dealing with the SDDM login screen.

https://bugs.kde.org/show_bug.cgi?id=511611

-------------

Operating System: NixOS 26.05
KDE Plasma Version: 6.5.4
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.1
Kernel Version: 6.18.0-zen1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × 13th Gen Intel® Core™ i5-13450HX
Memory: 16 GiB of RAM (15,3 GiB usable)
Graphics Processor 1: Intel® Graphics
Graphics Processor 2: NVIDIA GeForce RTX 4050 Laptop GPU
Manufacturer: Dell Inc.
Product Name: Dell G15 5530

Comment 1 Vlad Zahorodnii 2025-12-16 10:40:03 UTC

Please provide more steps to reproduce, what apps are affected, what likely triggers the bug, etc.

Comment 2 Mithrannussen 2025-12-16 18:54:23 UTC

(In reply to Vlad Zahorodnii from comment #1)
> Please provide more steps to reproduce, what apps are affected, what likely
> triggers the bug, etc.

Unfortunately, what I wrote is the most detailed I can be as of this moment. I cannot follow specific steps to replicate the issue nor determine a set of affected applications, as I said I already encountered the problem with Brave, ZapZap and Discord/Vesktop.

It seems random, obviously there should be an underlying reason, but nothing I can notice or determine. It also happened prior and after suspending to RAM, so that likely isn't the cause. 

I will try to use the Wayland session longer and discover more about this problem. However, I shared it, even with very little technical descriptions or logs, to see if anyone else was facing anything similar or ideas on how to better investigate it.

Comment 3 Mithrannussen 2025-12-17 05:58:39 UTC

Created attachment 187722 [details]
log prior to switching virtual desktop

Comment 4 Mithrannussen 2025-12-17 05:59:23 UTC

Created attachment 187723 [details]
log after switching virtual desktop

Comment 5 Mithrannussen 2025-12-17 06:01:07 UTC

I have managed to determine a set of steps to reproduce the issue in my machine.

It is a requirement to have multiple virtual desktops configured. Traditionally I have enabled eight and at the beginning of each session four of them are automatically occupied by a few autostarted apps.

However, if I initialize a session with all my opened programs within a single desktop, I can use the Wayland session normally.

As soon as I move any program to another virtual desktop, almost immediately a program will no longer react to any keyboard input.

The affected program is sometimes not visible when alt-tabbing, but I can move it to another virtual desktop within the overview effect, while it becomes visible again, the keyboard input issue remains.

I already noticed the issue with the following programs:

Firefox (native)
Brave (native and flatpak)
Audiotube (flatpak)
Vesktop/Discord (native)
Zapzap (native and flatpak)
Whatsie (native and flatpak)


I saved the journalctl output in four different moments, in pairs of before and after moving a window to a different virtual desktop.

In all logs, the following output remains repetitive:

vaExportSurfaceHandle failed

Comment 6 Mithrannussen 2025-12-17 06:02:28 UTC

Created attachment 187724 [details]
second log prior to switching virtual desktop

Comment 7 Mithrannussen 2025-12-17 06:03:00 UTC

Created attachment 187725 [details]
second log after switching virtual desktop