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 Ådahl. 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 > Ådahl about a remote desktop protocol (presumably based on what GNOME > 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.
