Follow-up: M5 Max validation — both displays now driving 5K HiDPI symmetrically Closing the loop on this thread now that I've tested the M5 Max. Your prediction was correct. Test systems: Previous: MacBook Pro 16" (Mac17,8), M5 Pro 18-core, 64GB, macOS Tahoe 26.4.1 (25E253) New: MacBook Pro 16" (Mac17,6), M5 Max 18-core CPU (6 P + 12 E) / 40-core GPU, 64GB LPDDR5, 2TB, macOS 26.5 (25F71), Darwin 25.5.0 M5 Pro baseline (asymmetric two-pipe allocation, documented earlier in this thread): The connection-order-determined asymmetry was reproducible regardless of cable type. Whichever monitor connected first occupied dispext0 at the larger budget; the second occupied the smaller pipe: First connected: 5120×2880 HiDPI, Maximum Source Bandwidth 27,400 Mbps, Maximum Source Width 7680 Second connected: capped at 3840×2160 / 13,700 Mbps / Maximum Source Width 6720, HDR unavailable on that pipe at 120Hz Swapping which physical cable (C-to-C USB-C DP Alt Mode vs C-to-DP) connected first only changed which monitor got which pipe — the asymmetry itself persisted. This matched your explanation that the allocation happens in the kernel at connect time and is tied to the first display's presented configuration (Maximum Source Width 7680). M5 Max result (symmetric allocation, both pipes at full budget): Same two monitors, same cables (one USB-C DP Alt Mode, one USB-C-to-DP), set up as new (no migration, clean OS): Monitor 1 (C-to-DP, dispext2@0): Current Mode: 5120×2880 @ 165Hz HiDPI, 1:1 pixel mapped Maximum Source Bandwidth: 27,400 Mbps Maximum Source Width: 7680 10-bit RGB Full Range, HDR available Monitor 2 (C-to-C USB-C, dispext0@B0000000): Current Mode: 5120×2880 @ 144Hz HiDPI, 1:1 pixel mapped Maximum Source Bandwidth: 27,400 Mbps Maximum Source Width: 7680 10-bit RGB Full Range, HDR available Both pipes now report 27,400 Mbps and Maximum Source Width 7680. No 13,700 Mbps small-pipe assignment. No connection-order sensitivity — results are consistent regardless of which monitor is connected first. No BetterDisplay HiDPI override required; macOS selects 5K HiDPI natively on both. HDR enables on both displays simultaneously. The refresh difference (165Hz vs 144Hz) is purely the interface ceiling — the C-to-DP path negotiates DP 2.1 UHBR20 for 165Hz, while the USB-C input is DP 1.4-limited per the monitor's OSD and tops out at 144Hz with DSC. Both exceed the 120Hz target. This aligns with the MaxSrcRectWidthForPipe difference noted earlier — M5 Max exposing four entries (6720, 7680, 7680, 7680) vs M5 Pro's two. In practice the additional same-budget sub-pipes let the kernel hand both displays the full-width allocation rather than forcing one onto the smaller pipe. So for anyone with a similar dual-5K configuration: on M5 Pro the asymmetric allocation appears unavoidable for two simultaneous 5K@120Hz HiDPI displays, and the M5 Max resolves it natively without third-party intervention. Exactly as you predicted — appreciated the detailed engineering context throughout. FB22701284 updated with the M5 Max BetterDisplay reports for reference. — Reza

Thank you for the direct answer on M5 Max behavior — that's the specific data point I needed for the configuration decision. Closing this out as resolved. — Reza

Forgot to add the 4k connection vs 5k Connection via one connection on HDMI 2.1 and the other USB-C/TB changes depending on which connection is connected to the mac first.

