The Wayland Diversity Challenge

Wayland compositors vary wildly in capabilities. GNOME provides Portal-based screen capture but handles session persistence differently than KDE. Sway offers direct wlroots protocols. Hyprland has its own portal backend. COSMIC is actively developing its portal implementation. Traditional RDP servers assume a homogeneous X11 environment and fail when expected features are missing.

Lamco RDP Server solves this with intelligent runtime adaptation.

Our Service Advertisement Registry detects 18 distinct Wayland services at startup and determines their availability and feature level on your specific platform. The server then adapts its behavior: selecting optimal codecs, enabling bandwidth optimizations when damage tracking exists, adjusting to clipboard API variations, and choosing the right session persistence strategy for your compositor.

18 Services Across 3 Categories

Display Services (8)

Video quality, bandwidth optimization, and visual fidelity

Damage Tracking

Detects which screen regions changed, enabling bandwidth optimization by only encoding modified tiles.

Status: Production ready on tested platforms

DMA-BUF Zero-Copy

Direct GPU buffer sharing without memory copies for lower CPU usage and latency.

Status: Implementation complete, platform-dependent availability

Explicit Sync

GPU synchronization primitives for tear-free video encoding.

Status: Available on KDE Plasma 6.0+, wlroots compositors

Fractional Scaling

Proper HiDPI scaling detection for correct resolution reporting to RDP clients.

Status: Working across tested platforms

Metadata Cursor

Compositor provides cursor metadata (shape, position) for client-side rendering.

Status: Production ready on most compositors

Multi-Monitor

Multiple display support with coordinate mapping and resolution change handling.

Status: Working, behavior varies by platform

Window Capture

Per-window capture instead of full desktop (future enhancement).

Status: Future enhancement, detection ready

HDR Color Space

High dynamic range color space support for accurate color reproduction.

Status: In development, tracking Wayland HDR protocol progress

Input/Output Services (3)

Screen streaming, user interaction, and data exchange

Video Capture

Screen content streaming via PipeWire.

Source: Portal ScreenCast or wlr-screencopy-v1

Status: Production ready across tested platforms

Remote Input

Keyboard and mouse injection for controlling the remote desktop.

Source: Portal RemoteDesktop, libei/EIS, or wlr-virtual-pointer/keyboard

Status: Working on GNOME platforms, implementation complete for KDE/wlroots

Clipboard

Bidirectional copy/paste synchronization between client and server.

Source: Portal RemoteDesktop v2+, SelectionOwnerChanged signals

Status: Platform-dependent (requires Portal v5 or KDE SelectionOwnerChanged)

Session Management Services (7)

Persistence, unattended access, and strategy selection

Session Persistence

Zero-dialog reconnection using Portal restore tokens or direct APIs.

Status: Platform-dependent, multi-strategy implementation complete

Direct Compositor API

Bypass Portal using compositor-specific D-Bus APIs (Mutter Direct for GNOME).

Status: Implementation complete, testing in progress

Credential Storage

Encrypted session token storage in Keyring, Secret Portal, or TPM 2.0.

Status: Production ready, AES-256-GCM encryption

Unattended Access

Automatic session restoration without user interaction.

Status: Implementation complete, platform testing ongoing

wlr-Screencopy

Direct screen capture via wlroots-specific protocol.

Status: Implementation complete for Sway, Hyprland, River, Wayfire

wlr-DirectInput

Direct input injection via wlr-virtual-keyboard/pointer protocols.

Status: Zero-dialog implementation complete (1,050 lines)

libei Input

Emulated Input System for Flatpak sandboxed input injection.

Status: Implementation complete (480 lines), tracking Portal backend PRs

Feature Availability by Platform

✅ Production Ready

Tested and working reliably on tested platforms

Example: GNOME 46 Video Capture via PipeWire

Ubuntu 24.04 testing: 593 frames encoded, 0 drops, ~10ms average latency. Stable in production use.

⏳ Testing in Progress

Code complete, validation and testing underway

Example: KDE Plasma 6 Session Persistence

Portal token support implemented. Testing infrastructure being set up for KDE platforms.

🔧 Platform-Dependent

Availability varies by compositor, Portal version, or deployment method

Example: Clipboard Support

Works on Portal v5+ (Ubuntu 24.04, Fedora 40+). Portal v4/v1 platforms (RHEL 9) use different approaches. Server adapts automatically.

🚧 In Development

Being actively developed or waiting on upstream support

Example: HDR Color Space Support

Implementation planned. Waiting for Wayland HDR protocol stabilization and compositor adoption.

Practical Example: Ubuntu 24.04 Detection

When Lamco RDP Server starts on Ubuntu 24.04 (GNOME 46, Portal v5, Flatpak deployment), the Service Advertisement Registry detects:

[INFO] Service Advertisement Registry initialized

[INFO] Compositor: GNOME 46.0

[INFO] Portal: org.freedesktop.portal.Desktop v5

---

✅ Video Capture → Portal ScreenCast v4

✅ Remote Input → Portal RemoteDesktop v2

💡 Clipboard → Portal RemoteDesktop v2 (text/image)

✅ Damage Tracking → PipeWire buffer metadata

✅ Metadata Cursor → ScreenCast cursor modes

🔧 DMA-BUF Zero-Copy → Platform uses MemFd (adapting)

💡 Session Persistence → Varies by deployment method

---

[ADAPT] Enabling H.264/AVC444 (4:4:4 chroma)

[ADAPT] Enabling adaptive FPS (5-60 FPS)

[ADAPT] Using MemFd buffer path for this platform

[ADAPT] Clipboard: text/image (file staging in sandbox)

Result: Server automatically configures itself for optimal performance on this specific platform. AVC444 encoding enabled, adaptive FPS active, clipboard working for text/images, graceful fallback to MemFd when DMA-BUF unavailable.

Zero Configuration Required

You don't configure anything. The server probes your compositor, detects capabilities, and automatically selects the best features available. When something isn't supported, you get clear diagnostics—not cryptic failures.

How Detection Works

Startup Probe Sequence

1

Wayland Compositor Globals

Query which Wayland protocols the compositor advertises (wl_registry interface)

Example: wlr-screencopy-v1, wlr-virtual-pointer-v1 detected → wlroots compositor

2

XDG Desktop Portal Capabilities

Connect to org.freedesktop.portal.Desktop and introspect available interfaces

Example: ScreenCast v4, RemoteDesktop v2 → Full Portal support

3

Portal Version & Interface Support

Check Portal version (v3, v4, v5) and which RemoteDesktop interface version is available

Critical: RemoteDesktop v1 lacks clipboard, v2 adds clipboard support

4

Platform-Specific Quirks

Detect known platform issues and apply automatic workarounds

Example: RHEL 9 + Mesa 22.x → Disable AVC444 (blur issue), force AVC420

5

Deployment Constraints

Determine if running in Flatpak sandbox vs native system environment

Flatpak: GPU acceleration unavailable, Portal-only APIs, staging area for files

Service Registry Data Structure

The probing process builds a ServiceRegistry object with 18 services, each mapped to:

Wayland Source

Which protocol or portal provides this service

Example: Portal ScreenCast v4, wlr-screencopy-v1

RDP Capability

How this service appears to RDP clients

Example: H.264 codec, AVC444 color depth, RemoteFX

Feature Status

Production ready, testing in progress, platform-dependent, or in development

Determined by: Testing results + platform capabilities + protocol versions

Performance Hints

Recommended FPS, latency overhead, zero-copy availability

Example: DMA-BUF → 60 FPS ok, MemFd → 30 FPS recommended

Why Service Discovery Matters

Intelligent Runtime Adaptation

→ Automatically adapts to each platform's specific capabilities
→ Clear diagnostic feedback showing detected features and configuration
→ Optimal performance on every compositor without manual configuration
→ Platform-specific optimizations and workarounds applied automatically
→ Works across GNOME, KDE, wlroots, and actively developing compositors like COSMIC

Adaptation Examples by Platform

RHEL 9 (GNOME 40, Portal v4)

Detected:

• Portal RemoteDesktop v1 (no clipboard interface)
• Mesa 22.x graphics stack
• GNOME Mutter 40

