Chrome Remote Desktop and Wayland

[Erik Jensen]

On Thu, Apr 9, 2020 at 12:23 PM Carsten Haitzler <raster at rasterman.com> wrote:
> my take is this should be a daemon like a hybrid login manager/sshd, but
> instead of a text login shell, it authenticates then launches a "virtual fb"
> parent compositor that sets up a wayland compositor "rendering to ram" and then
> launches the actual user session as a wayland client. this will require
> compositors that are compatible need to support targeting both drm/kms directly
> in the tty AND as a wayland client of this compositor. this compositor would
> probably use something like the wayland fullscreen shell. it would be this
> compositor that encodes and transmits the compositing results over the network
> as well as reading in input from the remote system. the dbus session problem
> just need working around probably with another dbus session bus launched for
> this session and if apps have a problem with being run multiple times with
> different dbus sessions on the same system/homedir.. well.. there is nothing to
> be done - it's a problem with that app. it only matters if the user is logged
> in on the console and remotely and uses one of these types of apps. they can
> opt to not use them or do that, or these apps get fixed.
>
> if they want to "take over their existing console login session" the same idea
> applies but this remote compositor is actually a full system-wide fullscreen
> compositor and can auth some user then redirect their on screen session to be
> remote (and issue appropriate monitor reconfiguring when this happens) and
> replace their on-console session with a picture of a horses behind until the
> remote session ends... the same daemon can do both just with the option of it
> being a system-wide console compositor as opposed to "virtual, only for remote
> clients" most of the code is the same/shared. then they will bypass the above
> singleton problem apps by having only a single login (gui one) and single dbus
> session.
>
> the takeaway from this is more that the ecosystem at large needs to support
> compositors running as wayland clients with a system compositor using a
> fullscreen shell with all the appropriate logic to handle real local screens and
> expose them and let the client compositor configure them, as well as doing the
> "virtual rendering to memory and fake a virtual screen and modify that one (or
> ones if you want multiple screens) by unplugging/plugging it with new resolution
> options etc. if this system compositor is fairly lean and efficient and
> essentially doesn't get in the way of real desktop compositors, then it
> probably will be supported by most major compositors eventually.
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> Carsten Haitzler - raster at rasterman.com

I guess the question is, what is more likely to be accepted by the
major Wayland compositors? The ability to run efficiently nested
(using subsurfaces and other tricks to get the performance hit as low
as possible), or the ability to launch headless and render offscreen
with PipeWire capture and input injection?

The former has the advantage that XWayland exists today, so it could
work with X11 sessions even without any added support. Support could
be expanded for Wayland sessions as compositors gain support for
efficient nesting. It wouldn't even need major support from the
display manager, as Chrome Remote Desktop could install a "Connect to
Chrome Remote Desktop session" session type.

The latter approach has the potential for better integration overall,
but requires more design work, support from display managers, and
possibly more implementation work from the compositors. (I'm not
actually sure how offscreen rendering compares with nested rendering,
but many compositors seem to already have support for a limited,
lower-performance variant of the latter.) It also isn't usable until
at least one Wayland compositor or the Xorg server supports offscreen
rendering and video capture.