Running Xwayland GUI application on top of host desktop environment causes kwin_wayland_drm to freeze computer

[Acters]

Recently I had installed CachyOS with KDE, along with Incus to manage the lxc container.

overall, I had a decent time following some of the guides to get GUI based applications to run and even a completely separate KDE plasma DE. however, I didn’t want the separate KDE plasma DE window that I would have to tab to for controlling the GUI apps. So I was able to just run just the plasmashell, which seems to be the app launcher/task manager bar.

sudo incus exec kde-container -- sudo -u user bash -c 'source /home/user/.profile && dbus-run-session plasmashell'

this gets me a working bar and moved it to the top right of the screen. works fine and all the host apps and container apps respect both bars by not covering them at all. I have Wayland and Xwayland working. so everything is working great? not really…

Now there an issue. its fine If I run the full KDE plasma DE, which opens a window that holds the entire container’s GUI instead of just displaying on the Host’s DE, all the apps work fine. However, as I mentioned, I do not like that. Where the issue comes in is when I am running a specific GUI Xwayland app from inside the container through the Host’s DE.(tbh, I only have the one app that is using Xwayland rn)

This Xwayland app is QT5 based running under xcb. If I try to run this specific app with the native wayland QT implementation, then there is an annoying bug with the menus popping out as separate windows… this is besides the point but I feel like I should mention that this app doesnt play nice with wayland and forces me to run it under X.

Now everything seems to work fine with X, however this specific app causes the host’s screen/DE to freeze. running journalctl, I notice one outstanding message when I reproduce the screen freeze from using the app.

kwin_wayland[1090]: kwin_wayland_drm: The main thread was hanging temporarily!

well, that is the only clue I have to this problem. of course everything I am doing is basically running deep into “Here be dragons” territory. I unfortunately don’t know enough about kwin wayland’s drm to ascertain how to prevent hangups.

before you claim it is because I am running plasmashell or DBus separately. simply doing

sudo incus exec kde-container -- sudo -u user bash -c 'source /home/user/.profile && QT_QPA_PLATFORM=xcb /path/to/GUI_app'

this will launch it without plasmashell or the temp DBus. so it is something off with the kwin wayland drm hanging temporarily error.

All the guides have mostly been about running the GUI apps in their own DE/display and use ubuntu/debian with gnome/mutter.

If anyone knows how kwin wayland drm works or if I need to better integrate that with the container so that it works better, that would be nice.

at the moment, my only option is to run the app on the host, which I don’t really like because I am using the container to keep these specific apps I use separate from the main host install. you know to keep the main host files less cluttered as possible by isolating them in containers.

wayland so far is working dandy, and was by far the easiest to get up and running, discounting the fact that this specific QT5 app has poor wayland support.

[simos (Simos Xenitellis)]

@Acters

I had a decent time following some of the guides to get GUI based applications to run and even a completely separate KDE plasma DE.

Welcome!

What instructions have you followed that allows (easily) to get the full Desktop Environment (DE) from the container to appear in a window on the host?

[Acters]

Thanks for asking, I should have mentioned the posts I was reading for tinkering. I guess I quickly read through many other posts here but I forgot them so maybe only took bits and pieces here and there as grains of salt.

Incus / LXD profile for GUI apps: Wayland, X11 and Pulseaudio

Update: A profile for running GUI apps in Incus Ubuntu containers with Ubuntu 24.04 as host. Previous profiles are now here: Preliminary profile for Ubuntu 24.04 Profile for Ubuntu 22.04 with kernel 6.5.0+ Profile for Ubuntu 22.04 with older kernels The main goal this time around was to simplify the profile as much as possible. This means instead of relying on cloud-init and systemd service to remount sockets, I created a bare bone incus_ct_gui.sh script that you can push to the co…

[Overview] GUI inside Containers

If you want to have a GUI inside your Container there are multiple methods to achieve this. Factors to consider include: GPU acceleration (needed for demanding applications such as Games, Editing-, Rendering programs etc.) Security (in terms of seperation between Host and Container) Methods: With GPU acceleration: Use the Host’s Wayland/XWayland Server: [Howto] Use the Host's Wayland and XWayland Servers inside containers This is also usable for X-Server users, because some Wayland compo…

been mostly reading up what these guys posted. mostly the first guy.

if you are curious how I start the separate DE env that spawns a new display on :1 and wayland-1 then this is the command I used for spawning the new KDE plasma DE display window:

sudo incus exec kde-container -- sudo -u user bash -c 'source /home/user/.profile && dbus-run-session /usr/bin/startplasma-wayland'

