RTX 4090 [nvidia-open 610.43.02]: HDMI 2.1 FRL rate mis-selected on sink power-cycle — 4K@143.86/120/100 pruned to TMDS until reboot (KDE Wayland)
System
Summary
Cold boot trains FRL and 3840x2160@143.86 (VRR-derived) works. After the TV is
physically powered OFF and back ON during a running session, FRL is mis-selected
on re-detect: link drops to TMDS and every >594 MHz mode (4K@100/120/143.86) is
pruned — only 4K@60 remains. Full reboot restores it. Windows 11 on the same
hardware recovers without reboot.
Proof it is driver-side
- Raw EDID byte-identical good vs bad (
cmp clean, product code unchanged) → not the EDID.
- With the helper daemon stopped,
kscreen-doctor -o itself drops 4K>60 → mode list is from the driver, not KWin. HDR on/off does not change the list.
nvidia-bug-report in the bad state reports protocol : TMDS.- No userspace recovery: KMS re-modeset (rejected — single output) and DPMS off/on do not re-train; only reboot / another physical power-cycle does.
force_frl_rate gradient (the bug is in FRL rate selection)
/sys/module/nvidia_modeset/parameters/force_frl_rate, retested per value (reboot + power-cycle):
| value |
hotplug result |
0 (default) |
TMDS, 4K@60 (143.86 only on cold boot) |
1 (max FRL, no DSC) |
FRL, 4K@120 — 143.86 never returns |
2 (max FRL + DSC) |
TMDS, 4K@60 (DSC negotiation fails) |
Forcing the rate deterministically changes the outcome, and none restore the
VRR-derived 4K@143.86 on hotplug → points at the FRL rate / VRR-mode selection
on the hotplug re-detect path.
Repro
- Boot → 4K@143.86 works.
- Power off TV, wait ~10s, power on.
- 4K@100/120/143.86 gone, stuck at 4K@60 until reboot (non-deterministic).
Evidence
GOOD/BAD display-state dumps + both raw EDIDs (byte-identical):
https://gist.github.com/filipemendespi/dd6c1db5ec179b606667638a6a927567
(EDIDs are base64; base64 -d FILE.b64 > FILE)
Full nvidia-bug-report.log.gz (captured in the BAD state, shows protocol : TMDS)
available privately on request — withheld here as it contains host/network identifiers.
RTX 4090 [nvidia-open 610.43.02]: HDMI 2.1 FRL rate mis-selected on sink power-cycle — 4K@143.86/120/100 pruned to TMDS until reboot (KDE Wayland)
System
video=HDMI-A-1:e) — so this is not nvidia-drm: force-enabled HDMI connector does not set link-status to Bad when sink stops responding #1084.Summary
Cold boot trains FRL and
3840x2160@143.86(VRR-derived) works. After the TV isphysically powered OFF and back ON during a running session, FRL is mis-selected
on re-detect: link drops to TMDS and every >594 MHz mode (4K@100/120/143.86) is
pruned — only 4K@60 remains. Full reboot restores it. Windows 11 on the same
hardware recovers without reboot.
Proof it is driver-side
cmpclean, product code unchanged) → not the EDID.kscreen-doctor -oitself drops 4K>60 → mode list is from the driver, not KWin. HDR on/off does not change the list.nvidia-bug-reportin the bad state reportsprotocol : TMDS.force_frl_rate gradient (the bug is in FRL rate selection)
/sys/module/nvidia_modeset/parameters/force_frl_rate, retested per value (reboot + power-cycle):0(default)1(max FRL, no DSC)2(max FRL + DSC)Forcing the rate deterministically changes the outcome, and none restore the
VRR-derived 4K@143.86 on hotplug → points at the FRL rate / VRR-mode selection
on the hotplug re-detect path.
Repro
Evidence
GOOD/BAD display-state dumps + both raw EDIDs (byte-identical):
https://gist.github.com/filipemendespi/dd6c1db5ec179b606667638a6a927567
(EDIDs are base64;
base64 -d FILE.b64 > FILE)Full
nvidia-bug-report.log.gz(captured in the BAD state, showsprotocol : TMDS)available privately on request — withheld here as it contains host/network identifiers.