Platform Support

The agent runs on x64 and arm64 architectures and needs no third-party runtime dependencies. The server is distributed as a container image and is installed with Docker.

The operating systems below are officially supported. Where the notes state that troubleshooting support has ended, the agent still runs on that version but issues specific to it are no longer investigated.

For where each feature is available per platform, see the Feature Matrix.

X.8.1 Windows

X.8.2 Linux

X.8.3 macOS

The agent supports macOS Ventura, Sonoma, and Sequoia.

X.8.4 Additional confirmed platforms

The platforms below have been confirmed to run the agent reliably, both through community reports and our own testing. They are not officially supported by us: they are not part of the formally supported set and are not covered by troubleshooting support.

X.8.5 Remote Screen Control prerequisites on Linux

Remote Screen Control on Linux is experimental and supported only on Wayland sessions. Unlike Windows — where capture, input, and H.264 encoding are built in — the Linux agent relies on the Wayland desktop portal and a few host tools. Install the packages below on the controlled device (the one running the agent's user process), not on the operator's machine. Full feature detail is in A.7.

To confirm the device is running a Wayland session, run:

loginctl show-session "$(loginctl | awk '/ seat/{print $1; exit}')" -p Type

This prints Type=wayland for the active graphical seat session.

Under the hood there are two independent layers — screen capture and input injection — and each tries a preferred path first, dropping to a fallback only when the preferred path is unavailable. The agent decides this automatically at runtime; you do not configure which path is used. What you install simply determines which paths are possible.

What runs out of the box, and what is a fallback

When the fallback engages:

• Capture falls back if the portal/PipeWire prerequisites are missing, or if the preferred capture keeps returning no frame for a few seconds (e.g. the portal backend is absent).
• Input falls back if no portal input session is active (portal not running, permission not granted, or a session that only provides capture).

Where it works — display server and desktop

Whether Remote Screen Control works is decided by the display server and the desktop's portal backend, not by the distribution itself. The table below is derived from the implementation and from each desktop's standard portal support (it is a reasoned assessment, not a per-distro test result; the experimental status still applies).

On GNOME and KDE Wayland the portal path is effectively the only one that works — the command-line capture fallbacks do not apply there (grim needs wlroots; scrot only sees XWayland windows). So on those desktops the portal bridge packages below are required, not optional.

Applies to graphical desktops only. Remote Screen Control needs a screen to control. Headless server and cloud installs — common for RHEL/CentOS Server, SUSE Linux Enterprise Server, Alpine, Azure Linux, and Ubuntu Server — have no display server, so the feature does not apply there even though the agent itself runs.

The package names below are for Debian and Ubuntu (apt). Other distribution families ship the same tools under their own package managers (dnf, zypper, apk).

Required packages (Wayland portal path)

The preferred path is the desktop portal: org.freedesktop.portal.ScreenCast provides the screen and org.freedesktop.portal.RemoteDesktop injects input — no ydotool and no uinput access needed. The agent drives the portal through a small Python helper and bridges the PipeWire video stream with GStreamer.

Install the full portal path on the controlled device. On Debian and Ubuntu:

sudo apt install -y \
  pipewire xdg-desktop-portal xdg-desktop-portal-gnome \
  gstreamer1.0-tools gstreamer1.0-pipewire \
  gstreamer1.0-plugins-base gstreamer1.0-plugins-good \
  python3 python3-dbus python3-gi gir1.2-glib-2.0

On KDE, install xdg-desktop-portal-kde instead of xdg-desktop-portal-gnome. A standard GNOME or KDE desktop already ships pipewire, xdg-desktop-portal, and its portal backend; the packages that are usually still missing are the GStreamer plugins (gstreamer1.0-plugins-base and gstreamer1.0-plugins-good, which provide the videoconvert / videoscale / videorate and jpegenc / multifilesink elements the capture pipeline uses) and the GStreamer↔PipeWire bridge with the Python bindings the helper uses.

Other distribution families ship the same tools under their own package managers. The non-apt columns are equivalent package names — verify per distribution; only the apt column is authoritative.

Clipboard sync uses xclip (which works through XWayland); xsel works as an alternative:

sudo apt install -y xclip

Unattended access on Wayland

The Wayland portal is built around user consent, which shapes how unattended access behaves:

• First connection to a device shows a one-time screen-sharing dialog that must be accepted on the controlled device. The agent requests a persistent grant (persist_mode = 2).
• Every connection after that is silent. The agent stores the restore token the portal returns — per user, under ~/.config/netlock/pipewire_restore_token — and replays it on later connections, so the grant is restored without a prompt. This survives reboots: the grant persists until it is explicitly revoked.
• Re-approval is only needed if the user revokes the grant (GNOME Settings → Sharing / Privacy → Screen Sharing, or the equivalent on KDE), a different user or application identity is used, or — rarely — a desktop update invalidates the token. If a stored token ever fails to restore, the agent discards it and automatically falls back to a fresh prompt, so a stale token cannot get the device stuck.

Limitation — the login screen is not covered. Because the portal lives inside the user's session, unattended capture covers a logged-in user (including after a reboot, once that user's session is back). It does not cover the login screen (GDM) or a state with no logged-in user. To guarantee a session always exists for unattended access, enable autologin on the device.

Wayland fallback (only if the portal path is unavailable)

If the portal cannot be used — for example a session with no portal backend, or a locked-down/headless-style setup — the agent falls back to ydotool for input and CLI tools (grim, scrot) for capture. Install these only if you need that fallback to work:

sudo apt install -y ydotool grim scrot

ydotool injects at the kernel level through /dev/uinput, which needs two extra steps:

Related chapters

• Chapter 3 — Devices — device inventory and remote access.
• A.7 — Remote Screen Control — session switching, recording, and unattended access.
• X.7 — Feature Matrix — per-feature platform availability.