Bug 510401

Summary: When running applications inside of a distro box container my keyboard does not function in any of the applications
Product: [Plasma] kwin Reporter: HelpHQ <barton261>
Component: inputAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED WORKSFORME    
Severity: normal CC: duha.bugs, kdedev, madness742, nate, xaver.hugl
Priority: NOR    
Version First Reported In: 6.4.5   
Target Milestone: ---   
Platform: EndeavourOS   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description HelpHQ 2025-10-08 18:13:35 UTC
I posted this on the distrobox bug tracker and as a result it was determined by my testing that there may be a kwin issue when translating inputs into a distrobox container application that needs x11 inputs. I've pasted everything below. I hope it is helpful: 

Describe the bug
When running applications inside of a distro box container my keyboard does not function in any of the applications.

To Reproduce
Host system: EndeavourOS (KDE)
Distrobox Container: Rocky Linux 9 (using podman)
Primary Application: Davinci Resolve Studio 20.2.1

Expected behavior
I expected the keyboard to function as a normal input device.

Logs
There's were no errors its just like I don't have a keyboard plugged in. Mouse works fine.

Desktop (please complete the following information):

Distrobox 1.8.1.2-1
Podman 5.6.2-1
Host EndeavourOS Mercury Neo

How did you install distrobox?
Sudo pacman -S distrobox
Additional context

Initial Find/Testing: 
I added this before starting the container
GTK_IM_MODULE=xim QT_IM_MODULE=xim XMODIFIERS=

It didn't work. I then logged out of my Wayland session and logged into an X11 session. Keyboard functions fine inside container under X11 however the container does not have access to sound inputs or outputs because none of that stuff worked. Under X11 I also was unable to render a video. It said 15 hours to render a 6 minute video in Davinci Resolve. In Wayland the video rendered in 30 seconds. I did also try to use other applications in my Wayland session and the keyboard did not work in any of them (kdenlive, libre office).  I also created an Alma Linux 9 and a Fedora 37 container and I have the exact same issue. No keyboard input in any of the installed applications. This was to see if the issue was with the Rocky 9 container. 

Update 1: I redid this entire thing on my test bench running Liya Linux (Arch base). This distro utilizes X11 only and does not come preinstalled with wayland. It uses the Xanmod Kernel over Arch Stable and uses the Cinnamon DE. Installing the same rocky 9 container everything works (keyboard, sound, mic inputs..etc). I have GPU acceleration in DR. DR loads and runs fine and the keyboard works in all apps. So now I have to figure out why on my main editing rig running EndeavourOS is having these issues. It's not an Arch specific problem as I just ruled that out. Its either a KDE / Wayland Issue entirely or I need to see if the standard Arch kernel is somehow the problem.

Update 2: Changed EndeavourOS kernel keyboard issue is still present in Wayland. No sound or working inputs except mouse and keyboard in X11 KDE session. Just to see if it was perhaps EndeavourOS and the way it is compiled I installed CachyOS on a separate partition and experienced the same exact issues using a KDE Wayland session.

