bad resolution after monitor wakes up

[muff11n]

NVIDIA Open GPU Kernel Modules Version

nvidia-open-dkms 580.95.05

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

Arch Linux

Kernel Release

6.17.1

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 5080

Describe the bug

when monitor powers off after idle and then wakes up, sometimes the resolution is at 640x480, sddm restart doesn't fix the problem, only reboot

I haven't noticed anything special in journal, just this one thing, but not sure it's connected:
Oct 13 18:03:03 mypc kwin_wayland[4462]: Atomic modeset test failed! Permission denied
Oct 13 18:03:03 mypc kwin_wayland[4462]: Applying output configuration failed!
Oct 13 18:03:03 mypc systemd[1]: Started dbus-:1.2-org.kde.powerdevil.backlighthelper@1.service.
Oct 13 18:03:03 mypc backlighthelper[4780]: no kernel backlight interface found
Oct 13 18:03:03 mypc org_kde_powerdevil[4603]: org.kde.powerdevil.chargethresholdhelper.getthreshold failed "Charge thresholds are not supported by the kernel for this hardware"
Oct 13 18:03:03 mypc org_kde_powerdevil[4603]: org.kde.powerdevil.backlighthelper.brightness failed

KDE (plasma 6.4.5)

happens with normal and dkms driver, newest and previous release

To Reproduce

configure energy setting for monitor power off after 5 mins idle, wait till monitor is off, then move mouse or press a key to wake up the monitor

it's random, so not every time is the resolution bad

sometimes when I wake up the monitor immediately it doesn't happen, is there some GPU "power off" when the monitor is off for some time ?

I have connected main monitor via DP and TV via HDMI (but disabled)

Bug Incidence

Sometimes

nvidia-bug-report.log.gz

nvidia-bug-report.log.gz

More Info

No response

[BorisUitham]

(disclaimer, used ai to help draft me this because i am not knowledgable enough but i wanted to give as much relevant information as possible. excuse me if the llm made mistakes or wrong assumptions)
I can reproduce this on a very similar setup and have additional diagnostics that help narrow down the cause.
edidbugoutputs.tar.gz

nvidia-bug-report.log.gz

---

Environment:

• GPU: NVIDIA RTX 5080
• Driver: nvidia-open-dkms 590.48.01-6 (nvidia-drm.modeset=1)
• Kernel: 6.18.9-arch1-2
• Desktop: KDE Plasma 6 (Wayland)
• Affected monitor: Samsung Odyssey G65B (DisplayPort, DP-3)
• Second monitor: Dell P2425H (DisplayPort, DP-2, unaffected)

---

What the EDID actually looks like in the failed state

In the failed state, reading the EDID from sysfs (/sys/class/drm/card2-DP-3/edid) returns a minimal stub rather than the real monitor data:

Manufacturer: 0x3aC4 (unrecognised)
Product: 0x0000
Serial: (none)
Week/year: 0 / 1990
All detailed timing descriptor slots: empty
No extension blocks
Checksum: 0x92

In the working state the same connector returns the correct EDID: manufacturer SAM, Odyssey G65B, full timings including 2560×1440@120, HDR metadata, etc. The connector UUID reported by kscreen-doctor changes between states because it's derived from EDID content, confirming a different blob was ingested.

The stub has a valid checksum, so this is not a garbled read. it looks like a driver-synthesised or zeroed internal buffer being served instead of the real EDID.

---

Journal output in the failed state

org_kde_powerdevil: Retrying i2c_check_edid_exists_by_dh() tryctr=1, dh=Display_Handle[i2c-20]
org_kde_powerdevil: /dev/i2c-20, Checking EDID failed after 2 tries
org_kde_powerdevil: Unable to read EDID for /dev/i2c-20
org_kde_powerdevil: Failed to find connector name for /dev/i2c-20

kwin_wayland: EDID colorimetry xy(0.330078, 0.297852) xy(0.597656, 0.149414)
              xy(0.0605469, 0.314453) xy(0.328125, 0.00292969) is invalid

---

Additional: semsurf error and pageflip timeout on wake (from nvidia-bug-report.log)

The bug report log reveals a second symptom on the same wake event that is likely the same underlying failure. The sequence on Mar 10 09:43-09:45:

09:43:54  nvidia-suspend.service started
09:43:55  nvidia-suspend.service completed
09:44:14  kernel: [drm:__nv_drm_semsurf_wait_fence_work_cb [nvidia_drm]] *ERROR*
          [nvidia-drm] [GPU ID 0x00000100] Failed to register auto-value-update
          on pre-wait value for sync FD semaphore surface
09:44:15  nvidia-resume.service started
09:44:15  kwin_wayland: Pageflip timed out! This is a bug in the nvidia-drm kernel driver
09:44:16  kwin_wayland: Pageflip timed out! This is a bug in the nvidia-drm kernel driver
          [repeats every second for ~40 seconds]
09:45:23  kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR*
          [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 1
09:45:26  kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR*
          [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 1

The semsurf error fires before nvidia-resume even completes, then the display pipeline on head 1 (DP-3, the Samsung) deadlocks with continuous pageflip timeouts for ~40 seconds. KWin explicitly attributes this to the nvidia-drm driver. The EDID stub and the flip timeout appear to be two symptoms of the same broken state on head 1 following wake.

The same semsurf error appears on two other resume events in the log (Mar 09 21:40:46 and Mar 10 09:44:14), both immediately post-resume, suggesting it is consistently triggered by wake rather than being a random occurrence.

---

Hypothesis

The Samsung Odyssey G65B has a characteristically slow wake.it asserts HPD before its DDC/I²C bus is ready to serve the EDID. The driver fires the DDC read immediately on HPD assertion, the monitor isn't ready, and the driver caches the resulting stub without retrying. The Dell on the adjacent port wakes faster and is never affected.

The semsurf error and subsequent pageflip cascade suggest the display pipeline for head 1 enters a broken state during resume before the connector is fully re-initialised, and the EDID stub is a consequence of that rather than an independent failure.

Power-cycling the monitor resets HPD and triggers a fresh probe at a point when the monitor is fully initialised, which is why that always fixes it immediately without any cable reconnection or reboot.

I also filed a report on kernel.org bugzilla (#[221202]) but am commenting here as this is clearly the more appropriate tracker for an out-of-tree driver issue.