Chrome Remote Desktop and Wayland
Erik Jensen
rkjnsn at google.com
Tue May 12 20:26:56 UTC 2020
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!
More information about the wayland-devel
mailing list