Since kernel 7.2 (verified on 7.2.4 and 7.2.8, Fedora builds), the display goes black (monitor reports no signal / enters standby) as soon as the compositor sets 3840x2160@60 on the HDMI output. 7.1.8 works with the same monitor, cable, firmware and userspace. The monitor's EDID declares a max TMDS clock of **300 MHz**, has **no HDMI Forum VSDB** (no HDMI 2.0 / SCDC / scrambling), and lists 3840x2160@60 (VIC 97) **only in the YCbCr 4:2:0 Video Data Block**. On 7.2.8 amdgpu nevertheless commits that mode as **RGB 8 bpc with a 594 MHz pixel clock** — about twice what the sink supports — and reports success. The mode should either be driven as YCbCr 4:2:0 (297 MHz TMDS) or rejected.
The system itself keeps running normally; only the display output is lost.
3840x2160@30 (297 MHz, RGB) works fine on 7.2.8.
## Hardware
- System: Minisforum Venus series (board F7BSC), BIOS 1.09 (2023-11-20)
- APU: AMD Ryzen 9 7940HS w/ Radeon 780M — Phoenix1 `[1002:15bf]` rev c1,
subsystem `1f4c:b002`
- Display IP: DCN 3.1.4, ATOM BIOS 113-PHXGENERIC-001
- Output: native HDMI (`HDMI-A-2`, DC signal type 4 = HDMI Type A), no adapter
- Monitor: Samsung (EDID manufacturer `SAM`, product `0x0fee`), 4K, single
display
## Software
| | Good | Bad |
|---|---|---|
| Kernel | 7.1.8-200.fc44 (Display Core v3.2.378) | 7.2.4-200.fc44,
7.2.8-200.fc44 (Display Core v3.2.384) |
| DMUB firmware | 0x08005E00 | 0x08005E00 (7.2.4) and 0x08006200 (7.2.8) — both
bad |
- Distribution: Fedora 44 Workstation, GNOME / mutter 50.5 (Wayland)
- Mesa 26.2.3, linux-firmware / amd-gpu-firmware 20260916
- The firmware is ruled out: 7.2.4 fails with the old DMUB firmware
(0x08005E00), and 7.1.8 works with the current linux-firmware package installed.
- Also ruled out: `amdgpu.sg_display=0` makes no difference.
- Not bisected yet. The first bad version lies somewhere between 7.1.8 and
7.2.4.
## Steps to reproduce
1. Connect the Samsung monitor described above via HDMI.
2. Boot 7.2.x. The plymouth LUKS prompt is visible, because the initial fbdev
mode is 3840x2160@30 at 297 MHz.
3. GNOME starts and applies 3840x2160@60 from `monitors.xml` → the screen goes
black and the monitor shows no signal.
Changing the GNOME configuration to 3840x2160@30 makes 7.2.8 boot to a working
desktop.
## Expected / actual
- **Expected:** 3840x2160@60 is output as YCbCr 4:2:0 (297 MHz TMDS) like on
7.1.8, or is pruned as unsupported.
- **Actual:** the mode is validated and committed as RGB 8 bpc at 594 MHz on a
sink whose EDID declares a max TMDS clock of 300 MHz → no picture.
## Analysis (drm.debug=0x06 on 7.2.8)
EDID parsing — note the max TMDS clock:
```
[drm:drm_parse_cea_ext] [CONNECTOR:402:HDMI-A-2] HDMI: DVI dual 0, max TMDS
clock 300000 kHz
[drm:dm_helpers_parse_edid_caps [amdgpu]] dm_helpers_parse_edid_caps: HDMI_FRL
[HDMI-A-2] max_frl_rate 0
```
Mode validation. Higher bpc values are pruned, but 8 bpc RGB at 594 MHz passes,
although it exceeds 300 MHz:
```
[drm:create_validate_stream_for_sink [amdgpu]] Pruned mode 3840 x 2160 (clk
594000) RGB 10-bpc -- Encoder validation failure
[drm:create_validate_stream_for_sink [amdgpu]] Trying with 8 bpc
```
Commit when the compositor starts (screen goes black right after this):
```
[ 41.109637] [drm:dc_stream_log [amdgpu]] core_stream ...: src: 0, 0, 3840,
2160; dst: 0, 0, 3840, 2160, colorSpace:1
[ 41.110034] [drm:dc_stream_log [amdgpu]] pix_clk_khz: 594000,
h_total: 4400, v_total: 2250, pixel_encoding:RGB, color_depth:8-bpc
[ 41.110513] [drm:dc_stream_log [amdgpu]] signal: 4 dispname: SAMSUNG
manufacturer_id: 0x2d4c product_id: 0xfee
[ 41.201208] [drm:dc_commit_state_no_check [amdgpu]] {3840x2160,
4400x2250@594000Khz}
[ 41.202066] [drm:dc_commit_streams [amdgpu]] dc_commit_streams Finished.
```
For comparison, the early-boot fbdev mode, which displays correctly:
```
[ 4.946654] [drm:dc_stream_log [amdgpu]] pix_clk_khz: 297000,
h_total: 4400, v_total: 2250, pixel_encoding:RGB, color_depth:8-bpc
```
No errors, warnings, GPU hangs or resets are logged in the failing case. The
only other display-related message (`REG_WAIT timeout ... optc314_disable_crtc
line:146`) also appears on 7.1.8 and is unrelated.
### EDID (CTA-861 extension, decoded)
- Video Data Block VICs: 95 (2160p30), 16, 31, 4, 19, 5, 20, 32, 33, 34, 93,
94, 98, 100, 7, 22, 3, 18. VIC 97 (2160p60) is not listed here.
- HDMI 1.4 VSDB (OUI 00-0C-03): max TMDS clock 300 MHz.
- **No** HDMI Forum VSDB (OUI C4-5D-D8), so no SCDC and no scrambling.
- YCbCr 4:2:0 Video Data Block: VICs 96, 97, 101, 102, which are 4:2:0-only.
Raw EDID (256 bytes) is attached as `edid-samsung-hdmi.bin`.
On 7.1.8 the same 3840x2160@60 mode works on this monitor. That is consistent
with it being output as YCbCr 4:2:0 at 297 MHz, which is the only way the sink
can accept it, but I have not yet captured a drm.debug log on 7.1.8 to confirm
the encoding there. I can provide one, and I can test patches or bisect if
needed.
## Attachments
- `dmesg-7.2.8-drm.debug-0x06-black-screen.txt`: failing boot, 4K@60 requested
by GNOME
- `dmesg-7.2.8-drm.debug-0x06-4k30-working.txt`: same kernel with GNOME set to
4K@30, working
- `dmesg-7.1.8-working.txt`: last good kernel, no drm.debug
- `edid-samsung-hdmi.bin`: raw EDID of the monitor
MAC addresses in the logs have been replaced with `xx:xx:xx:xx:xx:xx`.
dmesg-7.2.8-drm.debug-0x06-4k30-working.txt.xz
Description: application/xz
dmesg-7.1.8-working.txt.xz
Description: application/xz
dmesg-7.2.8-drm.debug-0x06-black-screen.txt.xz
Description: application/xz
edid-samsung-hdmi.bin
Description: Binary data
