[Regression] amdgpu prunes second 4K display to 1920×1080 when two displays share a Thunderbolt dock — MacBookPro16,1 (Navi 14), 7.1.8-1-t2-resolute

[theresamclaird]

[Regression] amdgpu prunes second 4K display to 1920×1080 when two displays share a Thunderbolt dock — MacBookPro16,1 (Navi 14), 7.1.8-1-t2-resolute

Summary

On a 16" 2019 Intel MacBook Pro (MacBookPro16,1, AMD Navi 14 discrete GPU), driving two identical 4K monitors through a single Thunderbolt 4 dock worked correctly on kernel 6.18.44-1-t2-resolute (both at 3840×2160 / usable at 2560×1440). After updating to 7.1.8-1-t2-resolute, the second DisplayPort stream on that dock is pruned down to a maximum of 1920×1080 — 2560×1440 and 3840×2160 are no longer offered on that output at all. The first stream on the same dock is unaffected and still gets full 4K.

The monitors and their EDIDs are fine (both advertise 4K, EDIDs are byte-identical apart from the serial number). The fault follows the dock port / stream position, not the monitor — swapping in a different monitor (a 2560×1440 Dell) as the second stream causes that display to be capped at 1080p instead. This has the signature of an amdgpu DP-MST/DSC mode-validation issue, a historically regression-prone area (e.g. upstream commit 4df96ba6676034 in v6.10-rc1, corrected by fa57924c76d995).

Environment

Machine	Apple MacBookPro16,1 (Mac-E1008331FDC96864)
Discrete GPU	AMD Navi 14 [Radeon Pro 5300M/5500M] [1002:7340], driver amdgpu
iGPU	Intel UHD Graphics 630 [8086:3e9b], driver i915 (not used for these outputs)
RAM	64 GB DDR4-2667
Distro	Ubuntu 26.04 LTS
Session	Wayland / GNOME
Bad kernel	7.1.8-1-t2-resolute (#1 SMP PREEMPT_DYNAMIC Mon Aug 10 02:42:52 UTC 2026)
Last-known-good kernel	6.18.44-1-t2-resolute
Dock	Kensington TB4 Docking Station (Thunderbolt bus reports generation=4 / USB4), on host TB domain 1
Affected monitors	2× Samsung U32J59x 4K (EDID model 3891, product name U32J59x), connected via DisplayPort through the dock

Steps to reproduce

1. Connect two 4K DisplayPort monitors through a single Thunderbolt dock (Kensington TB4) to the MacBook's Thunderbolt port.
2. Boot 7.1.8-1-t2-resolute.
3. Open display settings (or inspect /sys/class/drm/*/modes).

Expected behavior

Both DisplayPort streams offer their full EDID mode list (up to 3840×2160), as they did on 6.18.44-1-t2-resolute.

Actual behavior

One stream (card5-DP-2) offers full modes; the other (card5-DP-1) is capped at 1920×1080 with a generic fallback ladder. 2560×1440 and 3840×2160 are absent from the pruned output entirely.

Kernel-visible modes (/sys/class/drm/…/modes)

card5-DP-1 (pruned — bad):

1920x1080   (×8, various rates)
1680x1050
1600x900
1280x1024
1440x900
1280x800
1152x864
1280x720 …

Max = 1920×1080. No 2560×1440, no 3840×2160.

card5-DP-2 (correct — good):

3840x2160   (×6)
2560x1440
1920x1080 …

Max = 3840×2160.

Evidence the EDID / monitor is NOT the problem

Both monitors' EDIDs are valid 256-byte (base + CTA extension) blocks and decode cleanly as Samsung U32J59x, EDID 1.3. A byte comparison of the two EDIDs shows they differ in only 13 bytes, all of which are the serial number (offsets 0x0C–0x11, the serial-string descriptor, and the resulting block checksum). The pruned display's EDID advertises the same 4K detailed timings as the working one (297 MHz pixel-clock detailed timing present).

$ cmp -l edid_DP1.bin edid_DP2.bin   # 1-indexed offsets
 13/14/15/17/18   -> serial number bytes
 115..123         -> serial-number ASCII in FF descriptor
 128              -> block-0 checksum
total differing bytes: 13

So both panels present identical capabilities; only the second stream through the dock is bandwidth-pruned.

Key: the fault follows the dock stream, not the monitor

• Two Samsung 4K on the Kensington → one is capped at 1080p.
• Replacing the second Samsung with a 2560×1440 Dell (as the second stream on the same dock) → the Dell is now capped at 1080p instead.
• Splitting the two 4K monitors across two different docks/ports (so no single dock carries two native streams) → both display at full resolution. This is the current workaround.

Relevant log line

The amdgpu DSC/MST path is active for these displays:

[drm] amdgpu 0000:03:00.0: [drm] DP-HDMI FRL PCON supported
[drm] pre_validate_dsc:1667 MST_DSC dsc precompute is not needed

(Full dmesg unavailable without root — kernel.dmesg_restrict=1. Happy to provide a complete drm.debug=0x1e boot log on request.)

Workaround

Distribute displays so that no single Thunderbolt dock drives two native high-bandwidth DP streams — e.g. one 4K per dock, or connect the second 4K directly to another Thunderbolt port via a USB-C→DisplayPort cable. Full native resolution is restored on all outputs this way.

Likely upstream cause / pointers

The symptom (second MST/dock stream pruned to a low fallback resolution, valid EDID, appears on a kernel bump) matches the amdgpu DP-MST + DSC mode-validation family of regressions:

• Introduced by 4df96ba6676034 ("drm/amd/display: Add timing pixel encoding for mst mode validation"), v6.10-rc1.
• Corrected by fa57924c76d995 ("drm/amd/display: Refactor function dm_dp_mst_is_port_support_mode()").
• LKML: "[REGRESSION] No image on 4k displayport displays connected through usb-c dock in kernel 6.10".

Please advise whether 7.1.8-1-t2-resolute carries the corrected mode-validation logic, or whether this is a fresh regression in the DSC bandwidth accounting for the second stream. I can test any candidate kernel and provide drm.debug logs.

[AdityaGarg8]

Please test with kernel 7.1.3 and 7.1.4 from the repo.