Headless Wayland Remote Desktop: A Proposal for Displays on Demand
A Linux machine with no monitor attached gives your remote desktop tool nothing to show. How would ext-transient-output create a display, and where does the proposal stand?
- ext-transient-output proposes a way for remote-access software to request virtual displays that are not attached to physical monitors.
- The compositor can accept or reject creation. Destroying the transient-output object removes its associated display.
- As of October 26, both the protocol proposal and the draft wlroots implementation remain unmerged. Existing headless access depends on the compositor and remote tool.
Give the remote server a display to capture
A Linux machine without a monitor still needs a graphical surface for a remote desktop to show. Simon Ser’s ext-transient-output proposal, submitted on October 25, addresses how software such as a VNC server can request that display.
It defines a temporary virtual output that is not tied to physical hardware. The remote tool requests the output, then uses a separate capture protocol to obtain its image and present it to the remote client.
The practical change would be an interface for requesting a display when remote software needs one. It is not a VNC server or a login service. As of October 26, the protocol merge request remains open, and the associated wlroots implementation is still a draft.
The compositor decides whether the display can exist
The proposed protocol is for privileged clients. After the client submits an initial configuration, the compositor can accept or deny creation. The compositor is the desktop component responsible for arranging windows and producing the final display.
On acceptance, the client receives information identifying the new output. It can submit later configuration changes, and destroying the transient-output object removes the associated output.
The compositor can also remove the underlying output first. A remote-tool implementation therefore needs to handle creation refusal and removal, as well as the successful path. The proposal describes both requesting a temporary display and managing its lifetime.
Headless Wayland access already exists in some environments
This is not the first way to use Wayland without a physical monitor. The WayVNC documentation already describes attaching to a running wlroots-based session, including a headless one. It explicitly excludes GNOME, KDE and Weston from its supported compositors.
The new proposal concerns an interface for requesting temporary outputs. Using it requires implementation in the relevant compositor and remote software. It does not convert an existing remote-access application into a tool that works on every desktop.
| Task | Required capability | Relation to this proposal |
|---|---|---|
| Control a desktop that is already running | Capture its screen and deliver input | A new temporary display may not be necessary. |
| Create a remote display without a physical monitor | Create a virtual output | This is the capability the proposal directly addresses. |
| Connect before anyone has logged in | Authenticate and start a session | Creating an output does not provide these steps. |
Separate headless, unattended and logged-out access
For a setup you need today, describe the missing pieces separately. Is there no monitor? Is the user already logged in? Is anyone available to approve a connection? Those situations can require different capabilities even though they all sound like “remote desktop.”
ThinLinc’s developers distinguish attaching to an existing session from supporting headless, multi-user sessions. Their work on the separate RemoteDesktop1 draft also treats headless session startup as another task. Creating a virtual monitor alone does not provide a complete login-to-desktop workflow.
Match the remote tool to the actual GNOME, KDE or wlroots-based environment, rather than just the distribution name. To track ext-transient-output adoption, watch protocol acceptance, compositor implementation and remote-tool support. For an immediate setup, the session types your installed software already supports remain the deciding factor.