[briantoll]

Studio Display XDR: 5K60 over a Thunderbolt DP tunnel on M1 Max (j314c)

A tiled 5K display (two 2560x2880@60 tiles on two DP tunnels) only ran its single-stream modes (3840x2160@120 with DSC) on an Apple silicon host. The connection manager offered the first tunnel HBR3 x4 and the second was left with HBR x4, too little for a tile.

Root cause and fix are in the commit message. In short: the Apple host DP IN adapters never report the trained rate in DP_COMMON_CAP, so tb_dp_consumed_bandwidth() keeps charging a tunnel the full rate it was offered. The second tile's DP OUT adapter raises HPD only after the first tile's link has trained, and until then it is indistinguishable from the router's third, sink-less DP OUT adapter. So the first DP tunnel to a router with more than one DP OUT adapter is offered half of the available bandwidth, and later tunnels share what is left among the adapters that have HPD. Both tiles end up at HBR2 x4 on a 40 Gb/s link.

Trade-off: a single monitor on a dock with two DP OUT adapters is offered HBR2 x4 instead of HBR3 x4 (still enough for 4K60 at 10 bpc). thunderbolt.apple_dpin_share_bandwidth=0 restores the old behaviour. The M2 Pro/Max DP IN profile (no TB_HOST_DP_NOTIFY) is not covered by tb_port_is_apple_host_dpin() and is unchanged.

Tested

MacBook Pro 14" M1 Max (j314c), Omarchy, Hyprland, Apple Thunderbolt 5 cable (USB4 2x20 Gb/s), on top of aurora-2026.10.17.20:

• Plug at 3840x2160@120: 0:5 <-> 1:11 (DP): sharing the path with 2 DP OUT adapters, offering 17325 Mb/s, second tunnel gets the remaining 17370 Mb/s, both DPTX ports SET_LINK_RATE 0x14 with 4 lanes.
• 5120x2880@60 at scale 2 works at plug time and through a compositor mode change in both directions, including after the firmware has idled the second tile's link (it sends SET_LINK_RATE 0 for it 30 s into any single-stream mode).
• All three Thunderbolt ports (host controllers b01f00000.nhi, 701f00000.nhi, f01f00000.nhi) bring the display up the same way; about a dozen plug/unplug cycles across two days and several reboots, always 5K60 within two seconds of the Thunderbolt device appearing.
• Without the change: first tile HBR3 x4, second HBR x4, set_digital_out_mode fails with 80000104.

Observation for a follow-up

When a modeset fails on a tunnel output, the firmware reports an unplug although the cable and HPD are still there, and the new Type-C relink (dcp_typec_relink_eligible()) excludes USB4 outputs, so the display stays off until the cable is replugged. Extending the relink to tunnel outputs would cover that.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QhYiD43tUYf8SqrkTnG5LQ

[briantoll]

Rebased onto integration/aurora 8eddf5a (branch dpin-share-bandwidth-rebased); the commit applies cleanly and drivers/thunderbolt/tunnel.o builds with the Omarchy config. The change has been in daily use on the j314c since release 12 of my local kernel, now through release 16: the Studio Display XDR comes up as two uncompressed 5120x2880@60 tiles at plug time, across compositor mode changes in either direction, and after the firmware idles the second tile's link, with sharing the path with 2 DP OUT adapters, offering 17325 Mb/s in the log each time. #373 (kloploid, both displays of a dual-stream Thunderbolt dock on j314/j316, dptxep.c and the t600x DT) and #406 (BTNG-studio, T6034 Thunderbolt externals with a Studio Display at 5K) touch the same DP IN path from the other side; I have the hardware to test either against this change if that helps land them together.

[JarenKempton]

Tested on MacBook Pro 14" M1 Pro (j314s, t6000), 7.2.11-14-1-ARCH (aurora14, 4fdd0fc), together with #373 for dual-stream. Dock: CalDigit TS4, with a Samsung C49RG9x (5120x1440@120) and a Dell S2719DGF (2560x1440@155) both on the dock. I applied 736d7350a4fa cleanly on 4fdd0fc and installed a rebuilt thunderbolt.ko.

This PR is what made dual-stream work for me. With #373 alone, the second tunnel (the Dell) trained at HBR while the first trained at HBR2:

289c00000.dcp: DPTXPort: SET_LINK_RATE 0x14
28cc00000.dcp: DPTXPort: SET_LINK_RATE 0xa
28cc00000.dcp: ... FIFO error interrupt COMMON_INT_STA_3=0x00000020   (x14)

The Dell only offered modes up to 2560x1440@60, and t600x's shared tunnel clock then killed its stream. With this PR added, both tunnels get the same share and train at the same rate:

0:5 <-> 1:13 (DP): bandwidth reduced to 5400 Mb/s x4 = 17280 Mb/s
0:6 <-> 1:14 (DP): bandwidth reduced to 5400 Mb/s x4 = 17280 Mb/s
289c00000.dcp: DPTXPort: SET_LINK_RATE 0x14
28cc00000.dcp: DPTXPort: SET_LINK_RATE 0x14

Result: Dell at 2560x1440@154.85 and ultrawide at 5120x1440@119.97 at the same time, with no FIFO errors after link-up.

So on t600x this looks like a dependency for #373 whenever the two sinks don't both need HBR2 on their own. It isn't only a 5K-tile fix. apple_dpin_share_bandwidth was left at the default (Y).