Chrome Remote Desktop and Wayland

[Carsten Haitzler (The Rasterman)]

On Thu, 9 Apr 2020 12:05:57 -0700 Erik Jensen <rkjnsn at google.com> said:

> On Thu, Apr 9, 2020 at 12:17 AM Jonas Ådahl <jadahl at gmail.com> 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?

my take is this should be a daemon like a hybrid login manager/sshd, but
instead of a text login shell, it authenticates then launches a "virtual fb"
parent compositor that sets up a wayland compositor "rendering to ram" and then
launches the actual user session as a wayland client. this will require
compositors that are compatible need to support targeting both drm/kms directly
in the tty AND as a wayland client of this compositor. this compositor would
probably use something like the wayland fullscreen shell. it would be this
compositor that encodes and transmits the compositing results over the network
as well as reading in input from the remote system. the dbus session problem
just need working around probably with another dbus session bus launched for
this session and if apps have a problem with being run multiple times with
different dbus sessions on the same system/homedir.. well.. there is nothing to
be done - it's a problem with that app. it only matters if the user is logged
in on the console and remotely and uses one of these types of apps. they can
opt to not use them or do that, or these apps get fixed.

if they want to "take over their existing console login session" the same idea
applies but this remote compositor is actually a full system-wide fullscreen
compositor and can auth some user then redirect their on screen session to be
remote (and issue appropriate monitor reconfiguring when this happens) and
replace their on-console session with a picture of a horses behind until the
remote session ends... the same daemon can do both just with the option of it
being a system-wide console compositor as opposed to "virtual, only for remote
clients" most of the code is the same/shared. then they will bypass the above
singleton problem apps by having only a single login (gui one) and single dbus
session.

the takeaway from this is more that the ecosystem at large needs to support
compositors running as wayland clients with a system compositor using a
fullscreen shell with all the appropriate logic to handle real local screens and
expose them and let the client compositor configure them, as well as doing the
"virtual rendering to memory and fake a virtual screen and modify that one (or
ones if you want multiple screens) by unplugging/plugging it with new resolution
options etc. if this system compositor is fairly lean and efficient and
essentially doesn't get in the way of real desktop compositors, then it
probably will be supported by most major compositors eventually.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com