IronRDP on Linux

Hello

It's a long-term goal to add IronRDP as an embedded RDP option on all RDM platforms, Linux included. However, realistically we're still quite far from achieving that.

I'll follow with some internal details, but can I ask why the interest in an alternative RDP backend? There is not a huge landscape of RDP clients to start with, and FreeRDP remains far and away the best and most complete. Do you have a specific interest in IronRDP? Is there a feature or bug that is limiting you in some way with FreeRDP? If there is, you should let us know because in the current timeframe we're far more capable of addressing such things than accelerating the integration of IronRDP.

In terms of the status of the IronRDP project; the primary driver for us right now has been integration as a web client. We're able to offer features through the web with IronRDP that no-one else can. Because the code base is so modern and robust, we also plan to integrate it into RDM and hopefully - eventually - supplant FreeRDP with it. However, we're not really close to that point yet. IronRDP is massively behind FreeRDP in terms of features and the native client integration is quite immature. We have integrated it on RDM Windows but it's firmly "experimental" at this point; we love it if people try it out and it works for them but it's not realistically ready for use as a daily driver. We also have to consider our internal bandwidth, where integrating a half-baked RDP alternative is actually bad for us in a lot of ways as it increases bug reports and feature requests, and time has to be divided between the two backends. Balancing internal priorities is hard!

So, in short; IronRDP is coming but we still have a long road to travel. If you have a specific bug or feature request for FreeRDP, or you're just interested in IronRDP itself, or a specific RDP backend; I'd be happy to listen and discuss it further!

Please, let me know if you have some questions or something isn't clear

Kind regards,

Thanks for that detailed response!
The main reason is just that if a modern and memory-safe backend is available I prefer using it and I certainly think the IronRDP you guys are doing is great.
A second factor is if its available in RDM it might be possible to apply changes to upstream ironrdp and test with RDM - though not sure how feasiable that would be anyway and best option for that probably is having RDM run external ironrdp_client if I get that to work (The external setting seemed to behave strangely only applying if restarting RDM, sometimes not at all).
Certainly understandable in this case platform parity / land experimental support on Linux doesnt have priority.

A third factor is being able to try if it behaves better in some ways I dont like.
I'm not exactly sure if those are bugs or configuration (or unrelated limits somewhere in X11/Wayland/KDE interaction landscape) but my "issues" with the linux version mostly are:
- Clipboard seems to cut off long contents (e.g. copying file contents) after couple hundred lines
- File transfers with having to mount a local folder and not being able to directly copy&paste from dolphin is worse UX than windows
- (Havent found a UX optimal way (e.g. shortcut key) to switch between full-screen and window as tab in RDM, currently always doing multiple clicks and then dragging tab back to main window)

Hello

Yes, having a modern and memory-safe RDP backend is really important to us too. It will take time to get there. Internally we are no longer starting new projects in C/C++, new native code is written in memory-safe languages like rust. That is a policy moving forward. There is a sister project to IronRDP, (imaginatively named) IronVNC with similar goals for VNC and its derivatives.

Testing upstream changes with IronRDP may or may not be feasible, it depends on the changes. You have to remember that there is an intermediary FFI layer that sits between IronRDP and RDM, because RDM is a .NET application. So we have to write the interop code to make them talk with each other. IronRDP is not "batteries included" like FreeRDP, it pushes a lot of work down to the client (for example, it's not like FreeRDP where you can set up your options and just call "Connect()"). That being said, it really depends on the kind of changes- whether they are in the core, or they impact the settings used and so forth.

Finally, I can probably address a couple of your concerns with FreeRDP. The clipboard implementation on Linux is immature; it doesn't use delayed rendering. This is the reason for the string length limitation. It also only supports plain text. I can tell you that the RDM Linux team are working on fixing that at the moment because I've been providing some support to them. The full clipboard implementation won't limit text length, and will support other formats like images, HTML and rich text. File transfer will follow afterwards.

For your UX issue with switching to-and-from full screen, I'd recommend making a feature request so it gets visibility with the RDM Linux team.

We are really happy to see excitement around IronRDP. Since Cloudflare started to use it, the project has got a lot more visibility. We want it to be a flagship project for Devolutions.

Please, let me know if you have any questions or problems

Kind regards,