Chrome Remote Desktop and Wayland

[Ray Strode]

Hi,

On Tue, Apr 21, 2020 at 8:21 AM Benjamin Berg <bberg at redhat.com> wrote:
> 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.
why does that information need to be conveyed? who would consume it?

> > 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.
So to be clear, I've been advocating for mutter/gnome-shell to do the
attaching *themselves*. We don't need any new api for them to do
that.

If mutter is already running, it just needs to set up a sd_login_monitor
to detect when a new session for the user show up. As soon as a
new session is registered with logind, that new session is announced.

mutter can then check the session type of the newly registered session
and see if it needs to add a new output (to e.g. pipewire or to kms).

This can be done using api that exists today (well we need a new
session type, right now there's only tty, x11, wayland, mir, unspecified,
we need pipewire too)

> 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.
Right, mutter shouldn't be guessing which session to use. it should use
all of them! it may use some logic to figure out where window go (e.g,
last that went active wins), but all active sessions should get chrome.

> 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.
Totally agree with these words, but I also think that's precisely what a
"user" is in logind. i don't see any advantage to having something between
user and session that's basically the same as user.

> Sorry, I meant the desktop here.
ah okay.

> 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.
You're saying a user wants to log into KDE on X11 and GNOME on wayland
at the same time, and both use systemd --user?

First, I think that's a fairly niche use case that cause problems for the user
(e.g., what if they try to run firefox in both?)

But I don't think there's anything that would prevent it from working.

logind lets a display server query whether or not a session is KDE or GNOME.
See sd_session_get_desktop . Each display server, should clearly only
manage sessions registered for their own desktop.

> > >  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.
I still don't understand. Is this in the context of KDE and GNOME ?

--Ray