Re: Chrome Remote Desktop and Wayland
Thanks all for the discussion so far. The discussion of how things might work for gnome-remote-desktop included calls to, e.g., org.gnome.Mutter.RemoteDesktop.CreateSession, org.gnome.Mutter.RemoteDesktop.CreateOutput, and org.gnome.Mutter.ScreenCast.CreateSession. Ideally, Chrome Remote Desktop wouldn't need specific knowledge of each desktop environment, but could rather use a standard mechanism to enumerate installed session types that support curtained remote usage (using .desktop files?) and initiate a remote session in a standard way, including setting up the virtual display and doing input injection. Either way, this sounds like a longer-term solution. To attempt to effect some improvement in the shorter term, we've been discussing the possibility of using our own compositor (possibly an adapted version of Weston) that supports both remote access and attaching to the console. By default, it would run in the background, but we'd install our own "Connect to local Chrome Remote Desktop session" wayland session that, when selected from the display manager, resulted in the session being attached to the local display. Initially, we'd only support X session types (same as today) by using Xwayland, but we could potentially support running nested wayland sessions in the future using subsurfaces. (This would again require some way to identify which session types supported nesting.) My gut reasoning would be that it would be easier for a lightweight compositor to implement nesting than multi-output curtaining support, so this mode might be useful even in the future when the major desktop environments have their own built-in remote desktop support, but, not having implemented a compositor, I couldn't say for sure. Does that sound reasonable? Or is efficient nesting support unlikely enough to happen in any compositor / desktop environment that this would be a dead end, and we'd be better off hacking together a temporary solution for forwarding frames from Xvfb to the local console if that's a feature we want to support, and otherwise waiting for remoting desktop support to land in the various Wayland-based desktop environments? Thanks! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
On Thu, Apr 9, 2020 at 12:17 AM Jonas Ådahl wrote: [snip] > 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. Ideally, (though not a strict requirement for us), there'd also be a way to specify the resolution of the offscreen virtual display (to match the resolution of the client) without modifying the modes used locally once the session is switched back to the local display(s). [snip] > 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. You mentioned that integration with session management makes sense to discuss with display manager folks. Where would be the best place to discuss other such potential cross-windowing system remote-desktop APIs like .desktop fields or headless startup? Thanks! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
On Wed, Apr 8, 2020 at 2:02 AM Jonas Ådahl 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
