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.
@Max_P 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?” 😆
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).
@Max_P 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).