RTX5090 [REGRESSION 610.88 → 616.x] HDMI: permanent black screen at 7680x2160 @ 240Hz (high-ratio DSC) — RTX 5090 + Samsung Odyssey Neo G9 57" (G95NC). Same mode works over DisplayPort.
Summary
Every driver after 610.88 fails to bring up my display in the highest-bandwidth HDMI mode it supports: 7680x2160 @ 240 Hz. The panel stays permanently black and does not recover from a reboot, a monitor power cycle or re-plugging the cable. Rolling back to 610.88 restores it immediately, every time. This is 100% reproducible and toggles purely with the driver version.
Three findings narrow this down considerably:
- 7680x2160 @ 120 Hz over the same HDMI cable and port is rock solid — and that mode already runs over DSC. So DSC, FRL link training and EDID handling are not broken in general.
- The identical 7680x2160 @ 240 Hz mode works over DisplayPort 2.1 on the same driver (616.92) and the same GPU. DisplayPort on this monitor is UHBR13.5, which affords a less aggressive DSC target than the HDMI link does.
- Output colour depth (8 / 10 / 12-bit) and dynamic range (limited / full) make no difference at all to the HDMI failure.
Everything points at DSC parameter selection — target bits-per-pixel and/or slice configuration — on the HDMI path when the required compression ratio approaches 3:1.
System configuration
| GPU | NVIDIA GeForce RTX 5090 (desktop) |
| OS | Windows 11 Enterprise 25H2, build 26200.9445 |
| Monitor | Samsung Odyssey Neo G9 57" — G95NC (LS57CG95NUXEN) |
| Monitor firmware | M-C9557GGPA-1008.2 (latest available) |
| Mode under test | 7680x2160 native, HDR on, Adaptive Sync on |
| HDMI connection | GPU’s single HDMI port → monitor input HDMI3 (the 48 Gbit/s port; the other two are 32 Gbit/s) |
| HDMI cable | Oehlbach Gaming New Game Green, 5 m, HDMI 2.1b, Ultra High Speed certified, 48 Gbit/s, DSC support |
| DisplayPort connection | GPU DisplayPort → monitor DisplayPort 2.1 (UHBR13.5, 54 Gbit/s) |
| DisplayPort cable | KabelDirekt 16K Gaming DisplayPort 2.1, 5 m, DP80 / UHBR20, 80 Gbit/s |
Last known good driver: 610.88 Affected drivers (all reproduce): 616.56, 616.64, 616.86 (hotfix), 616.92
Note on the monitor: the G95NC has two hardware operating modes selected in its OSD, “120 Hz” and “240 Hz”, which cap what Windows offers. In 120 Hz mode Windows offers 60 and 120 Hz; in 240 Hz mode Windows offers 60 and 240 Hz.
Reproduction steps
- Connect the G95NC to the RTX 5090’s HDMI port, monitor input HDMI3.
- Set the monitor’s OSD operating mode to 240 Hz.
- Clean-install driver 616.92 (DDU in safe mode).
- In Windows, set the display to 7680x2160 @ 60 Hz → works.
- Change the refresh rate to 240 Hz → immediate, permanent black screen.
Only rolling back to 610.88 restores the mode.
Test matrix (driver 616.92, clean DDU install)
| Interface | Monitor OSD mode | Refresh rate | Required DSC ratio | Approx. DSC target | Result |
|---|---|---|---|---|---|
| HDMI3 | 120 Hz | 60 Hz | none | — | OK |
| HDMI3 | 120 Hz | 120 Hz | ~1.4 : 1 | ~21 bpp | OK |
| HDMI3 | 240 Hz | 60 Hz | none | — | OK |
| HDMI3 | 240 Hz | 240 Hz | ~2.9 : 1 | ~10 bpp | BLACK SCREEN |
| DisplayPort 2.1 | 240 Hz | 240 Hz | ~2.3 : 1 | ~13 bpp | OK |
The failure tracks the required compression ratio, not the resolution, the refresh rate or the pixel format on their own.
Variables ruled out
Varied across the failing HDMI mode, with no effect whatsoever — the black screen is identical in every combination:
- Output colour depth: 8-bit, 10-bit, 12-bit
- Output dynamic range: limited and full
Also excluded:
- Cable and port. The same 48 Gbit/s cable on the same HDMI3 input carries the 120 Hz mode — which already requires DSC — without a single glitch, and carried 240 Hz without issue for roughly two years on older drivers.
- DSC in general. The working 120 Hz mode runs over DSC.
- EDID, FRL link training, HDR, Adaptive Sync. All lower modes negotiate correctly on the same link with the same settings.
- The monitor and its firmware. Latest firmware, and the same 240 Hz mode works over DisplayPort on the same driver.
- Windows. The behaviour toggles purely with the driver version on an unchanged, fully patched OS.
Bandwidth analysis
Monitor input HDMI3 is the 48 Gbit/s port; HDMI 2.1 FRL6 leaves roughly 42.7 Gbit/s of usable payload after 16b/18b encoding. The monitor’s DisplayPort 2.1 input runs UHBR13.5 — 54 Gbit/s raw, roughly 52.4 Gbit/s payload after 128b/132b encoding.
At 7680x2160 the pixel rate is about 2.04 Gpx/s at 120 Hz and about 4.08 Gpx/s at 240 Hz, so at 10 bpc:
| Mode | Uncompressed | Link payload | Required ratio | Required DSC target | Result |
|---|---|---|---|---|---|
| HDMI, 120 Hz | ~61 Gbit/s | 42.7 Gbit/s | ~1.4 : 1 | ~21 bpp | OK |
| HDMI, 240 Hz | ~122 Gbit/s | 42.7 Gbit/s | ~2.9 : 1 | ~10.4 bpp | fails |
| DisplayPort, 240 Hz | ~122 Gbit/s | 52.4 Gbit/s | ~2.3 : 1 | ~12.8 bpp | OK |
~10.4 bpp for RGB 4:4:4 is comfortably within what DSC 1.2a permits — the floor is 8 bpp — so this is a legal, in-spec mode, and one the driver drove correctly up to and including 610.88.
Additional observation that may or may not be related: over DisplayPort the NVIDIA Control Panel offers a maximum of 10-bit output, whereas over HDMI 12-bit is offered.
Suspected cause
A change between 610.88 and 616.56 in how the driver selects DSC parameters — target bits-per-pixel and/or slice configuration — for the HDMI path when the required compression ratio approaches 3:1. Every other element of the display pipeline demonstrably still works on the same link, the same cable and the same monitor.
Two readings fit the data, and I cannot distinguish them from the outside:
- the defect is specific to the HDMI/FRL DSC path, or
- the defect affects DSC target rates at or below roughly 11 bpp on any interface, and DisplayPort simply never has to go that low on this monitor.
The fact that source colour depth has no influence supports either reading: the DSC target rate is derived from available link bandwidth, not from source bit depth. Had the fault been in HDR, deep colour or range handling, varying those parameters would have changed the outcome.
One further data point: with a second display attached to another output, the failed primary is still listed in Windows display settings but is greyed out and cannot be activated — i.e. the mode set on that output fails, rather than the display not being detected.
Impact
This is the monitor’s flagship mode. On every driver after 610.88 the HDMI path is capped at 120 Hz, half the panel’s capability.
The severity is amplified by the recovery path: with only this monitor connected over HDMI, the machine becomes unusable and unrecoverable without safe mode or a second display, because installing the driver itself produces the black screen.
Questions / requests
- Can this be reproduced in-house on an RTX 50-series card with a G95NC, or with any display requiring a DSC ratio near 3:1 over HDMI?
- Is there a registry key, EDID override or other supported mechanism to pin or override the DSC target bpp, as an interim workaround?
- Which nvlog or driver dumps would be most useful? I can capture them from a secondary display while the primary output is in the failed state and provide them on request.
Related report
An existing report on the developer forums describes the same failure signature on different hardware — DSC handshake resulting in a persistent black screen / signal loss on recent drivers, resolved only by rolling back:
This may be the same underlying defect surfacing at a different bandwidth point.
Greetings,
Christian