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.
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!
iirc for GPU acceleration you need to make the GPU pretend to use one of it’s ports (you don’t actually need to plug anything into it)
nope I got around that. I don’t need video, just the render node. dma-buf pulls it from render to encode without passing through the CPU or system ram.
now I just need to figure out the udev multi seat crap. seats expect physical hardware to be assigned to them.
If you log in (preferably as another user) to another tty (Cntrl + Alt + F2/3/4/5), and then run
dbus-run-session startplasma-wayland, does that work?Sometimes just
startplasma-waylandworks, which used to work for me but didn’t work for me this time.Then, you should be able to switch back to the original KDE session, which continues to work normally, at least it does for me. Both sessions should have shared access to the GPU, as well. You can then probably run sunshine in that second instance of KDE, while the monitor can be attached to tty1 or tty2, whichever one is the default where KDE is put.
Then, you would probably want to configure sunshine to work even when the screen is locked, that way you can lock the second session with Win + L, but it can still be interacted with remotely via sunshine.
EDIT: I only am somewhat confident that this setup will work, I haven’t tested it personally.
I would need to use the headless backend in kwin, which apparently isn’t something you can do from start plasma-wayland but you can do with kwin_wayland --virtual -s waylandR. I can give it a specific socket (waylandR) which lets me point sunshine at that, but I cannot get moonlight to accept a PIN that way. it seems mad about this setup and I’m not sure why.
Do you actually need the headless backend? Or do you need a background session that doesn’t interfere with the main session?
the physical display output is claimed by something else totally separate.
Anyway I did figure out how to the headless backend working, but I did not figure out the udev rules for this headless session
Allows Sunshine to access /dev/uinput
KERNEL==“uinput”, SUBSYSTEM==“misc”, OPTIONS+=“static_node=uinput”, GROUP=“input”, MODE=“0660”, TAG+=“uaccess”
Allows Sunshine to access /dev/uhid
KERNEL==“uhid”, GROUP=“input”, MODE=“0660”, TAG+=“uaccess”
Joypads
KERNEL==“hidraw*”, ATTRS{name}==“Sunshine PS5 (virtual) pad*”, GROUP=“input”, MODE=“0660”, TAG+=“uaccess” SUBSYSTEMS==“input”, ATTRS{name}==“Sunshine X-Box One (virtual) pad*”, GROUP=“input”, MODE=“0660”, TAG+=“uaccess” SUBSYSTEMS==“input”, ATTRS{name}==“Sunshine gamepad (virtual) motion sensors*”, GROUP=“input”, MODE=“0660”, TAG+=“uaccess” SUBSYSTEMS==“input”, ATTRS{name}==“Sunshine Nintendo (virtual) pad*”, GROUP=“input”, MODE=“0660”, TAG+=“uaccess” SUBSYSTEMS==“input”, ATTRS{name}==“Sunshine PS5 (virtual) pad*”, GROUP=“input”, MODE=“0660”, TAG+=“uaccess”
this is…not enough
the physical display output is claimed by something else totally separate.
Yes, and the above solution I laid out is a way to get around that, that potentially dodges the complexity of configuring a truly headless session. It’s possible to run two KDE sessions at once, next to eachother, and then simply put one on the main display, with the second being “headless”, and not shown.
I started fiddling with the above setup I described, actually installing and testing sunshine. Unfortunately I hit some hiccups. I got sunshine to run, but with no input, and then then it attached to the wrong KDE, even though it was streaming the correct one initially. Now I’m running the same KDE session as a different user (since I was on the same user before), but having pairing issues, but I suspect these are because moonlight is seeing the wrong SSL cert, since the sunshine as a new user generated a new cert.
Sunshine has some documentation gaps that are annoying to figure out but there enough there you can get it done with some effort. Moonlight feels really crunchy though. Edges are rough and it always felt unfinished. I really think selkies v2 is going to kill it.
Sunshine+moonlight is better for an app based deployment, like set top boxes without web browsers. But if you have a browser available on the client, I can see some crazy possibilities with selkies.
Gamesonwhales solves the sunshine multi user issue in a different way. It’s better for renting out your box as a node for cloud gaming. It’s damn near turnkey for that and super clever. But that’s not what I’m trying to do here so it’s just adding complexity.
Second comment:
https://docs.lizardbyte.dev/projects/sunshine/v0.21.0/about/guides/linux/headless_ssh.html
There is also this guide, but it is specific for Xorg and Nvidia gpus. But I suspect that if you replace the
startxhere withstartplasma-waylandordbus-run-session startplasma-wayland, then it will work. It would still be nvidia gpu specific though.that won’t work. that only applies to X11. Wayland doesnt work that way.
