Start here: check capabilities

Before troubleshooting a specific symptom, verify what the running session exposes:

lamco-rdp-server --show-capabilities

Look for Portal (RemoteDesktop and ScreenCast) or the relevant direct-capture protocol, and an available Encoding backend.

First connection fails, second succeeds

This is normal behavior with self-signed TLS certificates. On the first connection, the RDP client encounters an untrusted certificate and may fail or prompt the user to accept it. The second connection succeeds because the client has cached the certificate.

Fix: Accept the certificate warning on your RDP client, or deploy a trusted TLS certificate. See the Security page for custom certificate configuration.

Clipboard: Linux to Windows not working (Flatpak/Snap)

In Flatpak and Snap installations, clipboard transfer from Linux to Windows is not supported. This is a limitation of the XDG Desktop Portal API, which only provides clipboard access in the Windows-to-Linux direction. On native installs, the persistent clipboard monitor binds ext-data-control-v1 and clipboard is fully bidirectional, including file copy in both directions (Windows to Linux, and Linux to Windows). On KDE Plasma, Windows to Linux file copy needs Plasma 6.6 or later (KDE Bug 515465 limits Plasma 6.3.90 to 6.5.x to text-only cooperation).

Workaround: Use a native installation (.deb, .rpm, AUR, or from source) for full bidirectional clipboard support.

Clipboard not working at all (Flatpak)

Flatpak clipboard support requires the RemoteDesktop portal v2, which is only available on:

GNOME 45 or later
KDE Plasma 6.3 or later

Fix: Update your desktop environment to a version that supports RemoteDesktop v2, or switch to a native installation.

Permission dialog on every start (GNOME)

GNOME does not persist RemoteDesktop portal sessions by design. Each time the server starts, GNOME will prompt the user to authorize screen sharing again.

Note: This is a GNOME design decision and cannot be changed by lamco-rdp-server. KDE Plasma and other compositors may persist the authorization.

"Unknown (not in Wayland session?)" message

This message is cosmetic and appears in Flatpak sandboxes where certain Wayland environment variables are not exposed. It does not affect functionality.

Action: This can be safely ignored. The server operates correctly through XDG Desktop Portals regardless of this message.

No video / black screen

A black screen usually indicates that PipeWire is not running or xdg-desktop-portal is not responding. The server captures video through PipeWire via the ScreenCast portal.

# Check PipeWire status
systemctl --user status pipewire

# Check xdg-desktop-portal status
systemctl --user status xdg-desktop-portal

Fix: Ensure both PipeWire and xdg-desktop-portal are running. Restart them if needed:

systemctl --user restart pipewire xdg-desktop-portal

High CPU usage

Software video encoding can consume significant CPU resources, especially at high resolutions and frame rates.

Fix: Enable hardware encoding to offload video compression to the GPU:

[video]
encoder = "vaapi" # or "nvenc" for NVIDIA GPUs

Check available hardware encoders with: vainfo (VA-API) or nvidia-smi (NVENC).

Video freezes when a fullscreen or maximised video plays (GNOME)

