Chrome Remote Desktop and Wayland

Wed Apr 8 09:02:36 UTC 2020

On Wed, Apr 08, 2020 at 07:07:19PM +1200, Scott Anderson wrote:
> On 8/04/20 4:04 pm, Erik Jensen wrote:
> > Hello,
> > 
> > I'm currently looking into how best to continue supporting Linux for
> > Chrome Remote Desktop given the current direction of development for
> > graphical sessions on Linux, and would like some community feedback as
> > to the best path forward.
> > 
> > Chrome Remote Desktop currently works on Linux by spinning up its own
> > Xvfb server and running a graphical session in that. However, as more
> > and more parts of the stack assume that a user will have at most one
> > graphical session, this is leading to more breakage more often. E.g.,
> > several distros have switched DBUS to using a single session bus per
> > user, which only supports one graphical session, and recent versions
> > of GDM will fail to log a user in locally at all if a Chrome Remote
> > Desktop session is running due to
> > https://gitlab.gnome.org/GNOME/gdm/-/issues/580. Given that Chrome
> > Remote Desktop starts at boot, the latter means that even just setting
> > it up and rebooting is enough to break local logins for the user,
> > which is obviously less than ideal.
> 
> This point about Gnome breaking multiple sessions has been a pain point for
> us (sway/wlroots), and why we typically push back against D-Bus solutions to
> Wayland problems, at least on the session bus. Wayland itself works
> perfectly fine with multiple sessions, and is something we want to preserve.
> 
> It may be possible to create individual session buses for each login
> session, but I don't know how this works in practice and I don't think
> anybody currently does it.

The dependency on a functional D-Bus session bus is in practice a
necessity in a modern desktop environment today on Linux; it would be
counter productive to try to avoid solving any possible issues related
to it to run multiple separate sessions, since so much is using it. For
example anything using GtkApplication or GApplication will use the
session bus, anything related to accessibility uses D-Bus (although on
its own bus), any sandboxed appliction using the portal APIs (including
properly sandboxed flatpak and snap applications) will use the session
bus, desktop notifications uses the session bus.

With that being said, it is possible to run multiple D-Bus sessions,
where session busses are separate - it's just that noone actually does
it as even if you have separate D-Bus sessions, separate
$XDG_RUNTIME_DIRs, the sessions still share fundamental resources such
as $HOME, and it is very likely that many applications you attempt to
run will run into issues where they, running on separate "sessions" on
the same user, will try to manage the same set of files in
the users home directory.

Thus, the only way to get reliable truly parallel sessions is to use
separate users, or separate $HOME directories, where the two sessions do
not share any managed resources at all. Whether there is a point in
using the same user with separate $HOME directories is desired I doubt.

> 
> > We have the following constraints for our use case:
> >   * Chrome Remote Desktop must be usable after boot without the user
> > needing to log in locally, first.
> >   * It must be possible to "curtain" the session, meaning that, when a
> > user is connected, their session is not displayed on the local
> > monitor. (Imagine a user working from home and connecting to their
> > workstation in a shared office space.)
> >   * When the user disconnects, the session must be locked in some
> > manner so a person at the local machine can't take over the session
> > without authentication.
> >   * It's okay to require X11 today, but there should be a reasonable
> > path forward as more distributions switch to Wayland.
> >   * It would be nice, though not required, if the user could access the
> > same session remotely as they see locally. (Though, as noted above,
> > having two separate sessions seems to be explicitly not supported by
> > many new developments, so this may be effectively required.)
> >   * It would be nice, though not required, if the session could be
> > resized to fit the client display when the user is connected remotely.
> >   * It would be nice, though not required, if apps in the session could
> > have access to graphics acceleration when accessed remotely.
> > 
> > Possible idea brainstorming:
> > I'm hoping for feedback for the feasibility of these, given I don't
> > have a lot of experience with Wayland or the modern graphical session
> > architecture. All of these have gaps which make them likely not usable
> > *right now*, so the question is probably which approach would be the
> > most likely to be accepted by the relevant projects, and potentially
> > which would be the quickest to design and get working.
> > 
> > There's likely other possibilities that I haven't thought of.
> > 
> > ~Use a nesting compositor~
> > This involves having an outer compositor that we control that renders
> > to the local screen when used locally, and handles curtaining,
> > offscreen rendering, video capture, and input injection when used
> > remotely. It would run X11 sessions via a fullscreen XWayland in
> > rooted (not rootless) mode, and a Wayland session in nested mode.
> > 
> > This would need some integration with the display manager so that
> > logging in locally would bring the session to the local display and
> > disconnect the remote connection. Similarly, connecting remotely would
> > need to return to the login screen and switch to off screen rendering.
> > I don't know enough to know whether this is feasible, or whether the
> > necessary GPU resource sharing is currently possible.
> > 
> > Additionally, nesting Wayland sessions requires support from
> > sub-compositor for nesting, which appears not to be ubiquitous, and
> > generally requires a special command-line flag. This means support for
> > Wayland sessions would have to be special cased if supported at all.
> > That said, sticking to nested X11 sessions only would probably be
> > tenable for now, assuming there is a future path forward for nested
> > Wayland sessions in the future, and assuming the technical details of
> > interacting with the local login manager could be figured out.
> > 
> > ~Integrate with a system compositor~
> > I've seen some discussion of having a system compositor that runs from
> > the boot splash to shutdown, and manages the display of each session
> > (and even the console). This seems like an ideal place to install
> > hooks that a tool such as Chrome Remote Desktop or an RDP server could
> > use to provide remote access to the machine, including curtaining.
> > This has the potential for a very integrated experience like RDP
> > sessions on Windows.
> > 
> > The obvious downside is that no distribution currently uses a system
> > compositor that I'm aware of, and I haven't been able to find much
> > discussion about the idea since 2013. That means this would be a
> > longer-term solution, which would require support from both distros
> > and session compositors. It would also mean the solution was only
> > usable on distributions that ended up choosing to use a system
> > compositor with the needed hooks, but that may be acceptable if that
> > included enough major distributions.
> > 
> > ~Add curtaining support to session compositors~
> > It appears there is ongoing development for supporting remote access
> > using xdg-desktop-portal and PipeWire. This currently seems more
> > geared to the screensharing and remote assistance use cases, where the
> > user logs in locally and then grants access to the machine. It may be
> > possible to extend the relevant protocols with support for curtaining.
> > 
> > This would require explicit support from each session compositor
> > before it could be used with Chrome Remote Desktop in curtained mode
> > (but others could potentially be supported when curtaining isn't
> > required by the user).
> > 
> > One tricky part here would be how to handle connections after boot, as
> > if the user connects without already being logged in locally, it would
> > be necessary to launch the session, appropriately registered with the
> > display manager, and ensure it was immediately curtained so there was
> > no window in which a person in front of the machine can interact with
> > the remote user's session.
> > 
> 
> In reality, there is no real difference between "nested compositors" "system
> compositors". In both cases, the Wayland compositor is leaving control of
> kernel mode setting (KMS) and input devices to somebody else, and needs to
> tell them what to show. There isn't any reason to use anything other than
> Wayland for that.
> 
> But I think there is already too much momentum behind compositors using KMS
> directly themselves. Back in 2013 when Weston way the only "real" Wayland
> compositor, that would've sounded like a more viable idea, but now you're
> talking about convincing 7 major Wayland implementations (according to
> wayland-protocols MEMBERS) to do things significantly differently.
> 
> Even if that's what was done, you need to be careful to not diminish the
> potential efficiency advantages we get by using KMS ourselves, which mostly
> involves hardware overlay planes.
> 
> The nested compositor needs to be capable of using wl_subsurfaces and
> interfaces like wp_viewporter to at least give the parent compositor the
> opportunity to use overlays, and I'm not aware of any nested compositor that
> currently does that.
> 
> It also gets more complex when you want to start talking about extra KMS
> features like variable refresh rate, which the nested compositor ideally
> wants to know about and have control over in this situation.

