Mutter does not handle bandwidth requirement correctly when MST Hubs are used in clone mode
Affected version
OS: Ubuntu 22.04 Gnome version: 42.9 Display Server: Xorg & Wayland
Bug summary
Hardware necessary to repro:
- MST Hub without DSC support (eg. https://www.startech.com/en-ca/display-video-adapters/mst14dp123dp)
- Two 4k monitors with refresh rate above 60Hz. Preferably 4k144 + 4k60. Issue is also reproduced on dual 4k60Hz monitors, but having different modelines for 4k60 at a higher pixel clock, for example, here is a modeline from a ThinkVision monitor:
Modeline "3840x2160": 60 533250 3840 3888 3920 4000 2160 2163 2168 2222 0x48 0x9
Modeline "3840x2160": 60 594000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5
Issue was reproduced when this monitor was plugged in along with another monitor with a single 4k60 modeline (clock 513 KHz) was used.
- AMD RX 7900 XT or any recent amdgpu supported graphics card (although any other driver should behave the same way).
Steps to reproduce
- Connect two monitors to the MST Hub, and plug the Hub them to a DP output from the dGPU
- By default,, monitors are connected in extended mode.
- Open display settings, and set the two monitor to clone mode
- Its seen that intermittently, one monitor gives a black screen.
- Downgrading resolution from display settings to a lower value make the system able to lightup both displays.
What happened
With startech hub, system lights up both the displays in extended mode by default. The displays have multiple pixel clocks available to lightup a 4k60 mode - one with 533Khz and other with 594Khz. These are modes from its EDID. If userspace chooses to lightup a 4k60 mode with either of these individually, we're good. Former takes 31 slots (total 64 available for DP 1.4), but latter takes 36 slots. When both are plugged in, we can only lightup if the system chose modes with both 533Khz pixel clock. 533khz + 594Khz will not work for Startech mst hub (31+36 > 64).
However, with Cablematters MST hub (with DSC support), 533Khz + 594Khz works fine because it supports DSC which reduces the slot requirement (from 36 to 23).
In all cases that failed to lightup, userspace tried to commit a mode that exceed the bw. Display driver responds correctly by sending -ENOSPC during atomic check. However, the userspace does not try modes with lower pixel clocks afterwards, we stay with a black screen on one of the monitors.
What did you expect to happen
Mutter should detect the -NOSPC from atomic check and retry with different modelines. Bandwidth requirement is directly proportional to pixel clock. Hence for the same resolution, mutter should try to find an appropriate mode when setting clone mode.