NVIDIA
GPU is not properly transitioning HDMI 2.1 displays from FRL (Fixed Rate Link) to TMDS (Transition Minimized Differential Signaling) during reboots
NVIDIA Open GPU Kernel Modules Version
560.35.03-18 x86_64
Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.
- [x] I confirm that this does not happen with the proprietary driver package.
Operating System and Version
Arch Linux
Kernel Release
6.11.5.arch1-1
Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.
- [x] I am running on a stable kernel release.
Hardware: GPU
Gigabyte RTX 3060 Ti LHR
Describe the bug
The GPU is not properly transitioning HDMI 2.1 displays from FRL (Fixed Rate Link) to TMDS (Transition Minimized Differential Signaling) during reboots. This causes a black screen during the BIOS/UEFI and Bootloader phase of the reboot process. Expected behavior is as follows: Display is in FRL mode when displaying the desktop environment, user initiates reboot, GPU transitions display to TMDS (required by bios/uefi and bootloader to produce video). This is how Windows and older LTS distros that do not have bleeding edge drivers or kernel support behave.
To Reproduce
Have an HDMI 2.1 connected monitor, preferably one that allows you to view signal information on the display itself such as an LG OLED TV, capable of saturating more than 18Gbps (required to be in FRL signal mode) and initiate a reboot. Notice the screen stays black and you do not see the PC's BIOS splash screen or the bootloader. Video returns once the linux kernel and initramfs are loaded.
Bug Incidence
Always
nvidia-bug-report.log.gz
More Info
I cannot pinpoint exactly when this bug started, but it is not present on LTS distros like Pop or Ubuntu. It seems to be some combination of kernel 6.11 or Nvidia 560. I have not been able to test 565 yet as it is not packaged for Arch at this time.
I think I can narrow this issue down to the fbdev option in nvidia_drm. The following steps will fix the issue, albeit at the expense of tty sessions having a very low/stretched resolution.
Set fbdev kernel parameter to 0 by creating nvidia-drm.conf in /usr/lib/modprobe.d (Arch Linux, may vary by distro) and add the following line:
options nvidia_drm modeset=1 fbdev=0
regenerate initramfs:
mkinitcpio -P
The next reboot will still have no bios screens but after the second one you should now always see the bios messages and boot-loader. You will also notice, that the boot messages on startup and shutdown/reboot in the tty now have a much lower resolution than before.
GPU transitions display to TMDS (required by bios/uefi and bootloader to produce video).
Erm, what? There is no requirement. uefi supports 1080p BIOS menu, 4k and HDMI 2.1...
Bootloader I hope youbare using is Linux kernel eufi stub.
It supports those video signals in TMDS mode. The issue is the GPU gets stuck in FRL mode for the duration of the boot so no video signal is displayed until the operating system loads. In Windows, the GPU gracefully transitions to TMDS during reboots, Linux using the Nvidia driver modules does not.
It supports those video signals in TMDS mode
The fix here would be to force GOP capsule driver to support FRL too. Not gonna happen, I imagine? Especially if we are using 12 bit/10 bit RGB.
@Binary-Eater , I've documented a NixOS reproducer and runtime results over here that may help internal debugging:
- https://forums.developer.nvidia.com/t/display-gets-stuck-in-frl-mode-during-reboot/310406/5
- https://forums.developer.nvidia.com/t/display-gets-stuck-in-frl-mode-during-reboot/310406/9
This has been an issue for SOOO long. I have no idea why, but I had a hunch it started when 30-bit color was enabled by default. By using the kernel parameter nvidia-modeset.hdmi_deepcolor=0, the problem is worked around—at the cost of losing 30-bit color.
The problem started for me when fbdev became mandatory, before that it was fine.
I hope there's movement internally, kind of discouraging to find a bug and then find the bug report about said bug that's 9 months old already.
Anyone know if the 580 beta fixed this issue? I noticed that the release notes said:
* Fixed a bug that could result in a black screen when setting specific modes on HDMI displays.
* Fixed a bug that caused blank or frozen screens under the following conditions: nvidia-drm is loaded with the modeset=1 and fbdev=1 parameters, using a Maxwell or Pascal series GPU, and more than one display device of differing resolutions are connected.
Anyone know if the 580 beta fixed this issue?
Just tested it, at least for me the 580 beta doesn't improve the situation. Every time I reboot my external screen on the NVIDIA GPU still remains blank ('no signal') until I switch to a TTY and back or re-plug the cable.
Just for completeness, but when this issue was reported I had this with my HDMI 2.1 display when HDMI was used as cable. I could fix it by switching to USB-C/DisplayPort. Since then (must be somewhere around 565 or 570), I also started experiencing it with other types of connectors (with the same HDMI 2.1 capable display, that is). Is this possible or does this imply there is a separate issue for DisplayPort/USB-C here?
Same here. Tested with 580.76.05 in Arch and I still get a black screen on reboots until my system finishes boot.
Just to follow up on my previous post: my specific issue on DisplayPort-over-USB-C was probably not this one as I managed to consistently fix the screen remaining black on boot (i.e. GDM) by early loading the NVIDIA driver modules on Arch. I do still have a similar issue with the monitor coming out of standby while the system is on, but have created https://github.com/NVIDIA/open-gpu-kernel-modules/issues/930 for that.
(Mentioning it in case the suggestion to early load helps anyone that might similarly incorrectly believe their issue is this one.)
Hey friends, just got the 580.105.08 update on Cachy and this seems to have been fixed, on my end at least.
I tested a reboot with the new 105 drivers as well and I was able to see my BIOS splash as well. Seems to have finally been addressed, woohoo!! 🎉
I can't believe this is finally fixed! Thank you @Binary-Eater and the rest of the Nvidia open source team for resolving this issue. It was one of the last major pain points I was having with the Linux drivers.
I can also confirm 580.105.08 resolves the issue, and I no longer require any hacks to reboot PCI to reset the GPU via kernel params on NixOS:
boot.kernelParams = [ "reboot=pci" ]; # Hack to reset HDMI for Nvidia GPU
> nvidia-smi
Fri Nov 14 14:04:27 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.105.08 Driver Version: 580.105.08 CUDA Version: 13.0 |
- https://github.com/NixOS/nixpkgs/pull/458794
Thank you for the fix, much appreciated!