drm_client_target_cloned() first tries to clone with the mode each connector got from the kernel's video= option, then falls back to 1024x768 on every connector. The fallback keeps the modes the first pass left behind, so a connector that has a video= mode set and no 1024x768 mode can make it report a clone with modes that differ. On a single-CRTC device one connector then gets no CRTC
Patch 1 frees those modes before the fallback. Patch 2 adds a KUnit test that fails without it Sashiko flagged this while reviewing my fbdev probe series [1]. I haven't hit it on hardware: it needs a single-CRTC device with two connected outputs and video= set on only some of them, and it only shows on the fbdev console. The KUnit test reproduces it, but how often it happens on real systems is unconfirmed [1] https://lore.kernel.org/all/[email protected]/ Hugo Sales (2): drm/client: Clear cmdline modes before the 1024x768 clone pass drm/tests: client-modeset: Test cloning with video= on one connector drivers/gpu/drm/drm_client_modeset.c | 2 + .../gpu/drm/tests/drm_client_modeset_test.c | 109 +++++++++++++++++- 2 files changed, 110 insertions(+), 1 deletion(-) base-commit: a1e63ab695ad76850ab9787b9eb6aab695dc2965 -- 2.56.0
