To Crack Wayland, RustDesk Went Straight to the Kernel

For over a decade, "just switch to X11" has been the punchline of every Linux remote desktop thread. RustDesk just removed the excuse: its new preview build delivers genuinely unattended remote access on Wayland — no consent dialog, multi-monitor support, and connections that work at the GDM login screen after a cold reboot. The build is x86_64 Debian/Ubuntu-only for now, with Fedora and Arch planned once it stabilizes.

The headline undersells what actually happened, though. RustDesk didn't finally get Wayland's screen-sharing stack to cooperate. It gave up on that stack entirely and went underneath it, straight to the kernel.

Why Wayland broke remote access on purpose

Wayland's security model treats screen capture and input injection as privileges to be granted per-session, by a human, at the keyboard. The sanctioned path — xdg-desktop-portal handing you a PipeWire stream — pops a picker dialog every time a capture session starts. That's exactly right for screen sharing in a video call, and exactly wrong for unattended access, where the whole point is that nobody's at the machine to click "Allow."

The portal spec has a persistence mechanism (restore tokens) meant to soften this, but compositor support is uneven, and none of it helps at the login screen, where no user session exists to host a portal. RustDesk's own Linux docs have long carried the telltale workaround: set WaylandEnable=false in /etc/gdm/custom.conf and fall back to X11 if you want login-screen access. The commercial players never solved it either — AnyDesk still requires Xorg for incoming Linux sessions, and TeamViewer describes its Wayland support as experimental. The only first-party answer is GNOME's gnome-remote-desktop, whose headless remote-login mode is real but GNOME-only, RDP-only, and famously fiddly to provision.

Going under the compositor instead of through it

The mechanism, per the merged pull request in the RustDesk repo, is DRM/KMS direct capture: reading the scanout framebuffer — the pixels the kernel is literally sending to your monitors — via a small library called libdrmtap. Reading another process's scanout requires CAP_SYS_ADMIN, and here's the clever part: RustDesk's existing root --service daemon already has it. The capture runs in-process inside that service, streams frames over an authorized IPC channel to the unprivileged user-facing process, and gets encoded and shipped to the client from there. No new privileged helper binary, no setcap'd files lying around.

This design explains every capability in the announcement. No consent dialog, because the compositor is never asked. Login screen support, because DRM scanout exists before any session or compositor does — a follow-up patch specifically wired up serving GDM and SDDM greeters. Multi-monitor, because each display is just another CRTC to read. Even the hardware cursor is grabbed off its dedicated DRM plane. Input injection was never the hard part: RustDesk already synthesizes it through uinput, which needs root anyway.

The fallback chain is sensible: DRM first (Wayland only), then PipeWire via the portal, then X11. If libdrmtap is missing or a grab fails, you degrade to the consent-dialog world with a logged reason rather than a black screen.

The uncomfortable part, and why it's still defensible

Let's name it plainly: this is a root process bypassing the consent model Wayland spent ten years building. If that sentence makes you flinch, good — it should. A daemon that can silently read framebuffers sees lock screens, password managers, other users' sessions, everything. The Hacker News thread's first serious question was "how does this work technically," and the honest answer is "the way the portal was designed to prevent."

But the flinch deserves a second look. Wayland's consent model assumes the security principal is the person at the screen. Unattended access inverts that premise: the consenting party is the machine's owner, who is by definition not at the screen. The portal architecture simply has no vocabulary for that case, which is why every "sanctioned" solution ends in a GNOME-specific RDP daemon or a GDM config hack. RustDesk's implementation acknowledges the stakes in its structure: the DRM feature is off by default, compiled behind a feature gate, and ships as a separately named rustdesk-unattended-wayland package that conflicts with the regular one — installing it is the consent. The privileged capture code lives in a RustDesk-org-controlled repo rather than an opaque crate, and the IPC channel verifies peer identity. That's more care than most root-daemon remote access tools have ever shown.

The precedent question is real, though. If the answer to "the portal can't do unattended" is "read the kernel's framebuffers as root," other vendors will follow, and the portal's leverage as the capture interface erodes. The right fix long-term is upstream: a portal-level grant for persistent, owner-authorized headless access. Nothing in the freedesktop world is close to shipping that.

What to do with this

If you run Debian- or Ubuntu-family machines you need to reach remotely — a homelab box, a parent's desktop, a fleet of engineering workstations — this is worth testing now. Install the preview .deb from RustDesk's site (it replaces the standard package), pair with a permanent password, reboot, and verify you can reach the GDM greeter cold. That last test is the one X11 refugees have been waiting for; it's also the one most likely to surface bugs, so keep an SSH escape hatch. Pair it with self-hosted rustdesk-server and a WireGuard or Tailscale overlay if the idea of a public rendezvous server brokering a root-privileged capture stream bothers you — it should at least give you pause.

If you're on Fedora, Arch, or anything RPM-shaped, wait — the team says support is coming after real-world testing, and a preview build of a root framebuffer reader is precisely the software you don't sideload from unofficial repackages.

My read: this is a genuine shift, not a stunt. It's the first time unattended Wayland access has worked across the login-screen boundary in a cross-distro, open-source tool, and it leapfrogs both AnyDesk and TeamViewer on Linux in one move. The implementation is preview-grade and the security model trades the compositor's guarantees for RustDesk's own — a trade many admins will rationally accept and some should refuse. Either way, the pressure now sits where it belongs: on the portal maintainers to make the sanctioned path capable enough that going under the compositor stops being the only way to get real work done.