Chrome Remote Desktop and Wayland

[Jonas Ådahl]

On Wed, Apr 08, 2020 at 11:17:14AM -0700, Erik Jensen wrote:
> 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?)

DRM master and input device revocation should be handled more or less
already by most if not all compositors, by closing devices, by then
going dorment until access is returned to the compositor. I don't know
if there is any compositor that can already handle continuing it's
session headless with an active PipeWire stream.

>  * 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?

More or less, yes. Launching sessions without DRM master and going
headless is probably things we can add capability fields for in the
session .desktop files, and show dialogs like "Wait" or "Terminate
session" if a conflict appears (as mentioned in the linked GDM bug). All
of this would also not need be specific to a certain windowing system,
so that you we can use the same APIs for handling both Wayland sessions,
X11 sessions, and whatever more types that may eventually appear.


Jonas