Wayland remote desktop — the modern way

Detects whether you're on Wayland or Xorg and selects the right capture backend on first run.

Status: X11 today, native Wayland in 0.3 (in test)

We'd rather tell you the truth than make you find out after install. The shipping Linux host (0.2.x) is X11-focused: x11grab for capture, xdotool for input. On a Wayland session today you have two options — log in to an Xorg session for the MVP, or wait for the 0.3 release. The 0.3 host is in active test now, using xdg-desktop-portal ScreenCast (PipeWire) for capture and libei for input injection. The portal asks once for screen-share consent, the same dialog you've seen if you've ever shared a screen on a modern Linux video call.

The Wayland stack Scry uses

• xdg-desktop-portal ScreenCast for capture

  The standard freedesktop portal API. Works the same on GNOME, KDE Plasma, and any compositor that implements the portal — not a compositor-specific protocol. Frames come out of a PipeWire stream with proper monitor selection and DMA-BUF handling where the compositor supports it.

• PipeWire as the video transport

  The same PipeWire your distro already runs for audio and screen sharing. The capture pipeline encodes through H.264 (libx264) and hands the encoded stream to a WebRTC track.

• libei for input injection

  Wayland deliberately blocks the X11 xdotool path for security. libei is the emerging standard for synthetic input on Wayland and what the modern portal stack accepts. Same keyboard + mouse + scroll surface, just on the new transport.

• WebRTC end transport (same as every other Scry client)

  Whether the host is Mac, Windows, or Linux/Wayland, the wire format from the host to the viewer is WebRTC. DTLS/SRTP transport encryption is part of the standard, not bolted on.

Why this matters (beyond keyword optimization)

Wayland is the default on Fedora Workstation, Ubuntu 24.04 desktop, GNOME 46+, and KDE Plasma 6+. If you're on a current distro and haven't touched session settings, you're probably on Wayland right now. Tools that only do X11 either downgrade you to Xorg or fall over.

Going through xdg-desktop-portal also means Scry plays nice with the security model Wayland was designed around: you grant screen-share consent explicitly, the portal records that consent, and revoking it is one switch in your system settings. That's a feature, not a tax.

What this is not (yet)

• Not GA yet. 0.3 is in test as of this writing (May 2026). 0.2.x ships X11 only. If you need Wayland-native today, the honest answer is “wait, or use an Xorg session.”
• No login-screen / GDM access. Capture starts after a user is logged in and has granted the portal consent. Reaching a locked Wayland session pre-login is not in scope.
• Multi-monitor on Wayland is Pro and in preview — the free tier is single-monitor across every platform.
• Transport-encrypted, not end-to-end. DTLS/SRTP over WebRTC is real and verifiable. End-to-end is a stronger claim we have not published evidence for.

Compositor coverage when 0.3 lands

Related