Force-enabled virtual connector won't bring up FRL — capped at 4K60 despite EDID Max_FRL_Rate=6 (blocks headless 4K120 Sunshine/Moonlight)

[HarryAnkers]

Hey I've been relentlessly trying to get 4k 120hz to work on sunshine / moonlight with the latest version of cachyos. I've tried overything but buying a 4k120hz monitor to stub the monitor. All virtual monitor solutions seem borked on the nvidia side sadly. Please may someone look at this. Heres my 3 hours of clauding summary:

Setup: RTX 3060 Ti on nvidia-open 610.43.02, CachyOS, KDE Plasma 6.6 on Wayland, kernel 7.x. The goal is a headless virtual display so I can stream 4K120 HDR to a Mac over Moonlight with nothing physically plugged into the GPU.

What works: I can force a virtual display with drm.edid_firmware + video=HDMI-A-1:e and a custom EDID, and SDR up to 4K60 is fine. I even got HDR working, but only on the HDMI connector and only with a real, well-formed EDID (a dumped AOC monitor EDID). HDR enable gets rejected on DisplayPort, and it's also rejected with a hand-built EDID even on HDMI. So the driver does honor HDR signaling as long as the sink descriptor looks real enough.

What doesn't work: 4K120. No matter what I do the forced connector caps at 4K60. The reason seems to be that 4K120 needs FRL (HDMI 2.1) or DSC, and the driver won't bring either up unless there's a real sink doing the SCDC/DPCD handshake.

The bit that makes me think this is a driver policy rather than a real limit: I fed it an EDID that declares Max_FRL_Rate=6 (48 Gbps) with VIC 118 (3840x2160@120) in the normal RGB video data block. edid-decode validates it as clean, and the kernel reads it back fine:

cat /sys/class/drm/card1-HDMI-A-1/edid | edid-decode
...
Max Fixed Rate Link: 3 and 6 Gbps per lane on 3 lanes, 6, 8, 10 and 12 Gbps on 4 lanes

Despite that, the driver only ever offers 3840x2160@50/59/60 and prunes 4K120. So it isn't the EDID being malformed; the driver is reading the FRL declaration and still refusing to bring up the high-bandwidth link because nothing is physically attached.

For comparison, gamescope --backend headless renders 4K120 (and HDR) totally fine with no connector involved at all, so the GPU and encoder can clearly do it. And amdgpu doesn't have this restriction for virtual displays. So it really looks specific to NVIDIA's connector mode validation.

The ask: for headless / virtual-display streaming, could the driver honor an EDID-declared FRL/DSC capability on a force-enabled connector, or expose some way to set the virtual connector's max link rate? Right now the only route to 4K120 (HDR or SDR) is to physically plug a display in, which defeats the whole point of a headless streaming box.

Happy to share the EDIDs, full logs, or run any test that would help.

[HarryAnkers]

Full writeup of the setup, the FRL smoking-gun (kernel reads Max Fixed Rate Link back correctly but still prunes 4K120), and the gamescope/amdgpu comparison, as a gist: https://gist.github.com/HarryAnkers/62da15b4957d9ace6cd72275777e8c19

[Rohithmatham12]

There is one existing knob that may be worth testing on this repro before this gets treated as requiring a new virtual-connector policy path: nvidia-modeset.force_frl_rate.

From the open module source, kernel-open/nvidia-modeset/nvidia-modeset-linux.c exposes:

• force_frl_rate=1: force max FRL rate
• force_frl_rate=2: force max FRL rate with DSC
• force_frl_rate=0: default

That value is consumed by GetForceMaxFrlRateType() in src/nvidia-modeset/src/nvkms-hdmi.c, then fed into NvHdmi_QueryFRLConfig() during HDMI FRL mode validation.

Could you try booting with one of these, ideally first nvidia-modeset.force_frl_rate=1 and then nvidia-modeset.force_frl_rate=2, while keeping the same drm.edid_firmware=... video=HDMI-A-1:e setup?

If 4K120 appears with force_frl_rate=1/2, then the EDID-declared FRL caps are probably being parsed but the default FRL-rate selection is too conservative for force-enabled connectors. If it still gets pruned at 4K60, that would strongly suggest the force-enabled path lacks enough sink/link state for nvHdmiFrlAssessLink() or later FRL config, despite the EDID advertising Max_FRL_Rate=6.

Either result would be useful, and the exact dmesg lines around any HDMI FRL link training failed / fallback messages would help narrow whether this is mode validation vs link training.

[Rohithmatham12]

I opened a draft PR with a small opt-in change for this path: #1186

The patch makes nvidia-modeset.force_frl_rate also skip the physical FRL link-training assessment during capability probing, so the HDMI library can use the override EDID's declared FRL caps when the user explicitly opts in. Default behavior with force_frl_rate=0 is unchanged.

If you are able to test it, the useful cases would be:

• nvidia-modeset.force_frl_rate=1 with your Max_FRL_Rate=6 HDMI EDID
• nvidia-modeset.force_frl_rate=2 if the mode still needs DSC

The key result to check is whether 3840x2160@120 appears on the force-enabled HDMI connector and whether modeset/streaming succeeds. I do not have the same headless HDMI 2.1 setup locally, so I left the PR as draft pending hardware validation.