| 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: | input | Assignee: | 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
What version of Plasma/KWin does Rocky Linux 9 offer? (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. 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 (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 (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! (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. 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?
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.
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. ๐๐งน โ ๏ธ 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! ๐๐งน This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME. |