modeset: honor forced FRL rate during link assessment

[Rohithmatham12]

Summary

• Treat nvidia-modeset.force_frl_rate as an explicit opt-in to use EDID-declared FRL capabilities during HDMI FRL link assessment.
• Leave the default physical link-training assessment path unchanged when force_frl_rate=0.
• Update the module parameter description so modinfo reflects the EDID-capability behavior.

This helps forced/headless HDMI connectors where a valid override EDID advertises FRL (for example Max_FRL_Rate=6) but physical link assessment cannot complete because there is no real sink handshake, causing high-bandwidth modes such as 4K120 to be pruned.

Fixes #1184.

Testing

• git diff --check
• make -C kernel-open -n modules
  • Reached the kernel build handoff and then stopped in this macOS workspace because /lib/modules/25.5.0/build is not present.
• Reporter validation on Force-enabled virtual connector won't bring up FRL — capped at 4K60 despite EDID Max_FRL_Rate=6 (blocks headless 4K120 Sunshine/Moonlight) #1184 / this PR:
  • Hardware/software: RTX 3060 Ti, nvidia-open 610.43.02, kernel 7.0.11
  • Boot setup: drm.edid_firmware=HDMI-A-1:edid/<file> video=HDMI-A-1:e
  • Override EDID advertises Max_FRL_Rate=6 plus VIC 118
  • Stock driver with nvidia-modeset.force_frl_rate=1 and =2 still stayed capped at 4K60
  • With this patch plus nvidia-modeset.force_frl_rate=1, 3840x2160@119.88 appears and sets on the force-enabled HDMI connector
  • HDR also enables and Sunshine HEVC Main10 streaming was confirmed end to end
  • Custom high-bandwidth DisplayID timings such as 3024x1890@120 and 2752x2064@120 also validate and set

[Rohithmatham12]

Thanks for testing and confirming the HDMI force-enabled connector case. I updated the PR description with your validation details and marked the PR ready for review.

The key confirmation is that stock nvidia-modeset.force_frl_rate=1/2 still capped the forced HDMI connector at 4K60, while this patch plus nvidia-modeset.force_frl_rate=1 exposed and set 3840x2160@119.88, with HDR/Sunshine HEVC Main10 working end to end.

[HarryAnkers]

Hardware validation on RTX 3060 Ti (GA104), nvidia-open 610.43.02, kernel 7.0.11, KDE Plasma 6.6 Wayland, headless HDMI connector force-enabled via drm.edid_firmware=HDMI-A-1:edid/<file> video=HDMI-A-1:e with an EDID declaring Max_FRL_Rate=6 and VIC 118 (3840x2160@120):

Without this patch (stock 610.43.02): force_frl_rate=1 and =2 both load but the connector stays pruned to 4K60, with no FRL messages in dmesg at all — the FRL path is never entered.

With this patch + nvidia-modeset.force_frl_rate=1:

• Patched module confirmed loaded (updated force_frl_rate parm description visible in modinfo).
• 3840x2160@119.88 appears in the mode list and sets successfully. The driver logs nvidia-modeset: WARNING: GPU:0: HDMI FRL link training failed. and proceeds with the modeset — sensible for a sink-less connector.
• HDR enables on top of the 4K120 mode; verified end to end with Sunshine KMS capture encoding HEVC Main10.
• Also exercised with higher custom timings (3024x1890@120 and 2752x2064@120 at ~764 MHz pixel clock, injected via a DisplayID extension block) — both validate and set under the forced FRL.
• Regression check: behavior with force_frl_rate=0 (default) unchanged, and a physically connected monitor on the same GPU behaves normally.

This is exactly the headless HDMI 2.1 setup from #1184 — works as designed. Happy to run any additional tests.

[KWottrich]

What is still outstanding on this PR? Is it just waiting for maintainer review?
I have this same issue and would benefit from bypassing FRL link training on a headless HDMI connector

[Rohithmatham12]

Yes, as far as I know this is waiting on NVIDIA maintainer review.

The current branch has the scoped HDMI change, the default force_frl_rate=0 path is intended to remain unchanged, and @HarryAnkers provided hardware validation for the headless HDMI case: stock 610.43.02 stayed capped at 4K60, while this patch plus nvidia-modeset.force_frl_rate=1 exposed and set 3840x2160@119.88, with HDR/Sunshine HEVC Main10 working end to end.

I do not have additional maintainer-side requirements yet. If NVIDIA wants a rebase, style change, or another test matrix, I can follow up.

[helloabunai]

RTX 3090, nvidia-open-dkms 610.43.03, Linux 7.1.5, hyprland/aquamarine.

mentioning that this also works for me; headless HDMI output via kernel EDID override (drm.edid_firmware=). The EDID now (with this code + nvidia-modeset.force_frl_rate=1 in boot launcher) properly advertises 48 Gbps FRL + VIC 118 (4K@120) + BT2020/PQ HDR, with no physical HDMI 2.1 sink attached to the card. I have a pacman hook that applies this PR as a patch whenever nvidia-open-dkms is updated, until this is merged.

edit: gist with pacman hook https://gist.github.com/helloabunai/9325592ba7b576160005052f2d26f6e2

thanks for the work, hopefully merged soon

[KWottrich]

RTX 3090, nvidia-open-dkms 610.43.03, Linux 7.1.5, hyprland/aquamarine.

mentioning that this also works for me; headless HDMI output via kernel EDID override (drm.edid_firmware=). The EDID now (with this code + nvidia-modeset.force_frl_rate=1 in boot launcher) properly advertises 48 Gbps FRL + VIC 118 (4K@120) + BT2020/PQ HDR, with no physical HDMI 2.1 sink attached to the card. I have a pacman hook that applies this PR as a patch whenever nvidia-open-dkms is updated, until this is merged.

thanks for the work, hopefully merged soon

If at all possible @helloabunai, could you share the pacman hook for applying this every update? Maybe in a gist you link here or something? I had hoped to do that for myself but didn't have the knowledge or time to do so. Thank you in advance!

[Rohithmatham12]

Hi @Binary-Eater, could you please take a look at this modeset change when available?

The PR has now been independently validated on RTX 3060 Ti and RTX 3090 systems. In both cases, the stock driver remained capped at 4K60 on a force-enabled headless HDMI connector, while this patch with nvidia-modeset.force_frl_rate=1 exposed and successfully set 4K120 with HDR. The testers also reported that normal physical-display behavior remained unchanged.

The branch is currently mergeable, and I am happy to address any implementation concerns or additional test requests.