Thank you.. Update with revised connection topology: Connection setup: Monitor 1: Mac built-in HDMI 2.1 port → LG-supplied Ultra High Speed HDMI cable (48 Gbps certified) → LG 27GM950B HDMI input set to "HDMI 2.1 PC" mode Monitor 2: Mac TB5 port → Silkland DP80 USB-C cable → LG 27GM950B USB-C input (DP Alt Mode, monitor's USB-C input is limited to DP 1.4 per OSD) Initial state (both monitors connected, no third-party software intervention): Monitor 1 (HDMI): 5120x2880 @ 120Hz HiDPI, YCbCr 4:4:4 Limited Range, 27,400 Mbps allocation. Monitor 2 (USB-C): 3840x2160 @ 120Hz HiDPI, RGB Full Range, 13,700 Mbps allocation. The kernel selected 4K HiDPI as the default mode on the smaller-allocation pipe — 5K HiDPI was not offered by macOS natively. After forcing HiDPI 5K on Monitor 2 via BetterDisplay 4.3.3: Monitor 2 transitioned to: 5120x2880 @ 60Hz HiDPI (VRR 48-60Hz), HDR10 RGB Full Range, 13,700 Mbps allocation. So the dual 5K HiDPI configuration is only achievable when a third-party utility (BetterDisplay) overrides the default macOS mode selection on the secondary display. Without that override, macOS defaults to 4K HiDPI on the smaller-allocation pipe. Full BetterDisplay 4.3.3 report data (both monitors, after HiDPI override on Monitor 2): Monitor 1 (HDMI, dispext0@B0000000): Current Mode: 5120x2880 @ 120Hz HiDPI (VRR 48-120Hz) Color Mode: HDR10_444LimitedRange Maximum Source Bandwidth: 27,400 Mbps Maximum Source Width: 7680 Transport Type: hdmi Preferred Mode: 5120x2880 @ 165Hz, 27,400 Mbps Monitor 2 (USB-C, dispext2@0): Current Mode: 5120x2880 @ 60Hz HiDPI (VRR 48-60Hz) Color Mode: HDR10_RGBFullRange Maximum Source Bandwidth: 13,700 Mbps Maximum Source Width: 6720 Transport Type: dp Preferred Mode: 3840x2160 @ 120Hz, 13,700 Mbps Observations: The asymmetric 27,400/13,700 Mbps allocation persists regardless of which monitor uses HDMI versus USB-C. Changing the connection type for one monitor changed which pipe each monitor received, but did not resolve the asymmetry. The kernel's default mode selection on the smaller-allocation pipe defaults to 4K HiDPI — the 5K HiDPI mode is only accessible via third-party override, and only achievable at 60Hz with VRR/HDR encoding due to the 13,700 Mbps ceiling. Does the M5 Max chip exhibit the same asymmetric two-pipe allocation behavior, or does it provide symmetric pipe allocation between two external displays? Specifically, would the same dual 5K configuration (one HDMI 2.1 + one USB-C DP Alt Mode, identical to the topology described above) result in both displays receiving equivalent bandwidth allocation natively, with both at 5K HiDPI as default selections, on M5 Max? The documented architectural difference (M5 Max showing four entries in MaxSrcRectWidthForPipe vs M5 Pro's two) suggests M5 Max may have additional sub-pipes available, but the underlying kernel allocation logic you described would still apply to either chip. Whether this results in symmetric, native dual 5K HiDPI for the described topology on M5 Max is the specific question.

Confirmed the configuration behavior with the first monitor manually set to 5120x2880 @ 120Hz before connecting the second monitor. Test results (both monitors connected, BetterDisplay 4.3.3 reports): First monitor (dispext0@B0000000): Current Mode: 5120x2880 @ 120Hz Maximum Source Bandwidth: 27,400 Mbps Maximum Source Width: 7680 Allocation maintained after second monitor hotplug Second monitor (dispext1@90000000): Current Mode: 3840x2160 @ 120Hz Preferred Mode at connection level: 3840x2160 @ 120Hz, 13,700 Mbps Maximum Source Bandwidth: 13,700 Mbps Maximum Source Width: 6720 Cannot negotiate 5120x2880 at any refresh rate on the smaller pipe Observations: The 120Hz cap on the first monitor prevents the runtime reallocation that previously occurred on second-monitor hotplug. However, the second monitor's connection-level preferred mode caps at 3840x2160 / 13,700 Mbps regardless of the first monitor's bandwidth consumption — the smaller pipe does not appear to receive additional bandwidth when the larger pipe is operating below its 27,400 Mbps ceiling. This is consistent with a fixed asymmetric two-pipe budget structure on M5 Pro (27,400 / 13,700 Mbps), rather than a shared pool that can rebalance based on demand. The BetterDisplay 4.3.3 allocation limits exposure (horizontal: 3360, 3840 pixels HiDPI / 6720, 7680 pixels LoDPI) is consistent with two sub-pipes of differing maximum widths. Connection topology note: Both monitors connect via USB-C, which on the 27GM950B is limited to DisplayPort 1.4 (OSD exposes DP 1.4 or DP 1.2 only — DP 2.1 is not available on the USB-C input). The DP 1.2 option caps the display at 4K, so a downward hardware cap on the first monitor isn't viable for preserving 5K capability on that connection. Questions: Is the 27,400 / 13,700 Mbps split a fixed M5 Pro DCP characteristic, or is there a configuration mechanism that allows the smaller pipe to receive additional bandwidth when the larger pipe is underutilized? Does the smaller pipe support 5120x2880 at any refresh rate, or is 3840x2160 @ 120Hz / 13,700 Mbps its maximum achievable mode regardless of OS state? Is the WindowServer assertion failure (r.170248892) expected to be addressed in a future macOS update, given that the underlying hotplug allocation logic appears tied to the same pipe assignment mechanism?