Connected, enabled, and still blank
The observed failure affected a Samsung Odyssey G93SC connected to an RTX 5090 over DisplayPort SST, running at 5120 × 1440 and 240 Hz with single DSC. After the usual display-off and wake sequence, the Samsung could remain blank while its connector was reported connected and enabled.
The documented setup was Ubuntu with GNOME Wayland, NVIDIA 610.57.04, kernel 7.0.0-31-generic, and four displays. An existing Blackwell overlay change remained constant during this investigation; it was not part of the DSC fix. Hardware investigation.
The state mismatch
DSC is display-stream compression. The transmitting side and the display’s decompression state need to agree. Here, a successful DPCD read reported the sink’s DSC enable bit off while the attached group still expected single DSC.
During re-detection, the returning device was removed from its active group. Group removal also removed its DSC tracking entry to avoid keeping a dangling pointer. The original insertion path put the device back in the group without reapplying DSC.
The focused patch calls setDeviceDscState() when a capable DisplayPort sink returns to an attached SST group using single or dual DSC. That restores sink decompression and the driver’s tracking entry. It does not broaden the change to inactive groups, MST links, or unrelated connector types. Submitted production change.
Testing the focused explanation
The diagnostic candidate still contained earlier experimental code, but its generic DRM recovery worker was disabled for the controlled wakes. That mattered: a successful wake with a generic recovery modeset would not isolate whether DSC restoration alone was sufficient.
Three consecutive user-confirmed diagnostic wakes returned all four displays. Two exercised SST reinsertion; the third used the normal wake path. In the two reinsertion captures, DSC enablement succeeded after the initial modeset, with no additional recovery modeset queued or reapplied.
A later cleaned build removed the diagnostic probes, tracing, retry, and generic recovery worker. One further user-confirmed wake returned all four displays. This was a separate final check, not another fully instrumented reproduction. Diagnostic and final-build results.
What the evidence leaves open
- The logs show a successful enable operation and physical recovery, but not a separate readback of the DSC bit after the write.
- Why the bit became clear remains unproven. A particular power transition has not been established as its cause.
- Sink forward error correction (FEC) state was not separately measured. The patch leaves the existing FEC handling unchanged.
- Normal logging in the final cleaned build did not establish which reinsertion branch ran.
These limits do not erase the result. They define what the captures actually support: a focused restoration was sufficient for the observed reinsertion failure on this setup.
Tests beside the hardware record
The regression harness extracts the production insertion, removal, and DSC setter functions. Its six scenarios cover lost state, tracking restoration, supported and excluded paths, conflicting ownership, and failure followed by retry. Removing the restoration block makes the lost-state scenario fail.
The device doubles test control flow and tracking lifetime. They do not simulate physical decoding, AUX transactions, FEC, HDCP, stream allocation, or kernel locking. Harness and test scope.
The upstream submission, NVIDIA PR #1349, remained open as of September 15, 2026.