Chrome Remote Desktop and Wayland

[Erik Jensen]

On Wed, Apr 8, 2020 at 2:02 AM Jonas Ådahl <jadahl at gmail.com> wrote:
> Either multiple separate units (e.g. GDM and Chrome Remote Desktop login
> manager) needs to both try to manage the same sessions via logind, which
> sounds fragile and unlikely to be able to cope with the various security
> policies mentioned above; or an session management API, using the D-Bus
> system bus, needs to be added and implemented by the relevant display
> managers. This API would need to handle things like opening headless
> sessions without making them DRM master; handing over control of a
> headless session if the session is supposed to be turned into a local
> one, then hand it back etc, with all the various policy related to e.g.
> when to show the lock screen or not taken into account.

It sounds like this would require a few new pieces:
 * The session management API you mentioned for coordinating sessions.
 * Compositor support for launching without DRM master.
 * Compositor support for offscreen rendering when DRM master is
revoked. (Presumably grant and revocation of DRM master is already
handled due to VT switching? Do any compositors already support this
if there's an ongoing PipeWire capture when they are put in the
background?)
 * A solution for input injection.

A remote desktop tool like Chrome Remote Desktop would then be
responsible for using the new API to launch a new session without DRM
master or revoke DRM master from an existing session (presumably
returning the local display to the login screen), and then connecting
to the appropriate Wayland session to initiate video capture and input
injection.

Does that accurately reflect your suggested solution?