Chrome Remote Desktop and Wayland

[Jonas Ådahl]

On Wed, Apr 22, 2020 at 04:34:01PM -0400, Ray Strode wrote:
> 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)

Can't the remote login session still be "wayland", but without being
able to be drm master? We still need API to manage the pipewire streams
(add/remove/change virtual outputs, inject input, i.e. something like
org.gnome.Mutter.RemoteDesktop/ScreenCast); would adding a new session
type bring us anything useful? We wouldn't just implicitly spit out a
pipewire stream for some made up output, I assume we still want it to be
managed some how by the remote desktop service.


Jonas

> 
> > 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel