Known working configurations and common issues

[alexleach]

Hi,

I'm writing this after spending over a week trying to get xrdp and xorgxrdp working on my Arch Linux system. Try as I may, I've all but failed, only ever connecting to black screens.

Rather than create another issue, as my issues may already be answered or solved elsewhere, I thought I'd start a discussion instead... A lot of these points relate to other repos made by contributors, but as this is the main one, I thought I'd write it here, hope that's okay 🙂 .

I've since set up Ubuntu 24.04 on a separate partition and xrdp works out of the box. However, it connected to a black screen if I had already logged into Gnome at the monitor, and it's not in the configuration I want to run it. My Arch Linux system is setup with secure boot and encrypted partitions, and runs several crucial docker workloads. Further, I've seen nvidia flavoured packages and am keen to take advantage of my GPU for hardware acceleration...

My Configuration
CPU: AMD Ryzen 9 5900X
GPU: Nvidia RTX 3070
OS: Arch Linux
Systemd
SDDM
Plasma
KDE

Google has brought me to many Issues, gists forks and separate repos, which have lots of useful information buried within. You guys appear to be doing a great job of responding to comments and moving xrdp forward. I'm quite excited about getting it working to be honest! However, I've been really struggling...

So, I've got some questions about the various projects, versions and configurations. I'm not sure if this is the best place to document answers to those questions (as then there's somewhere else to look!), but it would be nice to at least have links to documentation where I can find the answers to my questions...

---

Nvidia Hardware Acceleration

• Are there any plans to merge @Nexarian's forks and branches related to nvidia accelaration into https://github.com/neutrinolabs/xrdp ?

This gist shows how to set up xrdp with Nvidia acceleration: https://gist.github.com/Nexarian/0eb26a3284b21b55b6e1e8653ed88ec9. It uses two of his private repositories:

• https://github.com/Nexarian/xrdp/tree/mainline_merge
• https://github.com/Nexarian/xorgxrdp/tree/mainline_merge

No commits have made to these branches for a year old now, almost to the day. I'd love to see these integrated into the main repositories, but I haven't seen a PR, and there are now merge conflicts between his branches and the neutrinolabs devel repositories, which I've attempted to fix. Are there any plans to introduce those forks, or are there alternative plans for graphics acceleration?

Having tried using his forks, I think they might need some further work related to loading the nvidia code at runtime, but I'm not sure, as never got them working tbh...

---

Systemd Session workarounds

Systemd seems pretty common these days, and I've seen that there are issues related to graphical sessions on systemd.

@matt335672 has put together this great little repository for systemd users: https://github.com/matt335672/nest-systemd-user. It seems like another candidate for merging into https://github.com/neutrinolabs/xrdp?

---

Wayland

I've enjoyed seeing some discussion about Wayland. Has anyone tried running Xwayland -rootless instead of Xorg? I've tried myself, but as usual, black screen...

Other system quirks

Information on the above quirks in relation to Nvidia and Systemd are quite hard to find, as is information on compatible versions. I think I saw someone say xorgxrdp-nvidia doesn't work with xrdp version 0.10, but didn't see an explanation as to why?

I've also seem enabling glamor only works on non-nvidia hardware, is that still true and will it always be the case?

I think the xrdp and xorgxrdp projects are great and appear more active than some of the other user-space Linux rdp solutions (e.g. krdp, gnome-remote-desktop). I'm not a great C developer by any means, but I have a system I'd like to get working and I'd be happy to contribute testing changes to help improve compatibility with Nvidia hardware and systemd systems 🙂

[matt335672]

Hi @alexleach

In response to a few of your points:-

• There are plans on working on NVidia support for H.264 compression in the near future. I believe this isn't quite the same thing as @Nexarian's branches are providing, but it should be quite a jump forward. In the process of implementing that, I'm sure we'll bring forward any bits of @Nexarian's repos which make sense.
  As I understand it, these reason these branches haven't been updated recently is that we made a lot of changes for GFX support for v0.10.x. @Nexarian will correct me if I'm wrong on that, I'm sure.

• systemd. The recommendation is to use a separate user for xrdp sessions on systemd-based systems. It's annoying to many, but that's a pretty fundamental design-decision baked into systemd. We can't really fight this in a small project. @akarl10 made an eloquent case for change in this area in creation of session service type systemd/systemd#24932, but that sadly went nowhere.

  If you have a use-case which absolutely requires the same user for local and remote there are workarounds (as you post above), but relying on these working in the longer term (especially on a rolling distro like Arch) is risky.

[alexleach]

Thanks @matt335672.

Nvidia-accelerated RDP support is something I'm quite interested in, and I would be happy to test any early implementations. Do you know of any repos where they're being actively worked on?

I actually got @Nexarian's branches working over the weekend after making sure I was using his forks. The AUR package xorgxrdp-nvidia and various xrdp modules all refer to the neutrinolabs repositories, which I couldn't get working on my hardware. There are some quirks, but it's early days with it working for me and this isn't the place to report issues on those forks.

Yeah, I saw that request on systemd/systemd to add a session service type and a reference to it. I can't say I know enough about systemd internals to comment, but in my various testing, I did notice new instances of kwalletd loading each time I tried logging in, and loginctl list-sessions fills up with sessions that don't seem to close properly, without a manual loginctl kill-session. I've since added kwalletd.service to UNITS_TO_MASK in your systemd_user_context.sh script, too. I hope that will stop new kwalletd instances from launching with each RDP login...

Perhaps related to the whole systemd session thing (but not related to xrdp), is I've got a docker container running linuxserver.io/docker-blender, that I've been trying to accelerate using my GPU. The linuxserver.io docker images run Xvnc as a normal user account. When set up to run Xvnc in the container as my host system's user ID, passing through my GPU's display capability fails, although I can still render blender animations on the GPU using compute. (Referring to the related nvidia-container-toolkit capabilities here.) When Xvnc is run as a different host user (added to the hosts render and video groups), then I can use the display too. Makes a huge performance difference! It sounds like your suggestion of running xrdp as dedicated user accounts has some parallels with this, as this is another instance that works fine on Ubuntu, but not on Arch. That is, systemd could be the parting difference here... 🤷

The benefits of using the same accounts for local and remote seem pretty obvious and numerous without needing to spell them out, but I wouldn't say they fall into the "absolute requirements" category, at least outside of a highly regulated environment with licenses assigned to user accounts for instance, which isn't my use case. I just don't want to have a second user profile, with settings duplicated in two places, duplicate local mailbox files, permissions issues when trying to access documents between the user accounts, etc. Anyway, I thought the nested systemd user sessions that your repo addresses overcomes those issues? I understand it's pretty experimental at this stage, though.

Supporting all specific distros is obviously not in the remit of the core package, especially with rolling release ones like Arch(!), but as Systemd is so commonly used these days, even in RHEL since v7, I think it makes sense to (try to) support it fully in startwm.sh and xinitrc. It's a shame that neither @poettering or any other systemd expert offered any pragmatic solutions or alternatives to @akarl10's feature request.

Cheers,
Alex

[matt335672]

When we start working on hardware accelerated X264 in earnest, it will be in this repo. It's possible a couple of the guys are working on this, but I'm not aware of it.

I take your point about the hassle involved in keeping a couple of accounts set up and synchronised. The nested systemd approach seems to work at present, but has a couple of drawbacks I can see:-

1. The D-Bus address for the session is not not the default one, so any apps making assumptions about this will end up in the wrong session.
2. This isn't an approach which is officially sanctioned by the systemd team. That's by far my biggest concern, as we could be a single security advisory away from this approach being blocked. If that did happen (and I hope it doesn't) this will result in users being in the impossible position of implementing a fix for the SA, or continuing to with their existing work patterns. This might (or might not) be OK for single-user systems, but wouldn't be OK at all for a development team having to cope with deadlines.

At some point the systemd team may provide an official way to support this kind of working, and if so we will of course consider using it too. I suspect this will take the emergence of a compelling use-case which just isn't there yet.

[alexleach]

Thanks @matt335672.

Tbh, I thought (and hoped) that @Nexarian's mainline_merge branches might be heading towards a PR; people still appear to be using them for nvidia acceleration, and it now works quite nicely for me, too. 🙂

With the systemd sessions - where I'm far from an expert! - I would have thought the ideal scenario would be not to need a new session at all, but to use a single session that can be switched to and from a local sign-in at the physical console. I use RDP to connect to Windows client and server OS's a lot for work, where a remote session will lock the screen for the physical user, who can then take the session back if signing in again at the desktop. The current design choices around using systemd sessions all appear to want to start a separate session, which to be honest, I don't think is ideal. Is sharing the session not possible?

Having spent lots of time looking at the xrdp and xorgxrdp code, as well as Nvidia and RandR-related stuff, one idea / hope I had was that implementing the RandR v1.4 specification would allow switching output providers for the same desktop source. Nvidia has some documentation on it. With audio, pipewire should allow changing sinks on the fly, too? @Nexarian wrote a local RandR client in his mainline_merge branch, that is (mostly?) RandR v1.3 compliant. I did have a stab at adding some RandR v1.4 functionality here, but as I said, I'm not very experienced with C and was progressing too slowly to keep going with it. I've put a lot, if not all of the boiler plate there, though. Do you think RandR 1.4 could work like this?

[matt335672]

Using a single session would be great, but at the moment I can't see an easy way to support it.

I had a look at the RandR 1.4 stuff (which I was unaware of). There' a caveat on it :-

Support for PRIME Synchronization relies on DRM KMS support. See Chapter 35, Direct Rendering Manager Kernel Modesetting (DRM KMS) for more information.

My understanding of this is we'd somehow need to provide a KMS interface for the Xorg driver. I don't think this is something we're in a position to provide in this project. This would also be a Linux-only development which wouldn't be ideal.

I could well be wrong on this. @Nexarian - do you have a better handle on this area?

[alexleach]

Fair enough, I can't say I know how it could or should be implemented either tbh, but it would certainly be a fine achievement if that's where it ended up.

I think PRIME Sync is something specific to graphics card hardware drivers; the Arch wiki has a fairly good page on it. I don't know if it's Linux-only or not, but I wouldn't have thought xrdp or xorgxrdp would need to worry about KMS. There's already a modesetting driver built into X11, and I had to set kernel command line options for the nvidia_drm module, too: nvidia_drm.modeset=1 nvidia_drm.fbdev=1, which, as I understand it, offloads rendering or something to the nvidia X modules and then hardware. Again, that Arch wiki page has some good info on configuring it in userland, which I think just requires xorgxrdp to be a RandR v1.4-compatible provider sink.