Introduction
Remote control on Linux works the same way it does on Windows and macOS: click the OS icon next to an online device and a live desktop session opens in a new browser tab. The session is end-to-end encrypted and connects peer-to-peer when network conditions allow.
What's different on Linux is what's underneath. Linux desktops vary in display server (X11 or Wayland) and desktop environment, and remote control support depends on that combination rather than on which distribution you're running. This article covers what's supported, what the agent sets up on the device, and the behaviors specific to Linux sessions.
For session controls, toolbars, and clipboard tools, see Remote Control. Those work the same on every platform.
⚙️ PREREQUISITES
The Level agent is installed and online on the target device
Your account has remote control permission for the device's group
A graphical session (Wayland or X11) is running on the device, which includes the login screen
For GNOME on Wayland: PipeWire and a running D-Bus session bus (other compositors don't need these)
What's Supported
There's no fixed list of supported distributions. A Linux device supports remote control when three things are true:
The Level Linux agent runs on it.
It's running a supported display server and desktop environment combination (see below).
Any components its desktop environment needs are present (GNOME on Wayland uses PipeWire and D-Bus; other compositors don't require them).
If your distribution runs one of the environments below, remote control works regardless of which distro it is.
Display Servers
Both major Linux display servers are supported. The agent detects what's running and picks the right path automatically. Wayland is tried first, with X11 as the fallback.
Wayland is supported on these desktop environments:
GNOME (Mutter)
KDE Plasma (KWin)
COSMIC (System76 / Pop!_OS)
wlroots-based compositors such as Sway and Hyprland
X11 / Xorg is supported under any desktop environment. XFCE, MATE, Cinnamon, and older GNOME or KDE sessions running on Xorg all use this path.
ℹ️ NOTE: GNOME, KDE, COSMIC, Sway, and Hyprland are tested and work. A niche Wayland compositor outside that set may not, and the usual reason is screen capture: if the compositor can't hand Level a screen feed, you'll connect but see nothing. Mouse input has a kernel-level fallback that works on any compositor, so input is rarely the problem. If a niche compositor doesn't capture, run the session under Xorg instead.
Architectures
Both x86-64 and ARM64 devices are supported.
A Graphical Session Is Required
Remote control attaches to whichever graphical session is currently active on the device, including the login screen, and follows session changes automatically. If a user logs in, out, or switches accounts during a session, Level re-attaches to the new session.
💡 TIP: For headless Linux devices, use background management instead. Terminal, File Explorer, Processes, and Services all work without a graphical session. See Device Manage.
You don't need a user logged in. A display manager sitting at the login screen counts as an active graphical session, so you can connect, watch a user log in, and stay attached through the transition. This is the same behavior as the Windows login screen and the macOS lock screen.
What has to be true is that a graphical session is running. The session must be Wayland or X11 on a seat. These cases have no graphical session and can't be remote controlled:
Headless servers with no display manager
Machines booted to a text or multi-user target
The display manager isn't running
Text-console (tty / getty) logins only
🖥️ PLATFORM NOTE: Older GNOME releases (before GNOME 42 / Ubuntu 22.04) often run the login screen on Wayland while the user session runs on X11. The Wayland remote desktop APIs on those older releases aren't mature enough for Level to attach to the greeter, so remote control at the login screen won't work there.
To fix it, force the greeter onto X11 by uncommenting WaylandEnable=false in /etc/gdm3/custom.conf and rebooting. GNOME 42 and later work on Wayland at both the login screen and the user session.
What the Agent Sets Up
On most systems, remote control works with no manual setup. On GNOME and KDE, the agent installs a small component to enable Wayland session capture and input.
GNOME
The agent automatically installs a Level GNOME Shell extension for the logged-in user. It selects the right extension build for the installed GNOME Shell version, so a wide range of GNOME releases is handled without any action on your part.
GNOME on Wayland is supported from GNOME 42 (Ubuntu 22.04) onward. On those releases both the login screen and the user session work on Wayland. Older GNOME releases should run the session on X11 (see the login-screen note above).
KDE Plasma
On KDE Plasma, the agent registers the access it needs with KWin automatically. No action required.
If Remote Control Isn't Available After Install
Setup runs automatically and remote control should work right after the agent installs. If it doesn't, reboot the device.
💡 TIP: A reboot clears up nearly all first-time setup issues across every desktop environment, including GNOME extension activation and KDE access registration. If a freshly installed or upgraded device isn't accepting remote sessions, reboot it before digging further.
Linux Session Behaviors
A few things work slightly differently in a Linux session.
Multi-monitor is supported. Use the Display dropdown in the top toolbar to switch between monitors, the same as on other platforms.
Clipboard sharing works across desktop environments, including Wayland compositors beyond GNOME and KDE. Send Clipboard and Get Clipboard work as described in Remote Control.
Keyboard input handles non-US layouts and Unicode characters, so typing in the session should match what you'd type locally.
FAQ
Which Linux distros does remote control support? There's no distro list. Support is based on what the device is running, not which distribution it is. If the Level agent runs on it and it's using GNOME, KDE Plasma, COSMIC, a wlroots compositor, or any desktop on Xorg, remote control works.
I can't start a remote session on my Linux server. What's wrong? The machine probably has no graphical session running: it's headless, booted to a text target, or the display manager isn't running. Remote control needs a graphical session (Wayland or X11) to attach to, but it does not need a user logged in. A login screen counts. Text-console logins don't. Use the Terminal in background management for headless machines.
Can I connect before anyone logs in? Yes, as long as the graphical login screen is up. Level attaches to the login screen and stays connected through the login, so you can watch a user sign in or sign in yourself if you have credentials.
Remote control connects to my Wayland machine but the screen is blank. Why? On a niche compositor, Level may not be able to capture the screen. Sway, Hyprland, GNOME, KDE, and COSMIC are tested and capture fine; some less common compositors don't. Run the session under Xorg instead, which captures on any desktop environment.
I just installed the agent and remote control isn't available yet. Setup is automatic and should be ready immediately, but if a device isn't accepting sessions right after install or upgrade, reboot it. That resolves most first-time setup issues, including GNOME extension activation and KDE access registration.
Does the GNOME extension require any setup from the end user? No. The agent installs and enables it automatically for the logged-in user, and picks the right build for the installed GNOME Shell version.
Is the connection encrypted the same way as Windows and macOS? Yes. Linux sessions use the same end-to-end encrypted P2P connection, with relay fallback when a direct connection isn't possible. See the main Remote Control article for details.