Were you able to choose color depth: GFX AVC420 (32 bpp) or GFX H264 AVC444 on your rdp client before connecting?
I also had to upgrade my rdp client to be able to choose said color depth. After, it worked.
The rdp client error message leading me to the rdp client upgrade was:
“Client did not advertise support for the Graphics Pipeline, closing connection”
What does it mean?
The error message “Client did not advertise support for the Graphics Pipeline, closing connection” originates from the server side (usually gnome-remote-desktop-daemon) and means that the RDP server requires the GFX extension, but Remmina (my rdp client) did not negotiate it correctly. Here is the technical background and possible solutions:
Technical Background
The error message refers to the RDP extension [MS-RDPEGFX] (Remote Desktop Protocol: Graphics Pipeline Extension), also known as “GFX” or “RDP 8/10 Graphics Pipeline.” This protocol enables efficient graphics transmission via H.264/AVC, Progressive Codec, and others, and is required in newer versions of GNOME Remote Desktop (gnome-remote-desktop starting with GNOME 46 / Ubuntu 24.04). The server actively closes the connection if the client does not announce this capability during the connection setup in the capability exchange.
Remmina uses FreeRDP internally as its RDP implementation. The problem typically occurs when an older FreeRDP version (2.x) encounters a server that requires FreeRDP 3.x, or when GFX negotiation is suppressed by incorrect connection settings in Remmina.
There are essentially three groups of causes:
-
Version incompatibility: The server (e.g., gnome-remote-desktop 46+) expects FreeRDP 3.x-compatible behavior; Remmina is still built with FreeRDP 2.x.
-
Incorrect color profile in Remmina: Certain settings (e.g., “RemoteFX 32bpp”) can affect GFX negotiation or cause conflicts
-
Missing H.264 support on the client: If the FreeRDP build variant does not include H.264, GFX may not be fully advertised
Maybe those hints help you to get ahead although you are using a Mac while I used a linux machine.
As solution I found with Perplexity:
You have actually two separate problems stacked on top of each other. The .rdp tweak fixed the first one (Error 0x207 / NLA handshake failure), but the black screen with a movable cursor after login is a distinct, second issue: GNOME Remote Desktop is starting your session under Wayland, which fails to render on headless NVIDIA hardware over RDP.
What Is Happening Exactly
The DGX Spark runs Ubuntu 24.04 with GNOME on Wayland by default. When you connect via the “Remote Login” feature (GNOME Remote Desktop / gnome-remote-desktop.service), it tries to spin up a new RDP session using the Wayland compositor. On a headless ARM system with NVIDIA GPU, the Wayland compositor cannot properly initialize a virtual display for the RDP session — you get the session (the cursor moves), but no desktop renders. The libfreerdp package downgrade you attempted was a fix for a different bug (an NLA/security regression in ubuntu1.4), which you already bypassed via the .rdp tweak.
Two Paths to Fix It
Path 1 — Disable Wayland, Stay with GNOME Remote Desktop
This is the less invasive fix. SSH into the DGX Spark and run:
bash
sudo nano /etc/gdm3/custom.conf
Find the [daemon] section and make sure this line is present and uncommented:
text
[daemon]
WaylandEnable=false
Then reboot. GNOME will now start X11 sessions, and GNOME Remote Desktop will hand off an X11-based desktop to your RDP client instead of a Wayland compositor.
Path 2 — Switch to xrdp (Most Reliable for DGX Spark + macOS)
Multiple DGX Spark users confirmed this as the most stable solution on macOS. The key is to first prevent gnome-remote-desktop from hogging port 3389:
bash
# 1. Stop and disable GNOME Remote Desktop
systemctl --user stop gnome-remote-desktop.service
gsettings set org.gnome.desktop.remote-desktop.rdp enable false
# 2. Disable Wayland in GDM
sudo bash -c 'echo -e "[daemon]\nWaylandEnable=false" >> /etc/gdm3/custom.conf'
# 3. Install xrdp
sudo apt install xrdp xorgxrdp -y
sudo usermod -a -G ssl-cert xrdp
# 4. Make sure xrdp uses X11
echo "export XDG_SESSION_TYPE=x11" | sudo tee -a /etc/xrdp/startwm.sh
# 5. Enable and start xrdp
sudo systemctl enable xrdp
sudo systemctl start xrdp
sudo reboot
After reboot, also go into GNOME Settings → System → Remote Desktop and make sure “Remote Login” is turned off there too, to prevent gnome-remote-desktop from grabbing port 3389 on the next login. Your .rdp file tweak (use redirection server name:i:1) can stay — it does not interfere with xrdp.
Why ubuntu1.5 Didn’t Help
The ubuntu1.5 packages fixed the NLA security regression (the “AcceptSecurityContext failed” error seen in logs), but they do nothing about the Wayland rendering failure — those are completely independent problems.
Good Luck!