Fixed in 1.4.5 by area capture. Mutter stops recording a monitor stream while a surface is handed to direct scanout (mutter#3903; the upstream fix mutter!5276 is approved but unreleased), which froze the remote picture for the length of any video.

Fix: Keep capture.gnome_record_mode = "auto", the default. If it still happens, check the log for "direct scanout" and confirm the mode is not monitor.

Video is blurry or laggy on GNOME

Mutter can over-report how much of the frame changed, claiming 91 to 97 percent on nearly every frame while the true change is under 1 percent. The server then re-encodes almost the whole frame every time and spreads its bitrate over pixels that did not move.

Fixed in 1.4.5. The server detects the divergence and switches to its own pixel-diff detector for the connection, reporting a CompositorDamageHintsDistrusted health event. Tune with the damage_tracking.compositor_hint_distrust_* keys if needed.

Hardware encoding is enabled but the log says software

Run lamco-rdp-server --show-capabilities. From 1.4.5 startup names the reason: the vainfo tool (libva-utils) is not installed, the VA driver exposes no H.264 encode entrypoint, or there is no GPU render node.

Only VA-API is used for EGFX today. NVENC and Vulkan Video builds fall back to software.

Fix: Install vainfo and a VA driver with H.264 encode. On Fedora that is mesa-va-drivers-freeworld from RPM Fusion for AMD, or the Intel media driver.

No audio on the client

Check audio.enabled, that PipeWire is running, and that the client negotiated a codec (rdpsee or rdpdo info shows rdpsnd).

1.4.5 is the first release where capture actually starts. mstsc pitch and drift are fixed in the same release.

Input stops working on GNOME after a while

The EIS reconnect storm is fixed in 1.4.5: a device that is slow to appear no longer triggers a full reconnect that discards every device.

If input never starts at all: check the log for EisStreamEnded.

The server crashed when the client disconnected

Fixed in 1.4.5. lamco-pipewire no longer calls the PipeWire deinit that freed process-global state a still-running thread was built on.

The port I set in config.toml is ignored

Fixed in 1.4.5 (#63). --port carried a default of 3389, so it was always populated and silently overwrote the configured port on every launch, including a port saved from the GUI. The file is now authoritative unless --port or --listen is given explicitly.

Copy from Linux stops working after the first paste from Windows (GNOME)

Fixed in 1.4.5. Announcing the remote's formats made the server the selection owner, and Mutter refuses to let an owner read its own selection back, so every later paste failed. The server now answers from its own cached copy instead of asking Mutter to read a selection it owns.

RemoteFX or older clients see no picture on an idle desktop

Fixed in 1.4.5 (#57). The first-frame replay was gated on AVC support, which is permanently false for a RemoteFX or V8 client, so on a desktop idle enough that damage-driven capture produced nothing the session was declared dead before a frame ever went out. The replay now requires only EGFX readiness, and also fires once the EGFX gate deadline passes.

Systemd says lamco-rdp-server.service is not enabled after upgrade

The unit is now app-io.lamco.rdp-server.service. xdg-desktop-portal derives an app id from the unit name only when it starts with app-, and portal permission persistence keys on that id.

Fix: Enable it once with the new name: systemctl --user enable --now app-io.lamco.rdp-server.service. The old name still resolves as an alias.

KDE Plasma 6.3.90 to 6.5.x: clipboard crash

The portal-kde clipboard crash (KDE bug 515465, fixed in 6.6) is now called out in the log when Klipper cooperation mode is chosen.

Fix: Upgrade to Plasma 6.6 or newer.

wayfire drops many frames

Capture requests are now paced to video.target_fps or performance.adaptive_fps.max_fps, whichever is higher. Previously the request loop asked for the next frame the instant the previous one landed, and wayfire services requests as fast as asked.

Raise those values if you want more, and expect the compositor to keep up only within its own repaint rate.

Per-compositor issues

COSMIC: if the mouse does not move, grant /dev/uinput access (COSMIC has no wlr-virtual-pointer yet). Video and keyboard work without it. See the COSMIC guide.
KDE: Windows to Linux file copy needs Plasma 6.6 or later (KDE Bug 515465 on 6.5.x and earlier). See the KDE guide.
sway / Hyprland: colors skewed (blue rendered as brown) was a wl_shm format issue, fixed in 1.4.4; capture is wlr-screencopy. See the sway / wlroots guide or the Hyprland guide.

Also see the GNOME / Mutter guide.

Audio problems

No audio at all: confirm PipeWire is running (systemctl --user status pipewire) and that [audio] enabled = true in the config.
Choppy or crackling audio: usually a codec mismatch between server and client during negotiation; try forcing codec = "opus" instead of "auto".
Audio disabled unexpectedly: check [audio] enabled in config.toml.

Troubleshooting