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. Unlike Windows — where capture, input, and H.264 encoding are built in — the Linux agent relies on the display server and a few host tools, so the required packages depend on whether the device runs an X11 or a Wayland session. Install them 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.

The agent detects the session type at runtime. To check it yourself, run:

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

This prints Type=wayland or Type=x11 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/imagemagick only see 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).

X11 sessions

X11 is essentially out of the box: input goes through the XTest extension and capture through the native X11 image API, both of which live in libraries (libxtst6, libx11-6) that are present on any X11 desktop. Nothing else is required for control itself.

# Preferred path — usually already installed on any X11 desktop
sudo apt install -y libxtst6 libx11-6

# Optional: capture fallback + clipboard sync
sudo apt install -y grim scrot imagemagick xclip

Wayland sessions

On Wayland 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.

On a standard GNOME or KDE desktop the base is already present (pipewire, xdg-desktop-portal, and the desktop's portal backend such as xdg-desktop-portal-gnome). What usually still needs installing is the GStreamer↔PipeWire bridge and the Python bindings the helper uses:

# Preferred path — the portal bridge (base pipewire/portal is normally already there)
sudo apt install -y pipewire gstreamer1.0-pipewire gstreamer1.0-tools \
  python3-dbus python3-gi gir1.2-glib-2.0

# Clipboard sync (works through XWayland)
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. X11 sessions do not have this constraint — XTest/XGetImage need no per-session consent.

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.