v595.45.04 older HDMI 1.3 monitor fails to resume after sleep/monitor off

[mix3d]

NVIDIA Open GPU Kernel Modules Version

595.45.04

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.

• I confirm that this does not happen with the proprietary driver package.

Operating System and Version

CachyOS

Kernel Release

Linux cachyos 6.19.7-1-cachyos #1 SMP PREEMPT_DYNAMIC Fri, 13 Mar 2026 16:01:21 +0000 x86_64 GNU/Linux

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.

• I am running on a stable kernel release.

Hardware: GPU

GPU 0: NVIDIA GeForce RTX 3070 Ti (UUID: GPU-07b194b5-6400-26a1-7045-ddeca6e63058)

(If helpful; AMD 5800X3D, 32GB DDR4 RAM desktop.)

Describe the bug

I am new to linux as a desktop have been troubleshooting this with LLM support for hours, but to no avail.

From what I am observing, my older HDMI monitor (asus VH242H) will fail to resume after a second screen off attempt... which appears more to be a "fails to shut down properly" as the monitor still appears detected and available to the OS, but it takes a full power off to bring the monitor back. (via unplugging the power cord, the power button is not enough)

I am WAY out of my element in this space, LLMs suggested it's a handshake issue with the modern GSP and the older monitor's firmware / display driver.

I tried numerous driver/kernel mode changes in an attempt to fix this (LLM's throwing spaghetti at the wall attempts to fix):

nvidia-drm.modeset=1 and nvidia-drm.fbdev=1
NVreg_PreserveVideoMemoryAllocations=1 and a temp folder path
mem_sleep=deep and EnableS0ixPowerManagement=0
NVreg_EnableGpuFirmware=0 (though this allegedly does nothing on Open drivers)
NVreg_EnableDirectDisplay=0
video=HDMI-A-1:e and video=HDMI-A-1:D to force port state
forcing an EDID to the port with drm.edid_firmware=HDMI-A-1:edid/asus_vh242h.bin

I also tried on 580.142-1 proprietary driver and got the same behavior.

To Reproduce

• Sleep computer or let screen-off timeout (most reliably reproduced if the computer is put to sleep first, but does during monitor off too).
  • Both monitors (HDMI and DP) show the "display disconnected" OSD. The older monitor will also light the power button in this off state.
• Resume computer or wiggle mouse, observe both monitors resume
• Sleep computer or let screen-off timeout again.
  • Observe that the older monitor fails to shutdown properly, no "no signal" OSD message. Screen is off, but power button stays unlit. Monitor is now completely unresponsive to all physical buttons as well.
• Resume computer again, observe only the newer monitor resumes.
  • The older monitor is still detected by the OS and is "enabled", windows are drawn on it.
  • toggling monitor enabled/disabled via kscreen-doctor or the OS menu GUI does not help.

Bug Incidence

Always

nvidia-bug-report.log.gz

On latest Open driver:
nvidia-bug-report.log.gz

using proprietary driver:
nvidia-bug-report.proprietary.log.gz

More Info

Tangentially related... sometimes the Monitor's OSD will permanently display the input name. I have not been able to reliably reproduce this, however. None of these issues ever happened while on Windows.

I noticed a couple similar bug reports (like #1028), but they all pointed to DisplayPort devices and/or monitors on a dock, while mine is directly on HDMI and not occurring on the also-connected primary DP monitor.

Happy to run any additional troubleshooting commands.

[Binary-Eater]

Sanity checking because we recently had to WAR a behavior related to a specific Wayland compositor related to monitor light up, what Wayland compositor are you using?

[mix3d]

KDE Plasma? Is that the compositor?

[Binary-Eater]

Yeah that's right. We have a fix for this with KDE Plasma that did not land in 595 beta driver. It did land in 580.142, so I am a bit surprised you are seeing this. Would it be possible for you to compile a debug build of open-gpu-kernel-modules using 580.142 and share the logs after repro-ing this issue? If you need assistance with this, let me know and I can help draft some steps.

[mix3d]

Def need assistance. I can follow steps and am comfortable in the terminal, but I am in no way a Linux wizard. I'm on week 3 of fulltime desktop, but still running on a portable SSD. If this monitor issue can be fixed, I'll likely fully commit and wipe the windows 10 partition.