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?

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.

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 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