HDMI VRR series on DCN 3.2 + Samsung G95SD (5120x1440@240, FRL5+DSC): results across three builds

# HDMI VRR series on DCN 3.2 + Samsung Odyssey G95SD (5120x1440@240, FRL+DSC)


Reported by: Sam

## Why this might be useful

A 5120x1440 ultrawide at 240 Hz on DCN 3.2, driven over HDMI 2.1 FRL with DSC,
is a configuration I have not seen reported against this series. Everything
below is from the CachyOS `7.2/hdmi` rebase (27 commits, `dc59e4fea..8f75e000c`)
applied to stock Linux 7.2.0, with `amdgpu.dcfeaturemask=0x402`.

## Hardware / software

| | |
|---|---|
| GPU | RX 7900 XTX, Navi 31, **DCN 3.2**, `1002:744c` |
| Sink | Samsung **Odyssey G95SD**, 5120x1440, HDMI 2.1, FRL5 max, VRRmin 48 / VRRmax 240 |
| Link | active optical HDMI 2.1, direct, no PCON |
| Base | Linux 7.2.0 + CachyOS `7.2/hdmi` (all 27 apply cleanly to 7.2.0) |
| Committed stream | RGB 12-bpc, DSC 12.0 bpp, ODM 2:1, BT.2020 full range, HDR on, FRL rate 4 |

The sink is correctly classified by the series:

```
[CONNECTOR:415:HDMI-A-2] VRRmin: 48, VRRmax: 240, VRR supported: yes
[CONNECTOR:415:HDMI-A-2] FAPA in blanking: no, ALLM support: yes, Fast Vactive support: no
```

## 1. The good news: patches 01-12 fix VRR detection under FRL

Stock 7.2.0-rc5 with `dcfeaturemask=0x402` reports the connector as
**`Vrr: incapable`**. With the series applied but HDMI-VRR classification
disabled (see build C below), the same link on the same cable reports
**`Vrr: Always`** and FreeSync engages.

So the early parsing/refactor patches — "Always try to parse AMD vsdb", "Check
for VRR range in CEA AMD vsdb", "Use bigger VRR range if found in AMD vsdb",
"Separate DP/eDP and PCON paths completely" — repair legacy
FreeSync-over-HDMI detection on an FRL link, which stock 7.2 gets wrong. That
is a clear improvement and is independent of everything below.

## 2. The gradient: three builds, three failure modes

| build | HDMI-VRR (VTEM) path | result |
|---|---|---|
| **A** full series | active, plus `f402ff76a` forcing `freesync_on_desktop` | 5120x1440@240 **refused outright** — sink OSD "Mode Not Supported" |
| **B** minus `f402ff76a` | active | mode comes up, then link **dies permanently** ~0.4 s after `VRR off->on`; sink shows NO SIGNAL; only a monitor power-cycle recovers |
| **C** minus `f402ff76a`, HDMI-VRR classification disabled | not taken; legacy AMD-VSDB path used | link **stays up** at 240 Hz. `Vrr: Always` = steady faint VA-style brightness flicker on motion. `Vrr: Automatic` = ~1 s full black-drop-and-recover on each VRR engage/disengage |

Build C's edit is one token, neutralising `6a58fd84f` for this connector
without reverting it (a mechanical revert conflicts with 21/24/25/26):

```c
/* amdgpu_dm_update_freesync_caps(), HDMI branch */
-           if (hdmi_vrr.supported) {
+           if (0 && hdmi_vrr.supported) {
                  amdgpu_dm_connector->as_type = ADAPTIVE_SYNC_TYPE_HDMI;
```

**Reading:** the common factor is a **VRR state change on this sink over
FRL+DSC**, not VTEM specifically. VTEM signalling makes it fatal; the legacy
FreeSync path makes it a recoverable ~1 s glitch. Steady VRR is survivable;
transitions are not.

## 3. Build A's specific defect: VRR entered on an inactive stream

In build A the CRTC is switched into VRR while the freesync module still
reports VRR off:

```
amdgpu_dm_handle_vrr_transition: crtc=376 VRR off->on: Get vblank ref
update_freesync_state_on_stream: VRR packet update: crtc=376 enabled=0 state=2
```

`state=2` is `VRR_STATE_INACTIVE`, `enabled=0` is
`mod_freesync_get_freesync_enabled()`. The chain:

```c
/* f402ff76a "Force freesync_on_desktop for HDMI" */
if (dc_is_hdmi_signal(new_stream->signal))
        new_stream->freesync_on_desktop = true;      /* unconditional */

/* ddf48d91e "freesync_on_desktop support for HDMI VRR" (v4 22/27) */
if (stream->freesync_on_desktop)
        vrr_active |= vrr->state == VRR_STATE_INACTIVE;
```

`f402ff76a` sets the flag for every HDMI stream with no check on `as_type`, on
sink VRR support, or on whether signalling will be sent; `ddf48d91e` then
promotes `vrr_active` *because* the state is INACTIVE. Removing `f402ff76a`
(build B) makes the transition coherent — `enabled=1 state=3` — and the
incoherence is gone. It did not save the link, but it is a real defect on its
own and `f402ff76a` is not in the v4 posting.

## 4. Robustness issue, independent of root cause: no way out of VRR

