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/[email protected] > > 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
