Allow DisplayPort detach bookkeeping when the sink is unplugged

[martinstark]

Power-cycling a Dell U2725QE on 615.71.09 can leave DPLib tracking detached heads, breaking subsequent setup using DSC (4k120hz) . This patch restores detach cleanup and same-connector recovery in the tested setup.

Cause and fix

All four previousPlugged modeset guards were introduced in 615.71.09 (dpPreModeset() guard); 610.57.04 has none. dpPreModeset() rejects unplugged detach, leaving dpPostModeset() nothing to complete. NVKMS detaches hardware, clears its head bit and removes group devices; DPLib retains its per-head pointer and an empty, attached activeGroups entry.

With stale groups present, ConnectorImpl2x::enableFlush() proceeds past its early-return checks and attempts flush phase 1. Phase 1 returns 0x40 (NV_ERR_INVALID_STATE), aborting trainLinkOptimized() before hardware training or sink DSC enable. The firmware-side rejection reason is unavailable.

Every selected head is checked before mutation: allow HPD-low detach-only requests; reject any request containing an attachment target. Connector/discovery guards, forced-connected/DDS exceptions and DSC/flush/training policy remain unchanged. Existing detach callbacks and unplug discovery completion already permit cleanup around the hardware update.

Reproduction

RTX 5090, direct DisplayPort, Arch Linux, Sway/Wayland, kernel 7.2.4-arch1-2, NVIDIA modules/userspace 615.71.09. Both modes use 3840×2160/four lanes: 60 Hz at 5.4 Gbit/s without DSC/FEC; 120 Hz at 8.1 Gbit/s with DSC/FEC.

1. Fresh boot at 60 Hz; power off for ~10 seconds, then on. The picture can return with stale state.
2. Select 120 Hz: no signal. Another power cycle fails; moving the cable to another GPU connector recovers it.

Power-cycling from working 120 Hz also fails on stock 615.71.09. Expected: same-connector recovery.

Evidence and limits

Pinned evidence: sanitized timestamped logs, diagnostic patches, control-flow harness and build/reproduction instructions. Instrumentation is excluded from this PR.

Capture	Result
Before: display 0x800, SOR 1	Stale head 2 remains attached; head 3 requests DSC. Flush phase 1 returns 0x40; attach-training result is false.
Fixed: display 0x200, SOR 0	HPD-low detach (headMask=0x8) completes; group/transition lists are empty at rediscovery. Head 3 reattaches at 120 Hz; first training attempt, FEC and sink DSC enable succeed.

Captures use separate boots/connector assignments. The fixed capture covers one instrumented 120 Hz cycle on the same connector: no phase-1 failure or 0x40, but AUX errors persist during power-off/rediscovery. The nv-modeset-kernel.o build and control-flow checks passed. Not tested on hardware: diagnostic-free build, MST, UHBR, eDP/DDS, multi-head/head reassignment, other GPUs and repeated-cycle reliability.

Potentially related: NVIDIA bug 6760883, RTX 5090/Samsung G95NC wake regression (tracking acknowledgement).

AI tools assisted with investigation, patch development and this write-up. I performed the hardware tests.

[CLAassistant]

All committers have signed the CLA.

[attackgoat]

This patch fixes the issue for this Samsung too; where the 120 Hz mode doesn't require DSC and so does not exhibit the issue while 240 Hz does:

• GPU: NVIDIA GeForce RTX 3090 (GA102)
• Monitor: Samsung Odyssey G93SC
• Connection: DisplayPort
• Mode: 5120x1440 at 240 Hz, requiring DSC

[klg90]

Fixes the issue on my machine

ested PR #1359 successfully on Fedora 44.

Setup:

GPU: RTX 5090
Desktop: GNOME / Wayland
Monitor: ASUS TUF Gaming VG27AQM1A
DisplayPort
2560×1440 @ 240 Hz

Behavior:

Stock 610.57.04: works normally
Stock 615.71.09: physically turning the monitor off and back on causes loss of DisplayPort signal; unplug/replug is required
615.71.09 + PR #1359: monitor power-off/on recovery works normally

I rebuilt the RPM Fusion akmod with PR #1359 applied and verified the patched 615.71.09 kernel module was actually loaded.

I’m continuing to test repeated power cycles, GNOME DPMS, suspend/resume, reboot, and 240 Hz behavior. So far this patch fixes the regression on my setup as well.

[jdvmi00]

Tested a2e8b26 on DGX Spark (GB10/aarch64), Omarchy/Arch Linux ARM, kernel 7.2.6-1.5-aarch64-ARCH, Hyprland 0.56.2/Aquamarine 0.15.1, with direct USB-C–DisplayPort to a Dell U5226KW.

Stock 615.71.09 detected the monitor but produced no signal. Replugging, changing ports and 1080p/60 did not recover it; reboot did. The 1080p capture had DSC/FEC off and logged Enabling flush mode failed! and Set flush mode phase 1 failed.

With this PR's two commits and no diagnostic source patches, native build, DKMS installation and reboot passed. Loaded module build IDs were verified. Graphical unlock, reconnect in both USB-C orientations, HDMI→DP input switching with KVM USB, and 10-second DPMS off/on all worked without another reboot. I separately confirmed full 6144×2560/120 Hz output.

The original flush failures did not recur. AUX/disconnect and DRM topology warnings remain. Reconnect/input-switch captures were at 3072×2560/~60 Hz; DPMS was at 3840×2160/~60 Hz. Full-resolution reconnect endurance and system suspend/resume remain untested; the original failure trigger was not isolated. Thanks for the fix.

[Loong0x00]

Another reproduction of the DP monitor power-cycle issue (I have not tested this patch):

• Arch Linux, kernel 7.2.6-arch2-1; RTX 5090, NVIDIA open driver; GNOME/Wayland; LG UltraFine 6144x3456 @ 60 Hz via DisplayPort.
• NVIDIA 615.71.09: turning the monitor off and back on leaves it black, although the system detects the DP display. Switching the output to 3840x2160 @ 60 Hz restores the image.
• Downgraded the NVIDIA packages to 610.57.04 without changing the kernel, rebooted, and tested the same monitor power cycle at 6144x3456 @ 60 Hz: it works normally.