by “easily” that is subjective, definitely went through hoops and tried my best to read the incus docs and other associated programs man pages when I could. do I remember it all not really but I tried my best, haha. didn’t really copy paste anything over expecting it to just work, I made sure I looked through each option carefully in a way that I could. seemingly running the /usr/bin/startplasma-wayland that starts a window for controlling this separate Display/DE is the most stable. however, since running on my host’s display is mostly stable, it is was what I really ended up choosing. the Kwin wayland drm hanging error is the only clue I have. only seems to occur for this specific app that is running on Xwayland with that QT5 xcb env flag set. running the app under wayland is just a graphical nightmare with the submenus popping out as new windows and other oddities I might have not noticed or come across.(happens when running natively wayland on host too, so not a container issue, the app probably only works with X)

I was thinking. the first link has the guy using X1 for the X socket but he still uses the host’s wayland-0? idk maybe I should keep X on a separate socket connection. just a thought

[catfish]

I have an unrelated question, how did you install kde in container? Everytime I try to do it will fail due to permission problems.

What you do is what I call nested desktop environment. And I also nest wayland in wayland, but I seldom use qt5 app. Anyway, you can try another wayland compositor and install xwayland and try the app in it:

A detail step to run desktop environment in container

Chapter I: personal experience Container installed desktop environment is too long, let’s call it gui ct. I run a gui ct for over half a year. I use it as HTPC. The biggest issues are container’s wayland compositor will freeze when playing high rate 4K H265 10Bit SDR movie even my gpu can decode it, and host will freeze when CPU or RAM overloaded. Not big issues are can’t auto login because sway(wayland) don’t support display manager, host X11 will crush if X11 container exist, host X11 need x…

[Acters]

ah yeah, I didn’t know how to call it, but I did see your post. I haven’t truthfully read it in full but rather skimmed it. I will give it a read soon.

currently my host is CachyOS with NVidia’s driver and the container being kali linux. (I know, I know it isn’t meant for daily driving, hence putting it in a container and using it for only HTB/CTFs with friends)

for kali, all I needed to do was apt install -y kali-linux-default kali-desktop-kde after setting up the container with the GPU, wayland and Xwayland through incus. It was simple as just starting the plasmashell or the dedicated KDE plasma DE after setting it up. the QT5 app in question causing the issue? IDA Pro that heavily expensive unwieldy proprietary piece of software.

which type of linux distro are you shooting for specifically? might be better to nest the same types of DE. Realistically, I am running only the plasmashell which is only the taskbar. it is basically all piggybacking of the host’s main display/DE.

There is a lot to think about, and I been slowly tinkering with it each passing day.

[catfish]

I’m using debian and alpine.

I’m confused about this:

@Acters

is basically all piggybacking of the host’s main display/DE.

Does the app show in host’s DE? If so, the app is using host’s xwayland socket, then why did it perform differently? But you did start plasmashell, and start app in container’s plasma bar, so the app should be showing in container’s DE.

Can you post this container’s config and screenshot after you open plasmashell and the app?

I guess xeye started in container’ DE won’t detect host’s x11 activities and vice verse. Can you try start xeye in host and move you cursor to the app to determine it does runs in container’s DE?

Yeah, I know my post is a mess, I’m not good at writing. The post’s basically concept is you can use host’s wayland socket to show container’s wayland compositor, and how to custom barbone wayland compositor. Your gpu is NVidia, so don’t use any wlroots base wayland compositors. You can use weston.

[Acters]

If anything I do enjoy reading your thread over all the thought process behind each decision is uniquely interesting to me.

xeyes started in the container can see the host’s X apps and vice versa(host xeyes can see container X apps). hence the warnings threads about having the host’s X server being used by the container can introduce problems with isolating them for security reasons. that is unless they are in their own separate displays.

as you can see both Xeyes are able to see between host and container. interestingly, the container’s X apps are labeled as <@my-kali> socket. unsure too much of what is going on, there is a lot I am learning about here. its only when it is running on a new display like in the posted webp video link that the host can’t see the container apps.

Anything wayland specific seems to run without issue. its that sole QT5 app running under X with the xcb plugin. at least it displays properly but spawning and closing submenus is where it all just seems to cause the display to freeze. the mouse and keyboard inputs are still working but not shown until the 5-15 second freeze stops. its all still new to me. I guess its just not worth it.

webp is too large so here is link to it. the video shows two ida instances one spawned on the host’s display, while the KDE wayland Compositor WL-0 window houses the separate KDE plasma DE which is to say it is spawned a new display and houses another IDA instance. both IDA instances only see stuff from inside the container but run on separate displays. the IDA inside the separate wayland-1/X1 display is mostly stable, while the IDA running on host introduces the display freezes. interestingly, the recording software is able to capture the freezing.

Proton Drive

I guess I could just keep this other DE open and switch to it when I need to use this specific app or whatever.

probably something good to read: KWin/Wayland - KDE Community Wiki has plenty of details about nesting sessions.