UPDATE: Making Linux RDP smarter than Windows, not just a copy of it
A few months ago I published a white paper and posted it to the IronRDP project as an issue. The argument: We can make Linux RDP better, more performant and efficient than it is in Windows by using information and efficiencies only Linux has. The key is to provide those metrics and information through the protocol stacks so that RDP implementations can act on it.
Since the paper I've been working towards that goal with improvements submitted to IronRDP, Wayland, the portal, PipeWire, and libei, among other projects. A good amount has already landed, and the rest is moving with the maintainers. Here's where things stand today.
What's landed: Metrics in the protocol and the portal
Start with what's shipped. In IronRDP, the RDP library that lamco-rdp-server is built on, the server now collects quality-of-experience metrics, decode and render time, frame round-trip latency, bytes sent, and backpressure, through a QoE collector that landed upstream (#1167). Alongside it, the network auto-detect machinery merged too (#1168, #1176): RTT and bandwidth measurement, the protocol primitives a server uses to understand the connection it's serving. That's the metrics floor for adaptation, and it's in.
Up at the capture layer, the screen-capture portal now carries stream-identity metadata. The pipewire-serial change merged into xdg-desktop-portal, giving each ScreenCast stream a stable serial so a long-lived session can follow it through monitor changes. The wlroots backend landed the v6 update that exposes it, reviewed and merged by Simon Ser. KDE consumes the same serial. A piece of metadata that wasn't in the portal a few months ago is standard across backends now.
What's coming soon
The newer work is moving up through the stack, and it's the part I'm most engaged in right now.
Capture timing as a metric. The capture protocol tells a client when a frame is ready, and the number an encoder really wants is how long the copy took so it can budget the time it has. I proposed adding it as a wayland-protocols event, backed by capture-timing data from lamco-probe, and the design got better in the open: Andri Yngvason of wayvnc and Kenny Levinsen refined it toward sampling timestamps. This lines up with Simon Ser's own render-timer API. It's now a protocol merge request with green CI and a wlroots reference implementation alongside it.
Dynamic stream metadata now in PipeWire's core. When a stream's geometry changes mid-session, its position, size, scale, or transform, downstream needs to hear about it. That conversation started at the portal and climbed: Wim Taymans, the PipeWire lead, is steering it as PipeWire RFC #5305 toward per-buffer SPA metadata. The portal side stays as the cross-project anchor, and I added a ScreenCast integration test so the new properties stay covered.
Input stream state into libei's Rust stack. For input a consumer needs to see the state of the
connection, the seats, and the devices rather than reconstruct it. The reis maintainer, Ian Scott (ids1024), flagged that gap himself, and I implemented it: reis #21 adds ConnectionState, SeatState, and DeviceState. After a review round in mid-June it converged on a clean shape we both liked, and it's close. The device-lifecycle pieces (#22, #23) and the COSMIC EIS path
(Smithay #1388) are moving in the same direction.
The whole stack is moving
The best part is that this isn't a solo push. The people who maintain these projects are engaged and improving the work: The IronRDP, PipeWire, and portal maintainers, the wlroots and KDE teams converging on the same stream serial, and the libei maintainer pulling input-state tracking in. Metrics and health for the Linux capture and input pipeline went from an idea to a live, multi-project effort in a few months, which is how this is supposed to work.
Where it comes together
All of this feeds one place: lamco-rdp-server, the Wayland-native RDP server I'm building. It already runs a mature health system, seven subsystems and more than thirty metrics over D-Bus, with adaptive frame rate and latency governance, and it consumes the upstream metadata directly: The portal serial, the capture instrumentation, the input state. The codecs are heading upstream into IronRDP too, so the encoding side is shared, not just mine. The point of putting metrics and health into every layer, the protocol, the capture stream, PipeWire, and libei, is a remote desktop that can watch itself and adapt, which is a thing a straight Windows port can't do.
If you want the full argument, the white paper has it. If you want the server it all feeds, lamco-rdp-server and its source are where it's going.
New to the project? The lamco-rdp-server introduction covers what the server is, why I bet on RDP native to Wayland covers the approach, and xdg-desktop-portal-generic is the portal backend that puts this metadata to work.