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