Chrome Remote Desktop and Wayland

[Ray Strode]

Hey,

On Wed, Apr 8, 2020 at 12:04 AM Erik Jensen <rkjnsn at google.com> wrote:
> 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.
Right, and as mentioned in the bug, GNOME doesn't really support
logging in more than once with the same user from a data reliability
point of view anyway.  I mean the settings database doesn't work well
if more than one thing is writing to it at the same time (which is one
of the reasons writes for all apps are funneled through a daemon).

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

>  * 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.)
Yea this is something we've wanted in GNOME for a long.  See for
instance this bug from 2005:

https://bugzilla.gnome.org/show_bug.cgi?id=311780

Back then we didn't even have compositing window
managers so it wasn't something we could practically implement.
Today's a different story!  This is something mutter/gnome-shell can
reasonably implement with some effort.

>  * It's okay to require X11 today, but there should be a reasonable
> path forward as more distributions switch to Wayland.
I think it's more likely for mutter, that this would land in the
native display server (wayland) side first.

> 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.
[snip]
> ~Add curtaining support to session compositors~
This seem like the most plausible way forward.

So the original idea with having a user bus instead of a session bus
was that e.g., gnome-shell would handle all sessions, not just one
session.  So rather than a gnome-shell per session, there would be
just the one for the user, started by systemd and running in its own
cgroup.  (Likewise, dconfd would handle setting writes for all sessions,
and then no worries about the settings database getting corrupted.)

The idea is, that if gnome-session is started in the mode that tells
it to use systemd, rather than starting gnome-shell and the rest of
the required components of the session itself, it instead defers to
the user's systemd instance to reach a specific target. That target
has various session services as dependencies including gnome-shell.

Crucially, if one gnome-session instance starts gnome-shell via a
systemd user service (say via chrome remote desktop), and another
gnome-session instance gets started in a new session (say via the
local gdm login screen), and also tries to set a systemd --user
target that brings in gnome-shell, systemd won't start gnome-shell
twice.  gnome-shell is instead a sort of factory process that starts
when the first session logs in and lasts until the last session logs
out.

But if gnome-shell is a factory process that may be around before a
session is started, how can it know when that new session comes
around so it can "adopt" or service it?

Sessions are registered with logind (usually via pam_systemd, but
there's an underlying D-Bus api too).

gnome-shell can easily ask logind to enumerate all the sessions that
belong to a user (see sd_uid_get_sessions), and can also easily
detect when a new session comes or goes (see sd_login_monitor).
It can also detect when a session is active or inactive via logind.

We don't really do a lot of this today, but one vision for the future is
something like this:

- User logs into their workstation at work and hacks away for a while
before needing to leave.

- Before going the user enables remote desktop, which leads to the
new session getting registered with logind .

- This, in turn, tells systemd --user to reach a particular target that
 pulls in gnome-shell, other gnome bits, and maybe some
chrome-remote-desktop agent-y thing? Probably we would provide
a gnome-session-pipewire at .target that ISVs could depend on, I guess.

- Since gnome-shell is already started, systemd doesn't start it again
when reaching the new target.

- The already running gnome-shell instance notices the new session
show up and stages a virtual output for it (that feeds to pipewire).
 No windows are placed on this output, and it's locked, with the
shell shield dropped.

- When the user connects with their remote viewer from their laptop,
logind on the workstation reports the new session as "active" instead
of just "online" (see sd_session_get_state ()).  This triggers the
shield to raise, and the unlock screen to be presented.

- If the user then types their password, the session is unlocked and the
windows are redirected to the virtual output.  At the same time, the shield
on the workstation drops, and the seat there is locked.

- If the user goes back to their workstation and unlocks it the shield
would drop over the remote desktop session, and the windows would
get redirected back to the local seat.

So that's the vision.  Where do we stand?

Today, mutter doesn't have full support for virtual outputs to redirect
windows, too, but it's something Jonas has mentioned he wants to work
on for a variety of reasons (including this use case).

Today, gnome-shell doesn't try to listen for sessions coming and going,
and it doesn't try to manage more than one session.  It also, doesn't notice,
when some other session for the user starts, and so it doesn't let that new
session preempt the currently active session.

Today, logind supports registering session for type "x11" and type "wayland".
It doesn't support a type of "pipewire" which would be more appropriate for
this remote desktop kind of session. Remember, in this vision, gnome-shell
is listening for the new session to get registered with logind.  it needs to
know the type of the session so it knows to enable pipewire and the
virtual output.

Today, logind always forces the sessions that aren't running on a physical
seat to have the state of "active".  At the moment "online" is mainly used for
"running on inactive VT on the primary seat", and not so much in other contexts.
We may need to enhance logind to support setting the state for these kinds
of seat-less sessions.  Alternatively, we could potentially go off the
"LockedHint"
for the session, but it's not quite as good of a fit conceptually as the session
state.

So there's a bit of work to do, mostly on the shell/mutter side, and some on the
logind side, before there's a good story, but it should happen
eventually. In the
mean time, Benjamin is going to land a fix for your more immediate GDM
problem soon:

https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/90

--Ray