Wayland remote desktop — the modern way

The self-contained AppImage detects whether you're on Wayland or Xorg and selects the right capture backend on first run.

Status: portal-native Wayland, shipping today

The Linux host auto-detects your session and runs the portal-native path on Wayland: xdg-desktop-portal ScreenCast (PipeWire) for capture, 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. On Xorg sessions, the host falls back to x11grab + xdotoolautomatically.

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. End-to-end DTLS-SRTP 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)

• 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 Linux lands later. The first Wayland host streams the portal-selected display. Mac and Windows have multi-monitor today; the Linux build catches up after the X11 and Wayland backends prove out in the wild.
• End-to-end encrypted (DTLS-SRTP), peer-to-peer. Keys are negotiated directly between your two devices; the relay only forwards already-encrypted packets it cannot read.

Compositor coverage today

Related