If you do a `ps -ef | grep vnc` while you're connected via Xrdp you should find the underlying vnc sessions. Something like:
Xvnc :32 -auth .Xauthority -geometry 1920x1080 -depth 24 -rfbauth....
It's been a bit mixed for us. As a sysadmin for non-technical users who need some linux access, it's wonderful because it's so much easier for them to connect. The stability has left quite a bit to be desired though - I have to nuke quite a few sessions and have them start from scratch.
On the server:
x11vnc -display :0 -noxdamage -shared -repeat -forever
On the client: ssh -T server 'nc 127.0.0.1 5900'
vncviewer 127.0.0.1:5900 ssh -N -L5900:127.0.0.1:5900 user@server
is usually cleaner than using nc, it doesn't require running any commands on the remote system and lets you do any port changing that you need to make things work between each side. ExecStart=ssh -T server 'nc 127.0.0.1 5900'
StandardInput=socket
StandardOutput=socket
in the service file and ListenStream=0.0.0.0:5900
in the socket file.The socket has to be connected to stdin/stdout instead of using SSH forwarding since SSH doesn't support fd-based socket activation.
It is like a vandal with a baseball bat.
Xrdp has an advantage in that it allows Windows to talk to Linux servers with its own Terminal Services client stack.
The only solution that worked for me, both configuration and performance wise, is sadly closed source - NX Server (which is excellent).
Also, if you look carefully at the default config mechanism, Xrdp does RDP to VNC translation internally, and runs Xvnc for each login.
Why is it ironic? I've been using systemd since before it was part of any distribution; it has been extremely convenient and helpful from the very start, and every year it gets even better (as new components mature enough to enable, e.g. systemd-timesyncd).