Automatic Adaptations:

• Force AVC420 (disable AVC444 due to Mesa quirk)
• Disable clipboard (Portal v1 limitation)
• Use Mutter Direct API path (native packages)

Result: Video and input work perfectly. Clipboard unavailable due to platform Portal version. Users get clear log messages explaining why.

Sway / Hyprland (wlroots, native package)

Detected:

• wlr-screencopy-v1 protocol
• wlr-virtual-keyboard-v1, wlr-virtual-pointer-v1
• Native protocol support available

Automatic Adaptations:

• Select wlr-direct strategy (1,050 lines)
• Enable zero-dialog operation (native protocols)
• Multi-monitor coordinate transformation

Result: Direct protocol access bypasses Portal entirely. Zero permission dialogs. Expected to work excellently for server deployments.

KDE Plasma 6 (Portal v5)

Expected Detection:

• Portal ScreenCast + RemoteDesktop v2
• SelectionOwnerChanged clipboard signals
• Portal restore token support
• DMA-BUF zero-copy capability

Expected Adaptations:

• Enable AVC444 (full 4:4:4 chroma)
• Use DMA-BUF zero-copy path (lower CPU)
• Enable session token persistence
• SelectionOwnerChanged clipboard (stable)

Prediction: Expected to work better than GNOME due to Portal token support and stable clipboard implementation. Testing infrastructure in progress.

The Power of Runtime Adaptation

Service Discovery means Lamco RDP Server works reliably across the diverse Wayland ecosystem without requiring you to understand Portal versions, protocol differences, or platform quirks.

🎯 Optimal Performance

Always uses the best available features for your specific platform combination

🔧 Zero Configuration

No manual tweaking required—the server figures it out automatically

📊 Clear Diagnostics

Log output shows exactly which services are available and why

For Developers & Advanced Users

How can I see the Service Registry output?

Run the server with the --show-capabilities flag:

flatpak run ai.lamco.rdp-server --show-capabilities
# or: lamco-rdp-server --show-capabilities (native package)

This displays the complete Service Registry with all 18 services and their guarantee levels before starting the RDP server.

Can I override service detection?

Yes, for testing or working around issues. Example flags:

--force-avc420 # Disable AVC444 even if available
--force-avc444 # Force AVC444 (ignore platform quirks)
--disable-damage-track # Disable damage tracking optimization
--force-software-encode # Disable GPU acceleration

Note: Overrides may cause issues if the platform truly doesn't support the feature. Use only for debugging.

Which platforms have the broadest feature support?

Feature availability (v1.2.0):

Ubuntu 24.04 (GNOME 46): Video, input, clipboard, damage tracking, multi-monitor working in production
KDE Plasma 6 (expected): DMA-BUF zero-copy, portal token support, SelectionOwnerChanged clipboard signals
wlroots (Sway/Hyprland, native): Direct protocol access, zero dialogs, multi-monitor transformation
RHEL 9 (GNOME 40): Video and input working, Portal v4 platform characteristics

As compositors and Portal backends evolve, feature coverage expands. Testing ongoing across platforms.

How does the server adapt when features vary by platform?

The server intelligently adjusts its configuration:

Example 1: Clipboard on Portal v4 platforms
→ Server detects Portal version, adapts clipboard strategy accordingly. Logs show current platform capabilities.
Example 2: DMA-BUF on different compositors
→ Falls back to MemFd buffer path when DMA-BUF not available. Performance remains good.
Example 3: Hardware acceleration in Flatpak
→ Uses OpenH264 software encoder. Works well, just higher CPU usage (~30% vs 5%).

The server adapts transparently—you get clear feedback in logs about what's being used.

How does this handle future compositor updates?

Service Discovery is dynamic, not hard-coded:

• When COSMIC adds RemoteDesktop portal → Automatically detected and used
• When GNOME adds DMA-BUF support → Zero-copy path automatically enabled
• When wlroots Portal backends merge EIS support → libei strategy automatically selected in Flatpak

No server updates required—the registry probes capabilities at every startup.

Questions? Ask on GitHub →

Service Discovery & Runtime Adaptation