Re: [PATCH 0/2] drm/client: Keep larger modes in connector->modes on fbdev hotplug

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, Oct 16, 2026 at 02:16:52PM +0100, Hugo Sales wrote:
> On Fri, Oct 16, 2026 at 03:28:39PM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 15, 2026 at 10:25:43PM +0100, Hugo Sales wrote:
> > > On an ASUS ROG Flow X13 with a 3840x2400 eDP panel, booted with
> > > video=eDP-1:1920x1200@60, an HDMI hotplug makes fbdev reprobe every
> > > connector with its 1920x1200 framebuffer as the limit. connector->modes
> > > loses the panel's 3840x2400 mode, and after suspend/resume amdgpu drives
> > > the panel with the 1920x1200 timing. The image ends up squeezed into the
> > > top-left corner. Details are in
> > > https://gitlab.freedesktop.org/drm/amd/-/issues/5983
> >
> > Sounds like an amdgpu bug.
> 
> Agreed, the resume bug is in amdgpu. It looks up the eDP native mode in
> connector->modes, which fbdev's hotplug probe can trim. This series
> fixes it there:
> https://lore.kernel.org/r/20261014223041.171317-1-hugo@hsal.es
> 
> I sent this one for the shared list itself because after a hotplug,
> connector->modes depends on fbdev's framebuffer size, while initial
> setup, drm_log and GETCONNECTOR probe with the device's limits.

Connectors aren't probed before something actually probes them.
Typically that would be fbdev.

> Until
> something reprobes, the sysfs modes file and any driver that reads the
> list see the trimmed version
> 
> amdgpu isn't the only driver that reads it. stm/lvds and
> shmob_drm_encoder_mode_fixup() take the first entry of connector->modes
> as the panel mode, so they may hit the same thing with a video= mode
> smaller than the panel. I haven't tested those, because I don't have
> the hardware. Fixing it in the core covers them without each driver
> keeping its own copy of the native mode

Those things will need to be fixed regardless because they are
broken wrt locking.

But I suppose not filtering the mode list based on the fbdev size
might be a bit less confusing for anyone who looks at the mode
list via sysfs. Can't immediately think what else besises the 
fbdev/client code would depend on this, so maybe it's fine.

If we do this then I think we should stop passing the size to
.fill_modes() entirely, because we always pass the same device
limits. The downside is all those annoying extra
drm_mode_validate_size() calls everywhere, but I guess we
could live with that.

-- 
Ville Syrjälä
Intel