Connected, enabled, and still blank
The display is a Samsung Odyssey G93SC on an RTX 5090, over DisplayPort SST at 5120 × 1440 and 240 Hz with single DSC. After a normal display-off and wake, the Samsung sometimes stayed blank. Its connector reported connected and enabled.
Setup: Ubuntu, GNOME Wayland, NVIDIA 610.57.04, kernel 7.0.0-31-generic, four displays. My Blackwell overlay change from the earlier work stayed in place, unchanged, throughout. Hardware investigation.
The state mismatch
DSC is display-stream compression. The GPU compresses the stream and the display decompresses it. Both sides have to agree that it is on. Here a successful DPCD read showed 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 dropped its DSC tracking entry, to avoid a dangling pointer. The original insertion path then put the device back in the group and never reapplied DSC.
The patch calls setDeviceDscState() when a capable DisplayPort sink returns to an attached SST group with single or dual DSC. That turns sink decompression back on and restores the driver’s tracking entry. It leaves inactive groups, MST links, and other connector types alone. Submitted change.
Controlled wakes
The diagnostic build still carried earlier experimental code. I disabled its generic DRM recovery worker for the controlled wakes. Otherwise a successful wake could have come from a recovery modeset instead of the DSC restore, and the test would not have isolated the DSC restore.
Three consecutive diagnostic wakes brought all four displays back. Two went through SST reinsertion. The third used the normal wake path. In both reinsertion captures, DSC enable succeeded after the initial modeset. No recovery modeset was queued or reapplied.
I then built a cleaned version with the probes, tracing, retry, and recovery worker removed. One more wake, without instrumentation, brought all four displays back. Diagnostic and final-build results.
What the evidence leaves open
- The logs show the enable write succeeded and the display returned. They do not include a separate readback of the DSC bit after the write.
- I do not know why the bit cleared. I have not tied it to a specific power transition.
- I did not measure sink forward error correction (FEC) state. The patch leaves FEC handling as it was.
- Normal logging in the cleaned build did not record which reinsertion branch ran.
Within those limits, restoring DSC alone fixed the reinsertion failure on this machine.
Regression tests
The harness extracts the production insertion, removal, and DSC setter functions. Six scenarios cover lost state, tracking restoration, supported and excluded paths, conflicting ownership, and failure followed by retry. Remove the restoration block and the lost-state scenario fails.
The device doubles cover control flow and tracking lifetime. Physical decoding, AUX transactions, FEC, HDCP, stream allocation, and kernel locking are outside the harness. Harness and test scope.
Submitted as NVIDIA PR #1349 to NVIDIA’s open GPU kernel modules, open as of September 20, 2026.