Anyone knows how to properly start a multiseat wayland with a desktop environment or window manager running?
I just need simple stuff such as profile initialization of the user and if it’s possible to just share the same discrete GPU across multiple seats?
The end result? I want to isolate my current user space from the gaming space where I can just connect using moonlight/sunshine. I want it all headless.
@[email protected] That looks amazingly promising regardless. I’m still bummed and a bit confused on the one shared GPU business I thought it wouldn’t matter if you ran multiple graphical applications regardless or is this imposed by Wayland at the moment? If not wayland would X11 do the same?
Just throwing questions more out of curiosity.
How… do you find all these pieces to glue together? Who or what is putting these out there “hey I want to initiate an desktop env”
Thank you!!
Painful reading of the manuals. You really need to know what you’re looking for, what keywords to search. I also played around a good bit with SDDM’s source code to piece it together/see a working example.
Some docs
It’s mostly that on Linux, GPUs are a bit all or nothing at the moment. You can have two sessions running, but only one of them can be active at a time. You can’t have one on one monitor and one or another. Well technically you can, but people basically run Sway with a full screen nested compositor on each monitor.
Technically there’s nothing preventing the creation of a headless compositor with GPU acceleration. It’s just such a niche use case I don’t know of any compositor that lets you do that. They use nested compositors for development, but those still need a window on the parent compositor.
X11 won’t save you there, people use specialized headless servers for that like xvnc (not to confuse with x11vnc which runs as a X11 client) or xephyr because Xorg can’t do headless on its own that I know of.
My use case was barely slightly less niche than yours: I wanted Steam big picture on my TV at all times, independently from my main session so I can just pick up a controller and play. That’s possible, I got it to launch, but in the end there was too much mixing in with my daily system I figured I kinda want a clean install with just the necessary packages, so I ended up back with VFIO.
@[email protected] Just to pick your brain and sorry for asking so many questions but what if from what you said nested compositors/clients/etc I could just create a separate virtual screen and have WAYLAND_DISPLAY=wayland-1 (or 0:1) wouldn’t I be technically be able to capture that and project it for my needs?
I guess I’m just jumbling/reorganizing my mind with this new information. I feel like the question would be “can I create a virtual monitor within a parent session?”
Anyhow, thanks again!
The problem there is really getting a compositor to run. By the time you have something to set WAYLAND_DISPLAY to, you already have solved the problem because you have a headless compositor running.
I did a little bit more research, and it seems at least wlroots compositors (Sway, Hyprland, Gamescope) do support headless with
WLR_BACKENDS=headless(from this Reddit thread). Kwin apparently has a--virtualflag. Now I’m not sure that will result in a compositor with graphical acceleration, maybe it will if there’s a GPU available?The main issue remains those are usually used for testing or remote desktop situations, like running GUI apps in CI and testing them. So they’re not very well documented nor all that well tested and supported.
Happy to help, I spent days on this so I’m glad to share the information! Feel free to ask more questions.
@[email protected] Anyhow I think I should be good. That was all super interesting looking at the freedesktop documentation it does answer some things I was wondering about myself.
Now I don’t think I feel in the mood to toy with creating my own display manager, maybe as a pet project but man I can’t imagine anyone new be like “so there’s a centralized documentation/communication channel for all of this, right?” 😆
I’ve contemplated making a blog series on it, but that involves finding time to actually make it work reliably and not hacked together, and also I guess setting up a blog for it. Ultimately I would be building a micro-DM of sorts that’s a one-shot command line where you give it a user and a session name, and it spawns the session correctly, with the goal to be able to run this alongside another DM like SDDM or GDM.
But yeah the documentation on this is pretty sparse, it’s very developer oriented and mostly used by people already in the deep ends of systemd and Wayland, ie. Gnome/KDE/wlroots developers. Also technically the Python script I shared is sort of v1, I have another version in Rust that goes through PAM and simulates a more accurate session startup. If you read the DBus API docs for login1, the function I’m calling is technically reserved for PAM. But PAM is like, a whole other thing. It fixed some issues and introduced a bunch more.
It’s a good step in the right direction but there’s still not really a good concept of headless seats, right now a seat will only be marked as graphical if it’s got a GPU attached to it, and you can only attach a GPU to a single seat at a time (at least via loginctl).