Chrome Remote Desktop and Wayland

[Benjamin Berg]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200417/838f0685/attachment.sig>