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