Hey, On Thu, 2020-04-16 at 14:45 -0400, Ray Strode wrote: > We don't really do a lot of this today, but one vision for the future is > something like this:
Yup, something like that. I am really not sure about the details.
I feel that this means that we conceptually have a "composite" session
that consists of multiple "normal" logind sessions. And I wonder if we
could make this singleton "composite" session an explicit concept
rather than something that purely exists implicitly.
In the "simple" implementation, we could expect each desktop
environment to handle all this themselves. i.e. gnome-session would
launch, see there is already an existing one, and then do an
appropriate call to "attach" the new seat and remain dormant until it
should/needs to be detached again.
While possible, I see the disadvantages that,
1. GDM/the greeter cannot know whether attaching is possible,
2. the user could try launching a different session type, and finally
3. we would likely get different implementations with varying degree
of brokenness.
So, if we made this a first level concept inside logind, then we
suddenly get the flexibility to reconsider a lot of legacy design
choices.
Right now to login/create a session we do:
* GDM starts helper process
* Helper does pam authentication and creates pam session,
* pam_logind moves helper into scope and attaches an FD for watching
* Helper effectively launches the user's session processes
What if, instead, the user can only have one "composite" graphical
session from GDMs point of view (which may not support multiple "real"
sessions, e.g. in the case of X11).
We can have calls in logind to manage such a composite session, i.e.:
* attach a new "real" logind session
* detach a "real" logind session
* create a new "composite" session with an existing "real" session
Session creation itself could be delegated to systemd-logind. The funny
thing is, that then GDM may never need to launch user processes. It
would go through PAM for authentication, and then from there just call
the "attach" or "create" method.
What could this mean?
1. Launching a graphical session becomes entirely the job of logind
2. GDM could solely create dummy sessions (for authentication), and
delegate the rest to logind.
3. The dummy sessions could probably be stripped down to returning
an FD, they may not even need a persistent process/scope anymore.
4. Control over the session's environment is removed from the display
manager.
Please, let's stop passing around environment variables!
5. X11 sessions requiring Xorg might be interesting. Could work by
still letting GDM start Xorg in the original session, or
standardising a procedure on the logind side.
I am sure what I am proposing here is potentially a huge pain for e.g.
flickerfree operations. But maybe letting logind start the user's
session is not completely crazy and could actually lead to a much
cleaner model overall?
Benjamin
signature.asc
Description: This is a digitally signed message part
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
