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] 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).