I’d like to try to get fedora to host a second headless Wayland session in the background for a remote user. I have a GPU but I want to share its render and compute, not the physical HDMI output, so I need a virtual Wayland session for the second seat.
Supposedly logind could handle the seat and udev permission issues clean enough, but headless use is still beyond me there.
I’d like a KDE Plasma environment running headless and then sunshine can just stream this session out using the war capture method. I just don’t know how to start up a separate Wayland session under another linux user in the background with a plasma session drawing to an imaginary monitor.
There seem to be 2 ways of doing this.
- wlheadless-run - a young project made to solve this particular problem
- kwin --virtual can theoretically do this, but I’m not finding clear examples of it
Just use wolf: https://games-on-whales.gitbook.io/wolf/stable/en/user/quickstart.md. Everything is ready out of the box. However, for a KDE session, you’ll have to rebuild KDE in the container instead of wolf-ui.
Wolf has opinions I disagree with. I could wrestle with containers OR look at the recent advances in Wayland, KDE (catching up to GNOME on this one for once) and classic Linux multiseat was easier than taming container security.
Wolf is better with temporary bring up and tear down. Honestly, probably not going to beat it there. But I want reusable instances and containers are needlessly complex for that.
Anyway, I got the last part of this solved this afternoon. Expect a how-to once I put it on the target system and confirm this process works there as well as my test rig.
Because of the Wayland architecture, you simply cannot do it differently. Because Wayland is not a window manager, but a subsystem for working directly with video. This is not a new X11 server, it’s a different architecture. Therefore, by default, no matter where you choose, the render will be output to tty0 of your main server. You have only 2 options - use Wolf as is or manually assemble https://github.com/games-on-whales/gst-wayland-display and limit it to one video card via systemd. gst-wayland-display literally forcibly transfers the render not to tty0, but immediately to the stream for Moonlight.
So it’s not that Wolf is too complicated, it’s just that what you want is a rather complicated case.
UPD: although it is possible that you will be able to do this using wlheadless-run, but this will most likely be worse in terms of performance compared to gst-wayland-display. Although for a simple KDE session, I think there is no difference.
UPD2: I checked and, as I thought, regular applications will get along fine if you run them through wlheadless-run, but everything that requires vulkan may break. it’s the same with video cards. Simply specifying primary will not guarantee the use of a fixed card. But just for office work, I think it will be fine. however, as soon as the case starts to go beyond the standard, everything will start to break down if you have more than one GPU.
I was investigating this some time ago when I wanted to remote login into my work PC on my local network so that I didnt need a KVM or multiple monitors and peripherals.
Fundamentally this works great in X11 because the core required for this is implemented in X11. Meaning it was easy to create software for this use-case no matter the DE.
Wayland is much more “hollow” in this regard. A lot of features that were core to X11 have been offloaded to the window manager. And by offloaded I mean “we do not handle this stuff, figure it out DE devs!”
This means that for what we want, the DE itself needs to implement it. Gnome does have a remote login feature that might fit the bill. KDE has made 0 attempts at implementing it. Not sure where the rest stand.
Well x11 was built from the ground up to solve this exact problem. Wayland was built for a more direct use case, then had to backpeddle when they realize that’s not the only way to use a computer so they either adapt or create and maintain a second stack.
Wayland is striking a pretty responsible balance here. Compositors are taking a bit to settle down on this bit it’s there. Wlroots and gnome had it best but KDE recently made enough improvements that I consider this matter settled from their side too. Cosmic, budgie, etc will be in limbo for a while.
Anyway I found out a method that works and it’s actually surprisingly clean and versatile. I just need to document and deploy. Expect a write up. I’m pretty pleased with my findings so far. There’s some old-world Linux ideas that worked really well here.
If you actually found a solution I would be very interested. Looking forward to it!
