NullNet-ai / NullNet-ai/wallguard
Remote Desktop: Wayland compatibility problems and macOS screen capture not implemented
@antoncxx is already working on this.
Since May 28, 2026.
- Dominant language
- Rust
- Stars
- 7
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
Wayland — Known Issues
1. Screen capture requires session user UID (blocks root deployments)
KWin (KDE Plasma 6) and most other Wayland compositors restrict zwlr_screencopy_manager_v1 to processes whose UID matches the session user. When the agent runs as root, the compositor simply does not advertise the protocol, making screen capture impossible.
Affected compositors: KWin (KDE Plasma 6), likely others
Not affected: sway, hyprland, labwc, river (these advertise screencopy to all clients)
Current behaviour: the pseudo-RD service is not advertised when screencopy negotiation fails, so the failure is silent rather than broken — but remote desktop is unavailable.
Potential solutions (in order of preference):
- Run the agent as the session user and grant network capabilities via
setcap cap_net_raw,cap_net_admin+eip— requires removing the hardis_root()exit check and adding the session user to theinputgroup for uinput access - Spawn a small privileged-drop helper binary that runs as the session user, connects to Wayland, and streams frames back over a Unix socket
- Implement xdg-desktop-portal + PipeWire screen capture — compositor-agnostic but shows a one-time user-approval dialog that cannot be displayed in the browser UI; requires the user to be physically present at the machine for first-run approval
2. GNOME / Mutter: zwlr_screencopy_manager_v1 not implemented
GNOME's compositor (Mutter) does not implement the wlr-screencopy protocol at all. Remote desktop is therefore unavailable on any GNOME Wayland session regardless of which user the agent runs as.
Affected sessions: GNOME on Wayland (Ubuntu 22.04+, Fedora Workstation, etc.)
Potential solution: xdg-desktop-portal + PipeWire (org.freedesktop.portal.ScreenCast) — this is the only screencopy path Mutter supports, but it has the first-run dialog problem described above.
3. Clipboard sync unavailable on pure Wayland
copypasta's ClipboardContext attempts an XCB/X11 handshake regardless of the active display protocol. On a pure Wayland session without XWayland, this always fails.
Current behaviour: clipboard initialisation failure is caught and clipboard sync is disabled for the session (graceful degradation). Remote desktop still opens; only clipboard paste/copy is non-functional.
Potential solution: add Wayland clipboard support via wl-clipboard or switch to the arboard crate which has native Wayland support.
4. Input injection (/dev/uinput) requires group membership
/dev/uinput is owned by root and the input group. When the agent is moved to run as the session user (the fix for issue 1), the user must be a member of the input group for uinput-based input injection to work.
Current behaviour: works when running as root; breaks if moved to session user without group setup.
Required: add the session user to the input group, or document this as a post-install step.
macOS — Not Implemented + Anticipated Issues
5. Screen capture not implemented
macOS falls through to the "Screen capture is not supported on this platform" error path. No capturer exists for Quartz/CoreGraphics.
Required implementation: CGDisplayCreateImage() (CoreGraphics, via the core-graphics crate) or ScreenCaptureKit (macOS 12.3+, stricter but modern).
6. Screen capture will require session context + TCC permission (same root problem, different mechanism)
Even once implemented, a root launchd daemon will face two separate blocks:
- WindowServer session access — the WindowServer is owned by the GUI login session. A daemon launched outside that session cannot connect to it regardless of UID.
- TCC Screen Recording permission — since macOS 10.15, all screen capture requires explicit user approval in System Settings → Privacy & Security → Screen Recording. Enforced by the TCC daemon against the binary's code-signing identity; root UID does not bypass it.
Consequence: the same architectural problem as Wayland — the agent must either run as a login item in the user's GUI session, or use a session-context helper process. Running as root is insufficient.
Summary
| Platform | Screen capture | Input injection | Clipboard |
|---|---|---|---|
| Linux / X11 (agent as root) | ✅ works | ✅ works | ✅ works |
| Linux / Wayland, KDE/KWin (agent as root) | ❌ UID restriction | ✅ uinput works | ❌ X11 only |
| Linux / Wayland, GNOME (agent as root) | ❌ protocol missing | ✅ uinput works | ❌ X11 only |
| Linux / Wayland (agent as session user) | ✅ works (KDE/sway/hyprland) | ⚠️ needs input group |
❌ X11 only |
| macOS | ❌ not implemented | ❓ not tested | ❓ not tested |
| Windows | ✅ GDI works | ✅ works | ✅ works |
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.