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.
You may be interested in a project called “wolf”.
Its goal is to run graphically accelerated containers using a Wayland compositor that uses gstreamer as the backend instead of a display. After that, wolf serves as your moonlight server.
There are hoops to jump through if you’re using Nvidia, and the software is very young. But I think it shows promise.
I’ve tried it and it went horribly. By default it doesn’t stream your desktop, just some apps so I tried to change the config file according to their docs but made a mistake, now it’s brokie. I deleted the config file and the entire /etc/wolf directory but it’s still fricced. (I am on Mint and used podman-docker instead of real docker)
Before I broke it, I could open up a black screen which should in theory be a sign that it’s still installing stuff in the container but I was too inpatient to find out.
I suppose the bottom line is that it’s still in alpha. I might try it again with the help of their discord or something when I get time for it but idk when that will happen lol.
And a mention of custom EDID for a monitor to be registered huh . Guess I’ll follow up on this as well eventually, less work setting things up and more things to learn.
How many GPUs do you have? If only one, not possible, at least not easily.
But, to answer the question, yes I know. It’s kind of a mess because the API is very much designed around display managers. Basically you need to call some DBus functions after authenticating the user but before dropping privileges to register the user with logind. The result of that is some permissions are modified to your user so the compositor has access to keyboard, GPU, mouse, etc. That makes running two sessions of the same user really hard because that lets the compositor try to grab the same resources as the other session.
Here’s the script I had made, but I ended up just using a VM for a while since I wanted to also isolate installed packages and whatnot so it’s barely enough to start gamescope.
#!/usr/bin/env python3
import os
import dbus
sysbus = dbus.SystemBus()
login = sysbus.get_object(
"org.freedesktop.login1",
"/org/freedesktop/login1"
)
manager = dbus.Interface(login, dbus_interface="org.freedesktop.login1.Manager")
manager.CreateSession(
1001, # u uid
os.getpid(), # u pid
"tv", # s service
"wayland", # s type
"user", # s class
"gamescope", # s desktop
"seat1", # s seat_id
0, # u vtnr
"", # s tty
"HDMI-A-1", # s display
False, # b remote
"tv", # s remote_user
"localhost", # s remote_host
[]
)
os.execve("/usr/bin/fish", ["--login"], { "XDG_SEAT": "seat1" })
Run it with
sudo systemd-run --system --scope
This will make systemd create a fully detached session from your user, so you can su to a different user, run PAM modules, start the XDG session.
@Max_P 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”
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”
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.
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?
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.
@Max_P 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?”
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 --virtual flag. 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.
@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).
You may be interested in a project called “wolf”. Its goal is to run graphically accelerated containers using a Wayland compositor that uses gstreamer as the backend instead of a display. After that, wolf serves as your moonlight server. There are hoops to jump through if you’re using Nvidia, and the software is very young. But I think it shows promise.
https://games-on-whales.github.io/wolf/stable/
I haven’t tried it myself yet, if you give it a go, let me know how you get on. 🙂
I’ve tried it and it went horribly. By default it doesn’t stream your desktop, just some apps so I tried to change the config file according to their docs but made a mistake, now it’s brokie. I deleted the config file and the entire /etc/wolf directory but it’s still fricced. (I am on Mint and used podman-docker instead of real docker)
Before I broke it, I could open up a black screen which should in theory be a sign that it’s still installing stuff in the container but I was too inpatient to find out.
I suppose the bottom line is that it’s still in alpha. I might try it again with the help of their discord or something when I get time for it but idk when that will happen lol.
@jac Hey, thanks for sharing!
They have a lot of useful information.
cc mostly in case if you find it useful @Max_P wayland headless https://games-on-whales.github.io/wolf/stable/dev/wayland.html
https://games-on-whales.github.io/gow/monitor.html#_force_xorg_to_use_a_custom_edid
And a mention of custom EDID for a monitor to be registered huh . Guess I’ll follow up on this as well eventually, less work setting things up and more things to learn.
How many GPUs do you have? If only one, not possible, at least not easily.
But, to answer the question, yes I know. It’s kind of a mess because the API is very much designed around display managers. Basically you need to call some DBus functions after authenticating the user but before dropping privileges to register the user with logind. The result of that is some permissions are modified to your user so the compositor has access to keyboard, GPU, mouse, etc. That makes running two sessions of the same user really hard because that lets the compositor try to grab the same resources as the other session.
Here’s the script I had made, but I ended up just using a VM for a while since I wanted to also isolate installed packages and whatnot so it’s barely enough to start gamescope.
Run it with
This will make systemd create a fully detached session from your user, so you can su to a different user, run PAM modules, start the XDG session.
@Max_P 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.
@Max_P 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.
@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).