**Scope: this is a build-A/B (HDMI-VRR path) observation only.** On build C's
legacy path the transition reverses normally — a 360 s capture shows a clean
`VRR off->on` at t=1163.5 and a matching `VRR on->off: Drop vblank ref` at
t=1508.5. So the stuck state is specific to the HDMI-VRR path, not to VRR in
general.

Across two build-B boots there is exactly **one** `VRR off->on` transition and
never a matching `on->off`, for the remaining ~230 s of uptime. Every later
modeset — including a full `link_set_dpms_off` / retrain cycle that trained
successfully at FRL rate 5, and a connector re-probe via
`echo detect > .../status` — ran with VRR still active. Neither recovered the
display.

On a sink that cannot cope with VRR under FRL+DSC, that turns a recoverable
glitch into "power-cycle the monitor". Some path back to non-VRR on repeated
commit failure, or on a connector re-probe, would help.

## 5. Observability gaps that made this hard to diagnose

Working this out took several instrumented boots, mostly because the
interesting code paths are silent:

- `build_vtem_infopacket()` — no `DC_LOG`/`drm_dbg` at all. "Zero VTEM lines"
  in a trace means nothing.
- `verify_link_capability_non_destructive()` — likewise silent, so the
  "FRL cap clobbered on non-destructive verify" hypothesis
  (`[PATCH 31/34] DC Patches Aug 10 2026`) can be neither confirmed nor
  excluded from logs.
- No FRL or DSC debugfs for HDMI connectors: `connector_debugfs_init()` gives
  `DRM_MODE_CONNECTOR_HDMIA` only `hdcp_sink_capability` and `hdmi_cec_state`;
  the `dsc_*` files are gated on DisplayPort/eDP. There is no way for a user to
  read back the negotiated FRL rate, whether DSC engaged, or at what bpp.

A `DC_LOG_INFOPACKET` in the VTEM builder and an HDMI equivalent of the DP
`dsc_*` debugfs files would each have saved a reboot cycle here.

## 6. Separately: DSC 10-bpc sink capability is discarded

Not part of this series — present in stock 7.2 — but found while chasing the
above, and it touches the same code. Two stacked `if/else if` chains collapse
the HF-VSDB DSC bit-depth mask to a single value, so a sink advertising both
10 and 12 bpc is presented to DC as 12-bpc-only, and a 16-bpc-capable sink ends
up 8-bpc-only. Details in a separate mail.

## 7. The build-C black-drop involves no link event

A 360 s `dmesg --follow` capture at `drm.debug=0x06` (DRIVER|KMS), covering a
witnessed ~1 s black-drop, contains **zero** matches for
`frl|link_set_dpms|link_detect|detect_link|verify_link|training|retrain|hpd|*ERROR*`.
Not one, in 11,361 lines over six minutes.

What it does contain, at the moment of the drop:

```
[1508.490017] amdgpu_dm_handle_vrr_transition: crtc=376 VRR on->off: Drop vblank ref
[1508.490142] update_freesync_state_on_stream: VRR packet update: crtc=376 enabled=0 state=2
```

followed by ~2.3 s of depressed atomic-commit rate and then a catch-up burst:

```
commits per 0.25 s:  t=1508.5 -> 24   1509.0 -> 17   1509.75 -> 17   1510.5 -> 29
                     t=1510.75 -> 330  1511.0 -> 249  1511.25 -> 361
```

So the drop coincides with **VRR disengage**, and the source does not
renegotiate the link across it — no retrain, no DPMS cycle, no re-detect, no
HPD, no error. On this evidence the blanking looks sink-side: the panel bailing
on a refresh-rate excursion rather than the source dropping the link. That also
fits the symptom gradient — steady VRR on `Vrr: Always` produces continuous
VA-style brightness flicker rather than blanking, i.e. the same panel behaviour
at lower amplitude.

The only other activity in the window is idle-power-state churn
(`dc_allow_idle_optimizations_internal`, 55 enter / 54 exit across the capture),
which tracks mouse activity throughout and is not clustered at the drop.
`HardMinUClk_Khz` and `HardMinDramclk_Khz` are 0 for the entire capture, so no
clock-floor reprogramming is involved.

Caveat: `0x06` covers DRIVER and KMS. DC's internal logger and DMUB firmware are
separate and could still hold something. But FRL training, link detect and DPMS
transitions all log under DRIVER — they appear in every other trace we took — so
their absence here is meaningful rather than a gap in coverage.

## Open / not established

- Whether the sink-side reading is right. It is inference from the absence of
  source-side link events plus the flicker/blank symptom gradient, not a
  positive measurement of what the panel did.
- Whether DC-internal or DMUB logging would show anything at the drop.
- Whether the "FRL failed to train, TMDS only until a monitor power-cycle" event
  seen once on stock rc5 shares a mechanism. That boot was untraced; there is no
  signature to compare.
- Whether `[PATCH 31/34] restore FRL cap on non-destructive HDMI link verify`
  (DC Patches Aug 10 2026) is relevant. It applies cleanly to 7.2 and fixes a
  real clobber, but `verify_link_capability_non_destructive()` is silent, so it
  can be neither confirmed nor excluded from logs. The successful FRL rate-5
  retrain during build B's dead-link period argues the cap was intact.