Chrome Remote Desktop and Wayland

[Erik Jensen]

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.

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.



Other ideas and suggestions would be much appreciated.

Thanks!