APIs for persistent remote access and headless/hybrid sessions

Erik Jensen rkjnsn at google.com
Tue Feb 27 18:35:22 GMT 2024

I'm on the Chrome Remote Desktop team at Google, and I am working to
add support for Wayland-based desktop environments. While our initial
focus will be on getting it to work with GNOME, we'd love the
functionally to be based on standardized APIs that can be used across
desktop environments, so I'm reaching out here to see what interest
there might be on the KDE side.

There's been a bit of discussion[1] on the GNOME Discourse, but to
summarize, while the existing Portal APIs are great for remote
assistance use cases where there is a local user to approve the
session and mirroring the local display(s) makes sense, they are
lacking functionality needed for the persistent remote access use
case, where:

 * Connection should be possible immediately after boot.
 * For security, the session should operate in a headless mode while a
remote connection is active and the physical seat should remain
 * Virtual monitor layout should be configurable by the remote desktop
tool to match the client, rather than mirroring the physical layout of
the host.

GNOME is currently pursuing an approach where the remote access tool
runs as a system service, and connecting presents a login screen where
the user can select a session and log in. Some handoff mechanism is
then used for a process running in the resulting session to take over
the connection.

The current GNOME implementation is based on unstable, GNOME-specific
APIs. As far as I understand it, there are three main pieces that
would need to be standardized for this approach to work in a
desktop-agnostic fashion:

 * An expanded remote desktop API for the compositor. Unlike the
Portals API, this API would only be exposed to trusted processes and
would not require a prompt for each session. Additionally, it would
provide support for configuring virtual monitor resolutions, layout,
and DPI, as well as support for accessing the clipboard. Jonas Ã…dahl
has been working on creating a standard spec for this functionality, a
draft of which is available at [2].
 * An API for requesting a new remote display from the greeter, which
the remote desktop tool could then attach to using the above API to
allow the user to log in. This would also provide a method for the
remote access tool to identify the resulting session.
 * A protocol by which the greeter can instruct the desktop
environment to launch in headless mode for remote access, or
(eventually) transition into/out of headless mode so the user can
attach to the same session locally or remotely. Desktop Environments
would presumably signal their support for headless / hybrid sesssions
via an entry in their respective .desktop file.

Of course, there are other approaches one could take, such as
expecting the remote desktop tool to handle PAM authentication and
session creation directly, rather than relying on the system greeter,
or allowing individual users to set up a remote desktop tool as a user
service that can only launch sessions on behalf of that user (which
would require linger and wouldn't work with encrypted home
directories, but would be more similar to how Chrome Remote Desktop
currently works).

Is such persistent remote access functionality something KDE would be
interested in having? Do folks have thoughts on what they'd like to
see such APIs look like?


[1]: https://discourse.gnome.org/t/persistent-remote-desktop-access-api/19415
[2]: https://gitlab.freedesktop.org/jadahl/xdg-specs/-/merge_requests/1

More information about the kde-devel mailing list