With this blog I would like to introduce KRdp, which is a new library implementingthe required glue to create a server exposing a KDE Plasma Wayland session overthe RDP protocol. It also contains a command-line based serverwhich will allow remote clients to control the current Plasma Wayland session.
Video file
Remote Desktop Support for Wayland
With the increase in people working from home the past years and other remoteuse cases, it has become increasingly important to be able to control a runningcomputer remotely. While on X11 there are several existing solutions, forWayland the choices are rather more limited. Currently the only way of allowingremote control of a Plasma Wayland session is through Krfb, which uses VNC1for streaming to the client.
Unfortunately, VNC is not ideal, for various reasons. So to provide a betterexperience we started looking at other options, eventually settling on buildingsomething around the RDP protocol. Fortunately, because of the work done forKrfb and various other projects, we do have all the parts implemented to allowremote 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 thingswe considered when starting with this. From the start, we knew we wanted tobuild upon something pre-existing, as maintaining a protocol takes a lot oftime and effort that are better spent elsewhere within KDE. Especially becausea custom protocol would also mean maintaining the client side. Both VNC and RDPhave many existing clients that can be used, which means we can focus on theserver side instead.
Image
Another major consideration is performance. VNC sends uncompressed images ofthe full screen over the wire, which means it requires a lot of bandwidth andperformance 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 "GraphicsPipeline" that allows using H.264 to compress video, greatly reducing theneeded bandwidth.
The main drawback of RDP is that it is owned by Microsoft and developed for theneeds of Windows. While a potential problem, the protocol isopenly documented and, equally important for us, there is an extensiveopen-source implementation of both server and client side of the protocol inthe form of FreeRDP. This means we do not need to bother with the details ofthe protocol and can instead focus on the higher level of gluing everythingtogether.
While I am talking about client support and performance since those were someof our main considerations, RDP has many more documented extensions that, longterm, would allow us to greatly enhance the remote desktop experience by addingfeatures 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 goodremote desktop experience, it was not the only part. As mentioned, wetechnically have all the pieces needed to enable remote desktop, but some ofthose pieces needed some additional work to really shine. One example of thisis the video encoding implemented in KPipeWire.
Image
During development of KRdp it became clear that using pure software encodingwas a bottleneck for a responsive remote desktop experience. We tried severalthings to improve its performance, but ultimately concluded that we would needto use hardware encoding for the best experience. This resulted in KPipeWirenow being able to use VA-API for hardware accelerated video encoding, whichnot only benefits KRdp but also Spectacle once it is released with KDE Plasma 6.
Another part is the KDE implementation of the FreeDesktop Remote Desktopportal. While it would be possible to directly communicate with KWin to requestremote input and a video stream, we preferred to use the portal so that itwould be possible to run KRdp from within a sandboxed environment. However, thecurrent implementation is fairly limited, only allowing you to choose to acceptor reject a remote desktop request. We are working on adding some of the samefeatures to the remote desktop portal as are already available for thescreencasting portal. This includes screen selection and remembering thesession settings.
KRdp
So all that leads us back to KRdp, which is a library that implements the glueto tie all these parts together to allow remote desktop using the RDP protocol.It uses the FreeDesktop Remote Desktop portal interface to request a videostream and remote input from KWin, uses KPipeWire to encode the video streamto H.264 and FreeRDP to send that to a remote client and receive input from thatclient. 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 bundlethat can be downloaded from here. This Flatpak, when run usingflatpak run org.kde.krdp -u {username} -p {password} will start a serverand listen for incoming connections from remote hosts. See the readme for moredetails 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.
While strictly speaking the protocol used by VNC is called RemoteFramebuffer or RFB, VNC is the general term that is used everywhere, so that iswhat I am using here as well.↩
