 So my talk is about first of all, hello, my name is Marcel. I'm from Germany. I'm still a student and yes my talk is about spawning and What spawning is is basically nothing else than a service which is offering you log-in capabilities You made now you might now say that this sounds familiar from something like XTM and yes it's basically the same but how it works is differently and The basic approach of this whole thing is That we are trying to unify how a user logs in and how a developer logs in and How I've seen it in the past few years is usually a developer of a window manager goes to a TTI logs in using a getty and Has a clean session and the user has his Demon like XTM or entrance or like the M and logs in using a UI and there We have a little problem because on something like like the M you might not start the window manager in a clean session Like the developer starts it using a TTI running start X because he has a fresh X server, etc, etc so the basic approach is to unify this and so The idea is there should not be a difference between you logging in from a virtual eternal using a getty or using spony and a graphical user interface to log in and How this works is basically by copying how a getty works on a normal system So what a getty does is it sets up the virtual journal for you. It sets up the file descriptor Zero one and two for you so standard Standard in standard out and standard error and just passes this on to the next process So what spony does in the internal things is there's a demon which is doing one set of operation And this is it is the demon is forking into a new process This process locks in the user using Pam After that it acquires a new virtual journal. It sets the correct user permissions on it It sets the correct file descriptors and then it just starts a binary for example the greeter binary for bringing up a greeter or binary like Weston or a binary like Start X to run X seven what you can see here now is already we don't depend anymore on the architecture of X So it doesn't matter for this system if you are starting a wayland compositor Or if you are starting a X compositor X window manager or even just a plane bash on your virtual journal without involving any graphical device And as those systems are working at some point you need a place where you can interact with the user and this is usually called for me the greeter and Spony itself only carries a text mode greeter. This means what you see on your screen It's just a text mode virtual journal. So without graphical output just a normal the normal characters as you see them on boot and The reason for doing this is on one side I didn't want to pull pull in any major Toolkit into spawning itself spawning itself should stay as tiny as possible so it could get integrated in many different places really easily and The other positive point about this is we are having a binary that can be used for logging in users For the case that a graphical mode of a virtual terminal fails So I'm sitting quite often in front of my work laptop after our update and sitting in front of a black screen because some driver issue happened and Lady I'm cannot come up anymore and cannot draw anything on the screen So the idea here is and what spawning actually does is it checks if the greeter is really starting up successfully a graphical mode Greeter for example, and if this is not happening for let's say two times It starts the fallback greeter, which is the text mode greeter So in the end we are promising the user in some kind that he's always ending up with a lock screen Which is working probably not looking nice, but it's at least working for example for the case of a driver issue He can then drop to his bash fix the system reboot and he is back at the graphical system. So in the best case However, since users like nice you eyes, there's also the possibility of a graphical greeter and this graphical greeter is Outside of the main repository. It's in a different repository The greeter is called Anna and looks like this It's using EFL as graphical output and runs there in the plain DRM session on the virtual journal However, the special thing on this greeter is how it uses spawning. So the big story Big story packed in a short sentence is spawning is using mason. Mason is a built system I don't know maybe one or the other knows it and Mason has one wonderful feature and this is you can include other mason projects in Your own project and this is what Anna does So for example in a distribution where you don't have many packages and you don't have a new software like spawning You can just deploy your greeter by using spawning in your repository so the distribution only would have to deploy your greeter and not also spawning and Your greeter for example for me on Arch Linux. This means I can have a single User Arch Linux repository built script which builds me the greeter and I can just deploy it like this to the users Without forcing them to build two packages, which is way easier The good thing also in spawning is you can just execute in the end of binary Which sets the default greeter to some path. So in the end for the user He doesn't for end user He doesn't seem at all see at all that there's something happening in the background with composing to two pieces of code However this started for me like a little research project so I Wanted to improve how the normal lock-in screens on Linux work and I wanted to have something that doesn't depend on something like GTK or QT or elementary So many projects can use one base and so since this is a research project somehow for me There are a few future goals where I would like to work on and where I wanted the project to go For example one thing that I've recognized and already said before there are sometimes Greeter hang-ups in terms of the greeters in terms of the driver. So the driver has some kind of issue and Cannot get further or back and this would be something that I would like to monitor So somehow that the greeter detects if there is a graphical issue and just exits in itself or spawning kills the greeter So the user in the end again ends up with a usable system instead of a locked system Also, which what is missing right now? But I want to have implemented is support for finger readers or smart card readers or anything like this right now This is not working because on the one side. I don't have the hardware to test and on the other side I've checked it once and there it was Pam starting some x-windows that you were seeing in your x-session and Since the for example a greeter like Anna runs in a DRM session and not in a x-session We don't have the possibility to bring such a window up So this is missing and other research project I was thinking of was to get a sequel lock screen which was something like Do not only use the greeter for logging a user in but also for Locking a session back. So if you are locking your session, you don't see the compositor bringing up a password field But rather get back to the greeter in the beginning and you have to log in again to get back to your session Which would be somehow a bit cleaner because Session itself does not need to implement something like a lock screen again However, this was basically it the takeaway from this should be in the end Spawning is nothing else than a graphical front end for using a greeter and the greeter is the standard way for a long time Logging into a Linux system for example The focus is on keeping a responsive system to the user. So no one is ever forced to do USB boot or something like this to get his system back up working and this whole thing is Undependent from the X server so we can start any session in it Yeah, that's basically it any questions do That was the short story the long story is you can decide if you want to have it in two packages or one Packaging when it doesn't exist. Yes, exactly. That was the use case. So you just keep it easy for the user for deploying it Yes The architecture is like you have a demon In the middle so to say which is called SP demon that is running as rude and outside any session So it can create other sessions which are recognized by something like log indeed and As this for King is happening and then the forks are running and the users Where you are logging in and for example the greeter itself is running in a user that doesn't have a home directory I think it has a home directory, but this is empty directory. It does not have rights to do anything basically at all and so yes The base thing is running as rude because this is needed to do all the stuff But in the end the lock screen for the users not running his route. No, just wanted to say developers like me Always use a login manager. I don't be static. So I've done that for 20 plus years building window manager So I'm not sure I'm not sure you're described description of yeah, okay But it was a it was a quick question on IOC and there have been already many which said okay Yeah, TTI logging in start X Are there other questions myself, thank you very much