Just a data point, this issue has gone away with 550.144 of the nvidia drivers, it is still present on 570.
The display is a HDR display, and I am not sure whether it makes any difference that HDR is enabled on this display at 144Hz. All I know is that it does not wake up properly from sleep when the display rate is higher than 30Hz with the 570 version of nvidia’s drivers
Yeah, this issue is not solved on the latest beta drivers (575.51)
It does not appear to be affected by HDR on or off, just refresh rates higher than 30Hz.
I just had a kernel update to 6.14.2, and now my workaround of using 550 drivers does not work anymore because the kernel modules won’t build. So, this is very much still an issue.
Hi @evorster ,
On the BenQ EX3210U, it is resolved on 550 drivers after upgrading the firmware?
It is still an issue on newer drivers such as the 570 series?
Hi there!
That is correct.
With the 550 series drivers, the monitor has no issues, and has no issues in windows on the latest drivers either. Admittedly, I have not checked the version in Windows, but I know that it is fully updated.
Upon a wakeup event with the 570 series drivers the monitor looks like it switches on, but does not detect a signal, and switches back off.
By manually switching off the monitor power and powering it back on, sometimes I see my desktop on the Benq monitor, but I can’t move my mouse there, and the KDE display app seems to think the monitor is off.
Which leads me to think there is some confusion in the driver as to which logical screen to output to, but this may just be a side effect of something deeper.
HDR on or off does not seem to make any difference, as does applying a color profile or not in non-HDR mode.
I have not checked on GNOME, and this is on Wayland. Last time I checked with X11 session the issue was identical, but this may have been before the firmware update on the monitor.
The issue seems identical with both the proprietary and open versions of the beta nVidia drivers.
Thank you for looking into this!
If there is any testing or data gathering, or even something you would like me to try, I would be happy to help.
I have an interesting data point for you.
This issue pops up with supergfxctl in Hybrid mode. However, if I switch the system to AsusMuxDgpu mode, and the nVidia card handles all the screens and compositing, this issue does not happen.
Since the dGPU fires up anyways to drive the external monitor, there is no power saving benefits to be had from Hybrid mode, and it is easy enough to switch.
So, I guess the title should be changed to Monitor not resuming from sleep with a refresh rate higher than 30Hz when the computer is in Hybrid mode?
The problem very definitely exists, but there is a workaround, so I will not mark this reply as a solution.
Half a year, and it’s still not fixed. Broken external output is a major bug for a GPU, in my book. What gives, Nvidia? Too busy counting money?
The unfortunate decision to update to Fedora 42 which doesn’t offer the option to install older drivers has rendered my laptop basically useless. There’s no 30 Hz mode on my monitor as a proposed workaround either. The craziest part is that this bug survives a reboot and even a hard shutdown! The only way I’ve found to make my monitor work again is to boot into Windows.
Hi there!
I have been using my workaround of using AsusMuxDgpu mode for a while now, and when 570.153.02 version of the drivers dropped, I thought that I would give this another try.
I switched back into Hybrid mode, and this issue still persists.
AsusMuxDgpu mode is only available on laptops that physically have the MUX chip installed, and so this workaround is not available on all Advanced Optimus laptops.
It has been six months now that this issue has been identified, and there has been very little feedback from nVidia on this issue.
I am available to give extra information on this issue, just please tell me what tests you would like me to run, and I will gladly do it.
Drivers 555+ enabled “HDMI DeepColor” (10 BPC) by default, which can push 4K@60Hz displays from TMDS to FRL mode, affecting monitor behavior. You can disable it by loading the ‘nvidia-modeset’ kernel module with ‘hdmi_deepcolor=0’, which may avoid the issue for 60 Hz, but will likely persist for higher refresh rates.
With 550.147, were you running with 4K@60Hz, or higher refresh rate? If the former, it’s possible that HDMI DeepColor made the difference. Does the issue reproduce on 550.147 with higher refresh rates or with the ‘nvidia-modeset’ kernel module loaded with ‘hdmi_deepcolor=1’ ?
Thank you for the update.
I’ll try the kernel parameter.
However, I was running 4K@144Hz, with HDR enabled. Still am running it now with the system in AsusMuxDgpu mode. With the 550 series of drivers the HDR mode was not available, but back then the monitor also woke up without issue in 4K@144Hz. The 550 series of driver is now broken for me, as some packages that I have installed is calling it old and do not want to run anymore because of it.
To be clear, this monitor has no issue waking up in 4K@144Hz HDR mode when the laptop is in AsusMuxDgpu mode. This mode uses the nVidia GPU to drive both monitors. This tells me that there is nothing wrong with the monitor, and that the driver has some issue with working through the Advanced Opitmus MUX.
I tried with the kernel parameter nvidia-modeset.hdmi_deepcolor=0
Sorry to report, but the monitor still did not wake up at high refresh rates.
Here is a journal of that run. I turned off and on the monitor a few times to get KDE to re-detect it. Somewhere along the line, the behaviour changed somewhat, and now the monitor does not come up at all on boot when it has been previously configured for 4K@144Hz.
Monitor_Not_Waking_up_Journal.txt (526.4 KB)
Just for your info, here is a nvidia-bug-report from when the system is working:
nvidia-bug-report.log.gz (1.0 MB)
Thanks @evorster ,
To be clear, I would only expect the option to make a difference for 4K@60Hz. Refresh rates over 60 Hz will use FRL regardless.
Here is an nvidia-bug-report when the system is in Hybrid mode, and the external monitor is not driven. (Or does not detect a signal)
nvidia-bug-report.log.gz (969.0 KB)
Thanks again for looking into this.
Just to re-iterate.
When the system is in Hybrid mode, the external monitor does not wake up if its refresh rate is higher than 30Hz.
When the system is in AsusMuxDgpu mode, the external monitor wakes up just fine in any more, including 4K@144Hz HDR.
Same monitor, same settings, same cabling, same software everything else is the same. Literally just issuing sudo supergfxctl -m Hybrid and rebooting breaks it, and then issuing sudo supergfxctl -m AsusMuxDgpu and rebooting fixes it.
However, there are people who have high resolution high refresh rate monitors that do not have the option of AsusMuxDgpu as it is a piece of hardware that is only found in high end dual gpu laptops.
Hi there!
Just tested with the newly released 575.57.08 version of the driver, and sadly this issue is still present.
This bug is still affecting this computer in Hybrid mode.
I have changed over to the CachyOS kernel, and am now running version 575.64 of the nvidia drivers.
I’m relieved that I’m not alone is having this exact problem with my 4090. I just abandoned Windows and I thought things would be great on Linux-only. Using 570.172.08 with Ubuntu on Linux 6.8.0-40-generic, and a Samsung Odyssey G8 (HDR OLED) at 3440x1440 resolution and as soon as the display sleeps I have this problem. I’ll try the suggestions that were made in the thread, but it sounds like there is no working solution yet. Maybe I’ll at least try using HDMI instead of DisplayPort for now and seeing if that makes a difference.
Yay! Another one who shares my pain.
For now, when I run with a high resolution external display capable of high refresh rates, I set asusctl -m AsusMuxDpu. If you have it, this is the best option. (Your HP may have a different option for letting the dGPU handle eveything)
Your dGPU is going to be active all the time anyways to drive the HDMI.
Then, when I am on the road, I set Hybrid, which saves the most power.
See thing is I have a desktop with a 4090 PCI card, so that’s a good idea but won’t work for me :-P
Edit: For now, it looks like running at 60Hz (59.97Hz) on my 3440x1440 display is enough to have the display wake up from powersaving successfully. I hope that one day I can run at 120Hz…
I have the same problem with my desktop running a 4080 super. Connected to a 4k OLED screen I can only set it to 60Hz or else it won’t wakeup from sleep. The issue is present it the most recent driver and why are we even mention this bug when nothing is done with it?