On Wed, Apr 8, 2020 at 2:02 AM Jonas Ådahl <jad...@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? _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel