This is a bug report for a KBL machine. This issue can be reproduce on both Sway  and Weston. The Sway issue contains a DRM dmesg excerpt.
User-space tries to enable a pipe with a 3840x2160 XRGB8888 buffer. The buffer is created with gbm_surface_create_with_modifiers. The primary plane supports I915_FORMAT_MOD_Y_TILED_CCS, it seems like that's what the driver is picking.
However when scanning out the buffer, the driver bails out with "Requested display configuration exceeds system DDB limitations". This results in a black screen.
My main question is: both Weston and wlroots except gbm_surface_create_with_modifiers to pick a modifier so that the buffer can be scanned out . I wouldn't expect the driver to pick a modifier that doesn't work.
If this isn't a driver bug, should user-space force LINEAR if the atomic commit fails? Should it prune the modifier and retry with gbm_surface_create_with_modifiers?
The DDB stuff depends on dotclock, number of pipes/planes, plane size, plane/pipe scaling, etc. so there is no real way to know upfront whether a particular framebuffer can be scanned out or not.
There should probably be some kind of mechanism to fall back to X-tiled if Y/Y+CCS fails.
In this particular case it's not entirely clear why it fails though. A full log would help. And probably we would want the following addition as well:
@@ -4401,6 +4401,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state,
DRM_DEBUG_KMS("Requested display configuration exceeds system DDB limitations");
DRM_DEBUG_KMS("minimum required %d/%d\n", blocks,
Hmm, I always get that when trying to use both planes, but when using AR24. XR24 works just fine on scan-out (primary)
[51903.929518] [drm:skl_allocate_pipe_ddb [i915]] Requested display configuration exceeds system DDB limitations
[51903.929551] [drm:skl_allocate_pipe_ddb [i915]] minimum required 964/847
[51903.929584] [drm:drm_atomic_check_only [drm]] atomic driver check for 000000004889d62d failed: -22
[51903.929615] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state 000000004889d62d
but even so, weston is able to continue just fine switching to mixed mode of compositing
[view] failing state generation: atomic test not OK
[repaint] could not build planes-only state, trying mixed
For reference this seems to happen when using AR24 on scan-out not XR24 (which I tested many times before).
Here's the current state of both planes, before doing the TEST_ONLY bit.
[CRTC:47] 22 (MODE_ID) -> 120 (0x78)
[CRTC:47] 21 (ACTIVE) -> 1 (0x1)
[CONN:85] 19 (CRTC_ID) -> 47 (0x2f)
[PLANE:37] 16 (FB_ID) -> 122 (0x7a)
[PLANE:37] 19 (CRTC_ID) -> 47 (0x2f)
[PLANE:37] 8 (SRC_X) -> 0 (0x0)
[PLANE:37] 9 (SRC_Y) -> 0 (0x0)
[PLANE:37] 10 (SRC_W) -> 251658240 (0xf000000)
[PLANE:37] 11 (SRC_H) -> 141557760 (0x8700000)
[PLANE:37] 12 (CRTC_X) -> 0 (0x0)
[PLANE:37] 13 (CRTC_Y) -> 0 (0x0)
[PLANE:37] 14 (CRTC_W) -> 3840 (0xf00)
[PLANE:37] 15 (CRTC_H) -> 2160 (0x870)
[PLANE:37] FORMAT: XRGB8888
[PLANE:30] 16 (FB_ID) -> 121 (0x79)
[PLANE:30] 19 (CRTC_ID) -> 47 (0x2f)
[PLANE:30] 8 (SRC_X) -> 0 (0x0)
[PLANE:30] 9 (SRC_Y) -> 0 (0x0)
[PLANE:30] 10 (SRC_W) -> 251658240 (0xf000000)
[PLANE:30] 11 (SRC_H) -> 141557760 (0x8700000)
[PLANE:30] 12 (CRTC_X) -> 0 (0x0)
[PLANE:30] 13 (CRTC_Y) -> 0 (0x0)
[PLANE:30] 14 (CRTC_W) -> 3840 (0xf00)
[PLANE:30] 15 (CRTC_H) -> 2160 (0x870)
[PLANE:30] FORMAT: ARGB8888
Do note, this is with e-DP as connector (it's previous gen xps 13'' laptop w/ i7-8550U).
After discussing with Pekka, agreed this is a userspace issue and ended up falling back to no modifiers when using modifiers fails: https://github.com/swaywm/wlroots/pull/1870
I guess Weston could come up with a similar solution.