[PATCH 0/2] drm/client: Clear stale cmdline modes before the 1024x768 clone pass

[Hugo Sales <hugo@hsal.es>]

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/20261024165355.2782145-1-hugo@hsal.es/

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