Update 3: Back in EndeavourOS I tried using XDG Portals but that didn't fix it. After extensive testing I've determined the issue is a KDE Kwin specific issue as using Mutter in a Gnome Wayland session works without any issues. Also as previously stated using X11 only DEs work fine as well too. Oddly enough an X11 KDE session resolved the keyboard issue but then created sound issues. Hopefully Kwin gets an update that resolves this in the future. For now I'm just switching to gnome .. sadly.
Comment 1 Nate Graham 2025-10-08 19:29:46 UTC
What version of Plasma/KWin does Rocky Linux 9 offer?
Comment 2 HelpHQ 2025-10-08 19:37:58 UTC
(In reply to Nate Graham from comment #1)
> What version of Plasma/KWin does Rocky Linux 9 offer?

Rocky Linux does not natively come with KDE Plasma as it is a fork of Red Hat. It ships with Gnome. KDE can be installed if you add the EPEL Repository. I did not do this because when running a distro in a container like distrobox there is no DE. It's all CLI. All of the core packages are there to load the container and then you install any applications and dependencies you need to run the application.
Comment 3 madness742 2025-10-13 20:01:23 UTC
I'm having a somewhat similar issue with my inputs when using Davinci Resolve in a podman container.

I created a podman container, using toolbox, for Davinci Resolve. But when I interact with the program my entire desktop (including mouse input) will freeze for a couple of seconds. When I switch to a X11 session, only the application and desktop will freeze, but I'm still able to move my cursor around.

Not sure when this started happening, but it used to work fine in the past.

These steps allow me to reproduce this freeze every single time:
1. `toolbox create --distro fedora --release 42`
2. `toolbox enter`
3. Install Davinci Resolve 19.1.4, 20.1, 20.1.1 or 20.2.1 
4. Start Davinci Resolve
5. On the Projects screen, select import and quickly hit ESC to close the file picker.

I've also tried an Ubuntu image, and manually installed the ROCm packages.

My keyboard inputs however do work fine in LibreOffice, and audio output is working as well in MPV. These two programs did not cause any freezing during the short time I interacted with them.

Does this issue belong in here, or should I create a separate bug report?

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: 32 ร— AMD Ryzen 9 7950X3D 16-Core Processor
Memory: 64 GiB of RAM (61,9 GiB usable)
Graphics Processor 1: AMD Radeon RX 7900 XTX
Graphics Processor 2: AMD Radeon Graphics
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7D75
System Version: 1.0
Comment 4 TraceyC 2025-10-14 20:02:55 UTC
(In reply to HelpHQ from comment #2)
If you're running KDE Plasma inside the distrobox, can you paste the output of `kinfo` into a reply? Thanks
Comment 5 TraceyC 2025-10-14 20:03:53 UTC
(In reply to madness742 from comment #3)
> I'm having a somewhat similar issue with my inputs when using Davinci
> Resolve in a podman container.
> 
Your issue sounds different. In the original issue, no keyboard input makes it into the distrobox container. Please open a new report for your issue. Thanks!
Comment 6 HelpHQ 2025-10-22 21:11:08 UTC
(In reply to TraceyC from comment #4)
> (In reply to HelpHQ from comment #2)
> If you're running KDE Plasma inside the distrobox, can you paste the output
> of `kinfo` into a reply? Thanks

** There is not a desktop environment running inside of distrobox. **

By default, Distrobox does not load a full desktop environment (DE) when you run a container.

Its main purpose is the opposite: to deeply integrate applications from the container into your existing host desktop environment.

How it works:

Host DE: You run your normal desktop (like GNOME, KDE, etc.) on your main (host) operating system.

Enter Container: You run "distrobox enter my-container" and get a terminal prompt for the containerized OS (e.g., Ubuntu).

Run GUI App: If you install and run a graphical application (like firefox or gimp) from within that container's terminal, Distrobox automatically forwards its display (using X11 or Wayland) so the app's window appears on your host desktop, right alongside your native host apps.

You don't see a "desktop within a desktop." You just see the single application window.
Comment 7 Zamundaaa 2025-10-22 22:50:52 UTC
There's a few tests you can run here to at least get more information.
1. If you run some Wayland native app in the container, does it get keyboard input?
    If it doesn't, please run it with WAYLAND_DEBUG=1 and attach the output of that here.
2. If you run some other X11 app in the container, does that get keyboard input as well?
3. Does setting "listening for keystrokes: always allowed" in the legacy x11 app support page make a difference?
Comment 8 HelpHQ 2025-10-24 21:51:46 UTC
Here are the results for the tests that you requested: 
1. If you run some Wayland native app in the container, does it get keyboard input?
*** I installed gedit and the keyboard functioned fine
    If it doesn't, please run it with WAYLAND_DEBUG=1 and attach the output of that here.
*** Because the keyboard worked above I skipped this
2. If you run some other X11 app in the container, does that get keyboard input as well?
*** I installed xterm and the keyboard also worked fine
3. Does setting "listening for keystrokes: always allowed" in the legacy x11 app support page make a difference?
*** I changed this setting and reopened the distrobox container as well as DaVinci Resolve Studio and the keyboard still does not work. However it will work fine if I switch to any other desktop environment. I updated to Plasma 6.5 and there was no change in status.
Comment 9 Zamundaaa 2025-10-28 17:47:08 UTC
It sounds like Davinci Resolve is broken then, and everything around it is fine. What happens if you run it with
- unset WAYLAND_DISPLAY
- XDG_SESSION_DESKTOP=gnome
- XDG_SESSION_TYPE=x11

It wouldn't be the first time that an app added DE or Wayland specific workarounds that backfired horribly later on.
Comment 10 Bug Janitor Service 2025-11-12 03:47:47 UTC
๐Ÿ›๐Ÿงน โš ๏ธ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!
Comment 11 Bug Janitor Service 2025-11-27 03:46:10 UTC
๐Ÿ›๐Ÿงน This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.