I agree that going down the nested compositor path is not feasible.
Display servers will most likely want to continue to work directly on
top of KMS and libinput, and not use a proxy compositor.

> 
> ---
> 
> An alternative solution is to try and do some of this stuff in logind.
> 
> logind does half of this work already in a sense, and AFAIK every compositor
> is capable of using it, including Xorg. It controls access to KMS and input
> devices, and can grant/revoke access to them at will. It doesn't do anything
> graphical, instead leaving it to the compositor and display manager; it's
> merely resource management and allows us to run as the user instead of as
> root.
> 
> Just as a quick overview, there are 'seats' and 'sessions'.
> 
> - A seat is basically the representation of at least one GPU and some input
> devices; the place the user sits at the computer. There is usually only one,
> but multiple is possible.
> 
> - A session is an instance of the user "logging in". It may or may not be
> attached to a seat, but the no seat case is not interesting here; it's
> currently used for SSH logins. If a session is the active session on a seat,
> we get access to the devices for that seat. If it's not (e.g. VT switched
> away), we don't.
> 
> Perhaps logind could be extended to provide some extra way to enforce
> external policy and help with your goals, instead of coming up with
> something completely original. E.g. if you don't want something being
> displayed on the monitor, you make the session non-active on its seat.
> 
> With seamlessly switching sessions between local and remote, that's a bit
> trickier. The compositor needs to be able to switch between KMS and
> off-screen rendering, passing that off-screen rendering to something else
> (e.g. Pipewire), as well as having input-injection. Some input-injection
> things have been discussed before, but I personally haven't been keeping up
> with it.

Switching between local and virtual is FWIW what is the plan for how
GNOME intends to handle cases like this. Not only for headless sessions,
but for switching the monitor of an active session to output e.g. via
Miracast[0].

> 
> wlroots is flexible enough (in theory) to allow for that, but I don't know
> the software architecture of other compositors and how easy it is for them.

Lets say the ultimate goal is being able to log in remotely after boot,
then continue locally at a later point. Multiple isolated and separated
general purpose sessions has fundamental flaws, as discussed above, so
lets ignore that for a bit.

Lets assume that compositors will continue to access KMS directly,
and that there will be no system compositor that acts as a proxy for
session compositors.

Lets also assume we have a way to get the pixel content from the compositor
into the remote desktop service and input back into the compositor (e.g.
via PipeWire, etc.), the complex issues left to is not related to
Wayland at all, but with display manager and logind integration.

Either multiple separate units (e.g. GDM and Chrome Remote Desktop login
manager) needs to both try to manage the same sessions via logind, which
sounds fragile and unlikely to be able to cope with the various security
policies mentioned above; or an session management API, using the D-Bus
system bus, needs to be added and implemented by the relevant display
managers. This API would need to handle things like opening headless
sessions without making them DRM master; handing over control of a
headless session if the session is supposed to be turned into a local
one, then hand it back etc, with all the various policy related to e.g.
when to show the lock screen or not taken into account.

I think this is a discussion that primarily needs to be held with the
display manager developers, as in those is where things need to be tied
together.

Jonas

[0] https://github.com/benzea/gnome-network-displays
> 
> That's my two cents.
> 
> Scott
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel