https://bugs.kde.org/show_bug.cgi?id=527820
Bug ID: 527820
Summary: Wayland: ENOSPC on initial modeset leaves black screen
instead of picking largest fitting mode
Classification: Plasma
Product: kwin
Version First 6.7.5
Reported In:
Platform: CachyOS
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: platform-drm
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
DESCRIPTION
On a USB4 dock with two DP MST monitors, the EDID-preferred mode
(2560x1440@144 on each) does not fit the dock's MST bandwidth, so the
atomic test fails with ENOSPC and KWin leaves both screens black. KWin
never tries the modes that would fit (2x1440p60 works fine) and never
surfaces any error, so a first Wayland session on this hardware looks
like a broken desktop. X11 on the same dock is fine because the legacy
path never runs the atomic validation.
I traced the bandwidth side down to the kernel (USB4 DPIA link on this
platform provides 63 MST time slots total; one 1440p144 stream needs 70,
so even a single 144 Hz stream is impossible; 1440p60 needs 29 each) and
am filing that separately with amd-gfx. This report is about the KWin
side: a legal modeset request that the kernel rejects with a clear,
specific error code should not be able to produce a silent black screen.
STEPS TO REPRODUCE
1. Minisforum MS-S1 Max (AMD Strix Halo, Barlow Ridge USB4 router), USB4
dock, two monitors whose EDID prefers 2560x1440@144 behind the dock's
MST stream. Dock attached before boot.
2. Fresh user (no saved output config), Plasma Wayland login.
3. Observe outputs after the session starts.
OBSERVED RESULT
Both screens stay black ("no signal" or blank). No notification, no
error dialog, nothing usable; the session eventually has to be killed
from a VT. dmesg (from my instrumented build of 7.2.9) shows why:
find_ts: pbn=2088 req_slots=70 -> ENOSPC (only 63 slots available)
KWin requested the EDID-preferred mode, got ENOSPC from the atomic
test, and has no path down to a mode that would commit.
EXPECTED RESULT
When a mode fails the atomic test specifically with ENOSPC (bandwidth),
retry down the mode list until something commits (here 1440p60 works on
both outputs and fits with slots to spare), then show an OSD
notification on the same channel as the existing session-failure notice,
something like "one or more displays were set to a lower refresh rate
because the connection cannot carry the preferred mode", and persist
that decision. A user should never be locked out by a bandwidth ceiling
they cannot see.
SOFTWARE/OS VERSIONS
Operating System: CachyOS (Arch-based rolling), kernel 7.2.9-1-cachyos
(also reproduced on linux-cachyos-lts 6.18.55)
KDE Plasma Version: 6.7.5 (kwin 6.7.5-1.1)
KDE Frameworks Version: 6.30.0
Qt Version: 6.11.2
ADDITIONAL INFORMATION
- Reproduced identically on BIOS 1.06 and 1.11 (firmware updated
specifically to rule this out), kernels 7.2.9 and 6.18 LTS. This is
not firmware-specific: any platform whose DPIA/MST bandwidth
allocation is smaller than the EDID preferred mode needs will hit it.
- Workaround in use: pin both outputs to 2560x1440@59951 in
~/.config/kwinoutputconfig.json. Wayland then works perfectly and
loses nothing versus X11, which has silently been running 60 Hz on
this dock the whole time.
- Footgun while using that workaround: saved-config mode matching is
exact-match in millihertz. refreshRate: 60000 does NOT match KWin's
computed 59951 for the panel DTD and the pin silently does nothing.
Since this file is the documented recovery path for exactly the black
screen situation above, a small tolerance (or matching by clock,
htotal, vtotal rather than the rounded mHz) would make the escape
hatch actually work.
- Same-signature user reports (no root cause posted yet):
https://discuss.kde.org/t/problems-with-displayport-mst-multi-monitor-setup/42679
including the "plug the dock in after login" folk workaround, which
is consistent with this being the no-saved-mode first-modeset path.
- Happy to test patches; I still have the instrumented probe build and
the full capture on request.
--
You are receiving this mail because:
You are watching all bug changes.
