Remote Desktop using the RDP protocol for Plasma Wayland

With this blog I would like to introduce KRdp, which is a new library implementing the required glue to create a server exposing a KDE Plasma Wayland session over the RDP protocol. It also contains a command-line based server which will allow remote clients to control the current Plasma Wayland session.

Remote Desktop Support for Wayland

With the increase in people working from home the past years and other remote use cases, it has become increasingly important to be able to control a running computer remotely. While on X11 there are several existing solutions, for Wayland the choices are rather more limited. Currently the only way of allowing remote control of a Plasma Wayland session is through Krfb, which uses VNC¹ for streaming to the client.

Unfortunately, VNC is not ideal, for various reasons. So to provide a better experience we started looking at other options, eventually settling on building something around the RDP protocol. Fortunately, because of the work done for Krfb and various other projects, we do have all the parts implemented to allow remote desktop control, the "only" thing left was to glue everything together.

Why RDP?

This raises the obvious question of "why use RDP?". There were several things we considered when starting with this. From the start, we knew we wanted to build upon something pre-existing, as maintaining a protocol takes a lot of time and effort that are better spent elsewhere within KDE. Especially because a custom protocol would also mean maintaining the client side. Both VNC and RDP have many existing clients that can be used, which means we can focus on the server side instead.

Image

Another major consideration is performance. VNC sends uncompressed images of the full screen over the wire, which means it requires a lot of bandwidth and performance suffers accordingly. While I have seen some efforts to change this, they are not standardised and it is unclear what clients would support those. RDP, on the other hand, has a documented extension called the "Graphics Pipeline" that allows using H.264 to compress video, greatly reducing the needed bandwidth.

The main drawback of RDP is that it is owned by Microsoft and developed for the needs of Windows. While a potential problem, the protocol is openly documented and, equally important for us, there is an extensive open-source implementation of both server and client side of the protocol in the form of FreeRDP. This means we do not need to bother with the details of the protocol and can instead focus on the higher level of gluing everything together.

While I am talking about client support and performance since those were some of our main considerations, RDP has many more documented extensions that, long term, would allow us to greatly enhance the remote desktop experience by adding features such as audio streaming, clipboard integration and file sharing.

Other Considerations

While the protocol was one major thing that needed to be considered for a good remote desktop experience, it was not the only part. As mentioned, we technically have all the pieces needed to enable remote desktop, but some of those pieces needed some additional work to really shine. One example of this is the video encoding implemented in KPipeWire.

Image

During development of KRdp it became clear that using pure software encoding was a bottleneck for a responsive remote desktop experience. We tried several things to improve its performance, but ultimately concluded that we would need to use hardware encoding for the best experience. This resulted in KPipeWire now being able to use VA-API for hardware accelerated video encoding, which not only benefits KRdp but also Spectacle once it is released with KDE Plasma 6.

Another part is the KDE implementation of the FreeDesktop Remote Desktop portal. While it would be possible to directly communicate with KWin to request remote input and a video stream, we preferred to use the portal so that it would be possible to run KRdp from within a sandboxed environment. However, the current implementation is fairly limited, only allowing you to choose to accept or reject a remote desktop request. We are working on adding some of the same features to the remote desktop portal as are already available for the screencasting portal. This includes screen selection and remembering the session settings.

KRdp

So all that leads us back to KRdp, which is a library that implements the glue to tie all these parts together to allow remote desktop using the RDP protocol. It uses the FreeDesktop Remote Desktop portal interface to request a video stream and remote input from KWin, uses KPipeWire to encode the video stream to H.264 and FreeRDP to send that to a remote client and receive input from that client. The long term goal is to integrate this as a system service into KDE Plasma, with a fairly simple System Settings page to enable it and set some options.

Trying it Out

For those who want to try it out, we are releasing an alpha as a Flatpak bundle that can be downloaded from here. This Flatpak, when run using flatpak run org.kde.krdp -u {username} -p {password} will start a server and listen for incoming connections from remote hosts. See the readme for more details and known issues. The Flatpak bundle was built from this code. If you encounter any other issues, please file them at bugs.kde.org.

Discuss this blog post at discuss.kde.org.