Hi, On Fri, 2020-04-17 at 11:00 -0400, Ray Strode wrote: > On Fri, Apr 17, 2020 at 8:45 AM Benjamin Berg <bb...@redhat.com> wrote: > > 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. > This concept of a "composite session" you speak of already exists in > logind. In logind nomenclature it's called a "user".
Yes, I agree that "user" is very similar. However, it cannot currently
convey any information about whether a graphical session is already
running or whether it is capable of spanning multiple logind sessions.
> > 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.
> I don't think gnome-session needs to do much beyond what it's already
> doing. It just needs to make sure systemd is told what services to
> start, if they aren't already started (which target to reach)
Well, you need some mechanism to attach the new session/seat to the
running graphical session and then watch for it to be released again.
And yes, the session leader process could be the one taking care of
that.
Now, what I was thinking was that we could standardise how this works.
That shouldn't need much API, and I was hoping that the solution could
become nicer overall.
But, the other part of this is that the situation is confusing. Right
now we assign "user" processes to one of the logind sessions by doing a
best guess. That works great as long as the user has one graphical
logind session. But, if this graphical session starts spanning multiple
logind sessions, then the choice becomes more relevant as each of the
sessions might for example have a different "Active" state.
So, having something that represents the combination of all of them
could bypass that problem in an elegant way. We would never need to
"guess" the session, we would just always return the combined "user"
session. This user session would for example be considered "Active" as
lone as any of the underlying logind sessions are active.
> > While possible, I see the disadvantages that,
> > 1. GDM/the greeter cannot know whether attaching is possible,
> GDM certainly can (and already does) know if the user already has a
> running session.
Sure. What I mean is that GDM does not really know about the
capabilities of the session leader process.
I suspect that one could add sufficient information into the sessions
.desktop file though.
> > 2. the user could try launching a different session type
> Launching different session types should be supported. I mean, if the
> user is already running a local kms ("wayland") session, and then
> starts a "pipewire", mutter should detect and handle that.
> I think it would even be possible in theory (though maybe hard in
> practice with mutter, and of dubious value) to support "x11" and
> "wayland" at the same time.
Sorry, I meant the desktop here. So if KDE and GNOME have incompatible
implementation then we may run into odd error scenarios should the user
try to change the session type while they are logged in already.
> > 3. we would likely get different implementations with varying degree
> > of brokenness.
> Not sure what you're saying here, can you reiterate?
I think the above captures it well enough.
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
