TL;DR — 1920×1080@60 over the KVM's single USB-C cable, stable across a KVM reboot and a cold Spark reboot, no manual step after boot. Five settings. Two are order-dependent.

If you plugged a GL-RMQ1 into a DGX Spark and got a black screen, this is the short path.

1. Turn Virtual Media OFF — do this first

The mass-storage function on the KVM's composite USB gadget wedges the Spark's usb-storage thread in an unkillable reset loop. It spreads to systemd, PID 1. The Spark then cannot reboot cleanly and you pull the power cord.

An empty virtual drive is enough to trigger it. You do not have to mount anything.

KVM web UI -> Virtual Media -> off

2. Set the device identity to "Logitech Unifying Receiver"

Under the default Glinet Composite Device the keyboard interface does not bind. You get three mice and no keyboard. The failure is silent unless you look — sudo dmesg | grep usbhid on the Spark:

usbhid 5-1:1.0: can't add hid device: -32 usbhid 5-1:1.0: probe with driver usbhid failed with error -32 

The Logitech profile binds interface 0 as a real keyboard. It is also friendlier to UEFI and firmware screens.

KVM web UI -> device identity -> Logitech Unifying Receiver

3. EDID -> Customize -> paste the capture chip's own EDID

No shipped preset gave a picture here. The 1024×768 preset failed too — the Spark latched the EDID and drove the right timing, and the receiver still refused to lock. What works is the GSV1127 capture chip's own factory EDID. 256 bytes, both checksums valid, preferred timing 1080p60. It survives a KVM reboot.

00 ff ff ff ff ff ff 00 1e 76 00 01 01 00 00 00 08 1c 01 04 c5 8e 50 78 1a 23 ad a4 54 4d 99 26 0f 47 4a 23 08 00 71 4f 81 00 81 40 81 80 95 00 95 0f b3 00 a9 40 02 3a 80 18 71 38 2d 40 58 2c 45 00 50 1d 74 00 00 1e 01 1d 00 72 51 d0 1e 20 6e 28 55 00 c4 8e 21 00 00 1e 00 00 00 fd 00 18 3d 87 87 17 01 0a 20 20 20 20 20 20 00 00 00 fc 00 47 53 56 20 48 44 4d 49 32 2e 31 20 20 01 3c 02 03 59 f2 4d 10 1f 04 13 05 14 20 21 22 03 12 07 16 32 0f 04 01 15 07 50 3d 1f c0 57 04 03 5f 7e 00 67 54 03 83 5f 00 00 6a 03 0c 00 10 00 30 2d 0f 08 00 ed 1a 00 00 02 01 00 ff 00 00 00 00 00 00 e2 00 ff e3 05 e3 00 e3 06 0f 01 eb 01 46 d0 00 45 0b 90 86 60 76 8f 02 3a 80 18 71 38 2d 40 58 2c 45 00 50 1d 74 00 00 1e 01 1d 00 72 51 d0 1e 20 6e 28 55 00 c4 8e 21 00 00 1e 00 00 31 

4. Bring the KVM up first, then boot the Spark — order matters

The Spark probes its USB-C DisplayPort outputs once, in a narrow window early in boot. If the sink is not powered and negotiated by then, it never looks again. Every output reads disconnected for the rest of that boot, and no software poking brings it back. This is a known NVIDIA issue with these ports.

Connect the cable, let the KVM finish booting (about 50 seconds), then power on the Spark.

5. Still black? Replug — or cycle the receiver over SSH

A physical unplug and replug is the only thing that fully renegotiates the link. Remotely, which is the point of a KVM, SSH into the KVM and cycle the receiver instead. This drops and re-asserts hot-plug detect, so the Spark re-reads the EDID:

echo 0 > /sys/bus/i2c/devices/0-0058/poweron sleep 3 echo 1 > /sys/bus/i2c/devices/0-0058/poweron 

Give it 15-20 seconds to settle before you judge the result.

Check it properly — one glance will lie to you

The characteristic failure is a link that holds about 9 seconds, drops about 1, and retrains forever. Sample it at the wrong instant and a broken link looks perfect. It fooled me repeatedly. Sample for a minute:

P=/sys/bus/i2c/devices/0-0058 for i in $(seq 60); do echo "$(cat $P/resolution) $(cat $P/mipi_streaming_state)" sleep 1 done | sort | uniq -c 

Anything other than 60 lines of 1920x1080@60 connected means it is flapping. Go back to step 5.

How I ran all of this remotely

The KVM is at another site, behind NAT. I did not forward a port or expose SSH to reach it. It runs the noBGP agent, so every command in this post ran over noBGP's MCP endpoint from an AI assistant session — the sysfs reads, the poweron cycle, and the 60-second stability sample. The 60 / 60 result above is raw output from that session, not a hand transcription.

That also made the flap easy to catch. Sampling once a second for a minute and reading the counts back is tedious by hand and trivial to drive this way.

Disclosure: noBGP is my own project.

Two things I cannot explain

• The same EDID failed earlier in testing. Same hardware, same cable, same settings, opposite results hours apart. Negotiation here is not deterministic, so this can come back.
• Lower resolution does not reliably help. Modes at half the bandwidth of 1080p60 failed while 1080p60 itself passed. Do not assume dropping the resolution fixes it.

Two smaller notes

• HDMI on the Spark is fine. Its HDMI port works normally and stably throughout. This problem is specific to DisplayPort over USB-C. This KVM takes video over USB-C only, which is why the USB-C route matters.
• macOS GLKVM app will not reconnect? Quit with Cmd-Q and relaunch. After the KVM restarts a few times the app keeps finding the device over mDNS but refuses to reconnect. The web UI at https://<kvm-ip> is the same interface.

Tested 2 September 2026 — DGX Spark (GB10, BIOS 5.36_0ACUM018, driver 595.84, Ubuntu 24.04.4, kernel 6.17.0-1032-nvidia) and a GL-RMQ1 on Buildroot rmq1-1.8.1-release3, connected by the KVM's single captive USB-C cable.