The quick-tip: RustDesk's nightly builds now support Wayland for screen sharing and, on some compositors, remote input. However, true unattended access—connecting without anyone at the remote machine—still requires a virtual display or headless setup. Here's what works today and how to set it up.
If you've ever tried to remotely control a Linux machine running Wayland, you know the pain. VNC gives you a black screen. RDP won't install. Even commercial tools throw cryptic errors about "pipewire" and "portals," leaving you guessing.
The root cause lies in Wayland's security model. Unlike X11, where any application can grab the screen and inject keystrokes, Wayland forces every application to ask permission. That's great for security, but terrible for remote access tools that need to work in the background.
RustDesk, the open-source remote desktop tool with over 100,000 GitHub stars, has been chipping away at this problem. Its nightly builds now include Wayland support via xdg-desktop-portal and PipeWire. You can share your screen, and you can even control a remote machine—if the compositor cooperates.
But here's the catch: unattended access on Wayland isn't here yet—at least not in the way you'd expect.
Key Takeaway: RustDesk supports Wayland for attended sessions (where someone accepts the connection), but true unattended access requires a virtual display or X11 fallback. Expect this to change as compositors add input-injection protocols.
Wayland was designed to fix X11's security holes. On X11, any application can:
That's how keyloggers and screen-scrapers operated on Linux for decades. Wayland eliminates this by design.
Screen sharing on Wayland requires the xdg-desktop-portal—a D-Bus service that acts as a broker between applications and the compositor (the software that manages windows, such as GNOME's Mutter or KDE's KWin). When RustDesk wants to capture the screen, the portal displays a dialog asking the user to grant permission and select which screen or window to share.
The actual pixel data flows through PipeWire, the same multimedia framework used for audio and video. This isn't a RustDesk quirk—it's the only sanctioned path for screen capture on Wayland.
Input injection is a separate challenge. The compositor controls the keyboard and mouse exclusively. For RustDesk to move the cursor or send keystrokes, the compositor must expose a protocol for that. KDE has one; GNOME doesn't.
Here's the current state of nightly builds:
Screen sharing: Works on GNOME and KDE, provided the user grants permission through the portal dialog. The quality is solid—PipeWire handles encoding efficiently, and RustDesk's compression works on top.
Input injection: Works on KDE Plasma via the KWin scripting API. You can move the mouse, click, and type. On GNOME, input injection isn't supported because Mutter doesn't expose the necessary protocol.
Connection flow: When you connect to a Wayland machine, RustDesk displays a permission prompt. Someone must click "Accept" and grant screen-sharing access. This is the attended-access model.
Key Takeaway: On KDE Wayland, you get full remote control during an attended session. On GNOME Wayland, you get screen sharing but no input injection—essentially view-only.
True unattended access means connecting to a machine with no one present. No one to click "Accept." No one to grant portal permissions. On Wayland, this is fundamentally blocked by design.
The portal requires user consent for every screen capture session. There's no "remember this decision" checkbox. And even if you could bypass that, input injection on KDE requires an active, unlocked session—KWin won't inject input into a locked screen.
RustDesk's documentation is explicit about this: for unattended access on Wayland, you need a workaround. The nightly build status is experimental, and the project team is actively discussing protocol changes with compositor developers.
Current status: Nightly builds only. Not recommended for production. Breaking changes are likely.
If you need unattended access to a Wayland machine today, here are three options:
Create a headless X11 session running inside your Wayland desktop, then run RustDesk in that session:
# Install Xvfb
sudo apt install xvfb # Debian/Ubuntu
sudo dnf install xorg-x11-server-Xvfb # Fedora
# Start a virtual display
Xvfb :99 -screen 0 1920x1080x24 &
# Run RustDesk in that display
DISPLAY=:99 rustdesk
Now you can connect to that RustDesk instance. It runs on X11, so no Wayland restrictions apply. The downside: you're controlling a virtual screen, not your physical desktop.
If your machine has a GPU, you can create a second X11 session on a different virtual terminal:
# Switch to VT 2
sudo chvt 2
# Log in and start an X11 session (from the login screen)
Run RustDesk there. You'll see it on your physical monitor when you switch to that VT, and you can control it remotely without Wayland restrictions.
For servers, use a dummy display driver to create a virtual framebuffer:
# Install dummy-hcd (varies by distro)
sudo apt install xserver-xorg-video-dummy
# Configure /etc/X11/xorg.conf with a dummy display
# Then start RustDesk in that session
This is the cleanest option for servers without monitors. The RustDesk instance runs on X11, is accessible remotely, and the dummy driver provides a stable framebuffer.
Key Takeaway: For unattended access today, run RustDesk in an X11 session—virtual or physical. Wayland sessions require user presence.
The RustDesk team is actively developing Wayland support. GitHub discussions show ongoing work on:
The path to stable support depends on compositor adoption of input-injection protocols. As more compositors implement these, RustDesk's Wayland support will become more complete.
For now, treat Wayland support as a preview. It works for attended sessions on KDE, view-only on GNOME, and not at all for unattended access.
Does RustDesk support unattended remote access on Wayland? No. Wayland's security model requires user consent for screen capture and input injection. Unattended access requires a virtual display or X11 session.
What are the limitations of RustDesk on Wayland? Screen sharing requires user approval via the portal dialog. Input injection only works on compositors that expose the necessary protocols (currently KDE, not GNOME). Unattended sessions are not possible.
Which Wayland compositors are supported by RustDesk? GNOME (screen sharing only) and KDE Plasma (screen sharing + input injection). wlroots-based compositors are in development.
How can I set up unattended remote access on Wayland with RustDesk? You can't—not directly. Use Xvfb to create a virtual X11 display and run RustDesk there, or use a separate X11 session.
Is RustDesk's Wayland support stable? No. It's available in nightly builds only and is experimental. Expect breaking changes and bugs.
Download the latest nightly build from the RustDesk GitHub releases page, test it on your compositor, and file issues for anything that breaks.
The bottom line: RustDesk's Wayland support is a genuine step forward—the first open-source remote desktop tool to navigate Wayland's security model this far. But "true unattended access" isn't here yet. Use the X11 workaround for now, and keep an eye on nightly builds for progress.
Sources: RustDesk GitHub, Wayland documentation, xdg-desktop-portal, PipeWire, RustDesk forum