DP-MST monitor stays black after brief signal drop — DRM connector enabled:disabled / dpms:Off while compositor reports active

[mnencia]

NVIDIA Open GPU Kernel Modules Version

595.45.04

Does this happen with the proprietary driver (of the same version) as well?

Not tested (only open kernel modules available for Blackwell)

Operating System and Version

Debian 13 (trixie), GNOME 48.7, Wayland

Kernel Release

6.18.12+deb13-amd64

Hardware: GPU

NVIDIA RTX PRO 1000 Blackwell Generation Laptop GPU (GB207GLM) + Intel Arc Pro 140T (iGPU, hybrid graphics)

Describe the bug

External monitors connected via DP-MST through a Dell WD19DCS dock randomly go black and fail to recover. The monitor stays black indefinitely until a VT switch (sudo chvt 3 && sleep 2 && sudo chvt 2) forces a full DRM modeset.

Setup:

• Dell Pro Max 16 Premium (MA16250), Intel/NVIDIA hybrid graphics
• Dell Performance Dock WD19DCS (USB-C, DP-MST hub)
• Two external 1920x1080 monitors: Dell U2414H (DP-7) and Philips 234E5 (DP-8)
• Internal eDP-1 (1920x1200) on Intel iGPU
• BIOS: Direct Output Mode ON, Hybrid Graphics ON

What happens:
The external monitors experience brief random blackouts (1-5 seconds) every 30-60 minutes, which is likely a DP-MST hub signal renegotiation in the dock. Most of the time the monitors self-recover. However, occasionally one monitor fails to recover and stays permanently black.

DRM state when monitor is black:
When the monitor is stuck black, Mutter/GNOME still shows it as connected and configured, but the kernel DRM sysfs reveals a state mismatch:

# Black monitor (DP-7):
/sys/class/drm/card1/card1-DP-7/status:  connected
/sys/class/drm/card1/card1-DP-7/enabled: disabled
/sys/class/drm/card1/card1-DP-7/dpms:    Off

# Working monitor (DP-8) for comparison:
/sys/class/drm/card1/card1-DP-8/status:  connected
/sys/class/drm/card1/card1-DP-8/enabled: enabled
/sys/class/drm/card1/card1-DP-8/dpms:    On

The connector is connected but enabled: disabled and dpms: Off. Both sysfs files are read-only (0444), so only the DRM master (Mutter) can change them via modeset. Mutter's D-Bus API (GetCurrentState) reports the monitor as active, indicating the compositor is unaware that the kernel DRM state has diverged.

Attempted recovery methods:

• Mutter ApplyMonitorsConfig D-Bus call: briefly turns the monitor on during modeset (proving the hardware path works), but Mutter then reverts to the previous (broken) state
• DDC/CI via ddcutil: monitor's I2C is unresponsive (DPMS off)
• Writing to sysfs dpms/enabled: files are read-only
• VT switch works: sudo chvt 3 && sleep 2 && sudo chvt 2 forces a full DRM modeset and reliably restores the monitor
• Suspend/resume also works: the monitor reliably comes back after a suspend cycle
• Dock reconnect also works: unplugging and re-plugging the dock restores the monitor

Hypothesis:
The brief DP-MST signal drop triggers a hotplug event. During recovery, the NVIDIA driver fails to properly re-enable the connector (possibly not setting the connector->encoder field, similar to #889). Mutter processes the reconnect at its level but the underlying DRM state remains disabled, creating a persistent mismatch.

To Reproduce

1. Connect two external monitors via Dell WD19DCS dock (USB-C, DP-MST)
2. Use GNOME Wayland with hybrid Intel/NVIDIA graphics
3. Wait for a random DP-MST signal glitch (typically 30-60 minutes)
4. Most times the monitor self-recovers; occasionally it stays black
5. When stuck: check sysfs to confirm enabled: disabled while Mutter reports active

Bug Incidence

Sporadic (happens every few hours to once a day)

Relevant information

Driver config (/etc/modprobe.d/nvidia.conf):

blacklist nouveau
options nvidia NVreg_TemporaryFilePath=/var/tmp
options nvidia NVreg_EnableS0ixPowerManagement=1
options nvidia NVreg_PreserveVideoMemoryAllocations=1

options nvidia-drm modeset=1

Related issues:

• /sys/class/drm/*/enabled reports “disabled” for enabled monitors #889 — sysfs enabled reports disabled for enabled monitors due to missing connector->encoder field (fixed in 580.82.09, possible regression or different code path in DP-MST recovery)
• Driver 575, 580, 590: second external display missing and NvKmsKapiDisplay errors #879 — DP-MST via USB-C docks failing with NvKmsKapiDisplay errors (575+ driver series)
• [GB203][Xorg/Cinnamon][DP] Xid 62/109/119/120 leads to unrecoverable display loss after idle/DPMS (RTX 5080, 590.48.01) #1028 — display loss after DPMS on RTX 5080 with driver 590.48.01

nvidia-bug-report.log.gz

Captured while monitor was working (not in the black state). Will attach a new capture during the next occurrence if needed.

[mnencia]

nvidia-bug-report.log.gz attached (captured while monitor was working, not in the black state).

[Binary-Eater]

Hi, we have an internal change that will likely fix this issue. We could not put it into a driver release because we were worried about regression risks. The internal bug tied to the fix is 5947370.