Please open a ticket here: https://gitlab.freedesktop.org/drm/amd/-/work_items and if possible, can you bisect?
Thanks! On Mon, Oct 12, 2026 at 3:51 AM Tobias Johansson <[email protected]> wrote: > > 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`.
