[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: APIs for persistent remote access and headless/hybrid sessions
From:       Erik Jensen <rkjnsn () google ! com>
Date:       2024-04-01 21:18:57
Message-ID: CAN=K5G-rPKFrDoogpqEF+ixnZNpFDwQtx0ASDaqtqbjtWH_41Q () mail ! gmail ! com
[Download RAW message or body]

A remote session would need the following four pieces:

1. An API for the remote access tool to request a remote display and
authenticate. This could involve a headless greeter session for remote
login or direct authentication of some sort.
2. A way for the login manager to launch a session in headless mode.
3. A way for the login manager to query whether an existing session is
headless or can dynamically transition to being headless (and trigger
the transition if so).
4. A way for the remote desktop tool to connect to and control a
headless session (both the headless greeter, if used, and the user
session).

I think all of these parts can, and arguably should, be completely
independent of a standardized org.freedesktop.DisplayManager:

(1) should arguably be a separate interface than that for local
display managers. Discussion on the wlroots tracker suggests many
users of wlroots-based compositors prefer to have a simple local login
manager like ly or greetd. Having a separate interface allows a
separate package to offer remote login functionality on the system
bus. A full featured display manager like GDM or SDDM could still
offer both interfaces itself for better integration.
(2) could be as simple as a property in the session's .desktop file
providing a command-line for headless launch.
(3) would presumably be an interface provided on the user bus by the
compositor itself.
(4) would also be a compositor-provided interface, which could either
be a new or expanded Portal API or a distinct API like that proposed
by Jonas =C3=85dahl.

I believe ConsoleKit and logind already provide a mechanism for a
local login manager to switch to and unlock an existing session, so
the main piece of functionality more integration or a standardized
display manager API would provide would be to provide a way for the
session to kick back to the login screen when curtained, instead of
staying in the foreground with the physical inputs and outputs
disabled.

Please let me know if I'm missing something, though. I'm still
relatively new to this area.

> Also, it looks like there's a draft spec being worked on by Jonas
> =C3=85dahl about a remote desktop protocol (presumably based on what GNOM=
E
> has been working on).

Indeed. (I mentioned it in my initial message.) However, I do not
believe it is directly related to the remote login support Joan Torres
is working on for GNOME Remote Desktop, which relies on GNOME-specific
unstable APIs, but is rather a separate effort to provide a standard
interface for what I call piece (4) above.
[prev in list] [next in list] [prev in thread] [next in thread]