There is rdp support in Fedora 40, available through the packages xrdp and xorgxrdp-glamor. I started by roughly following the instructions by HarmfulBreeze on GitHub, along with the comment by nreith. Though when I tried connecting with enhanced session mode enabled it said something about being unable to start the X session.

I had a hunch, and indeed grepping journalctl -b for AVC showed that it was an SELinux denial getting in the way. The sealert tool suggested using audit2allow to create a policy that allows whatever was denied, but the RedHat SELinux Troubleshooting documentation says audit2allow should be a last resort, so I hesitated. I eventually found an article on installing xrdp on Fedora which looks every bit like blogspam, but it did suggest

$ sudo chcon --type=bin_t /usr/sbin/xrdp
$ sudo chcon --type=bin_t /usr/sbin/xrdp-sesman

This seems to have solved the problem of avc denials when setting up a new X session.

That problem out of the way, the connection attempt still failed, although now it was far less obvious why. The visible symptom was that it disconnected immediately upon connection. By grepping for xrdp in journalctl -b I found a helpful warning:

[WARN ] Window manager (pid 1838, display 10) exited quickly (0 secs). This could indicate a window manager config problem

Further up in the logs, it also informed me that it tried to launch the window manager through /usr/libexec/xrdp/startwm-bash.sh. I sprinkled various debug prints3³ Something mature like echo "GETTING HERE" > /tmp/aaahah. in that script and the ones it called, to figure out where it crashed. It seemed to get all the way to my .Xclients, so I set up a known location for XMonad to log to, by changing the .Xclients script to say

#!/bin/sh
exec xmonad > "$HOME/.xmonad/logs/xmonad-$(date +%Y-%m-%dT%H:%M:%S).txt" 2>&1

It turns out XMonad was the thing that crashed, with the unhelpful error message

xmonad-x86_64-linux: user error (openDisplay)

I still don’t know what that means, but as part of my debugging I changed my .Xclients script to

#!/bin/sh

if [ -n "$XRDP_SESSION" ]; then
    echo "$DISPLAY" > /tmp/wuhuh
    exec xmonad > "$HOME/.xmonad/logs/xmonad-$(date +%Y-%m-%dT%H:%M:%S).txt" 2>&1
else
    exec xmonad > "$HOME/.xmonad/logs/xmonad-$(date +%Y-%m-%dT%H:%M:%S).txt" 2>&1
fi

And for some weird reason, that seems to have made it work. Can you spot the difference? The only thing it does different under rdp is dumping the $DISPLAY variable into a file before starting XMonad. I have no idea why that works, but I’m also not really in a mood to start poking at it, now that it’s running.

At this point, it was surprisingly painless to get sound going. I expected it to be further trouble because Fedora 40 uses PipeWire rather than PulseAudio4⁴ Is that how that sentence is shaped? I know too little about these things. so I was close to postponing solving that problem further.5⁵ I don’t really use sound in my work other than for video conferencing and music, and my phone can do those things in a pinch.

I followed the instructions in the readme of pipewire-module-xrdp to install the module, and then re-connected to the vm, opting to transfer remote sound to and from my physical machine. Although the Windows volume mixer indicated that sound was playing at that point, I didn’t get any sound either through headphones or built-in speakers. I also didn’t get any sound from Windows, so I tried solving the problem as one solves problems with Windows: I rebooted the computer.

Lo and behold! That produced sound on the built-in speakers. When I connected my headphones, sound still … worked, but there was an odd crackling and uneven volume. This problem seems to go away with a reboot, but then it comes back. I don’t yet know how to fix it.6⁶ I am currently circumventing this problem by through a high-quality bluetooth dac instead.

There were a lot of false starts and red herrings to chase along the way. The whole ordeal from Linux vm without sound (through the native connection method) to one with sound (through rdp) took about three hours. The points listed above above are, I think, the main obstacles that held me back.

I was a bit concerned about running this setup with an external monitor. I love the way XMonad handles multiple monitors on native Linux – that is one of the primary reasons I use XMonad – and it is not obvious that rdp will do the right thing and connect each physical monitor as a separate X montor.

But it does! Rejoice. This one worked right out of the box.

As mentioned in an earlier sidenote, the webcam cannot be captured by the vm. I have experimented a little with streaming it from Windows over udp using ffmpeg, but not achieved anything satisfying yet7⁷ It is finicky and comes with a hefty delay., so for the time being, I’m setting up my phone on a stand for video conferencing.

Oh, dear $deity! This started just today with the most recent Windows update. Now the vm is considered by Windows to be a video game and thus it is no longer allowed to capture the Super+G key combination, because that launches an abomination called Game Bar which sits on top of the vm. To continue using the vm, the Game Bar first needs to be closed.

This wouldn’t be a problem, were it not for the fact that

• G is the physical key which corresponds to D under Colemak,
• I use an external Apple keyboard on which I have swapped Meta and Super, and
• I frequently delete word forward with Meta-D in Emacs and readline.

Under this unlucky combination of circumstances, Meta-D in Emacs gets interpreted as Super-G in Windows, which launches Game Bar. I can’t delete words forward anymore! And I haven’t found a way to turn this off. I have found guides for how to do it, but the toggle they reference is not visible in my Windows settings. Please send help.