Chrome Remote Desktop and Wayland

[Scott Anderson]

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.

> 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.

---

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.

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.

That's my two cents.

Scott