From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Hugo Sales <hugo@hsal.es>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jfalempe@redhat.com, javierm@redhat.com
Subject: Re: [PATCH 0/2] drm/client: Keep larger modes in connector->modes on fbdev hotplug
Date: Fri, 16 Oct 2026 15:28:39 +0300 [thread overview]
Message-ID: <atIYd0dd6ynXulwQ@intel.com> (raw)
In-Reply-To: <20261015212545.1989962-1-hugo@hsal.es>
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.
>
> Patch 1 makes drm_client_modeset_probe() probe with the device's limits
> and moves the framebuffer size check into the fbdev mode pickers.
> Patch 2 adds KUnit tests for it
>
> fbdev's hotplug probe has passed the framebuffer size since 2010
> (4abe35204af8). The pickers didn't check mode sizes then, so leaving
> larger modes out of the list was what kept fbdev from picking one. They
> check the size themselves now, so the probe can use the device's limits
> like initial setup, drm_log and GETCONNECTOR already do
>
> The HiBMC thread "[RFC] drm/client: Relax clone mode selection in
> drm_client_target_cloned" runs into the same pruning: its 640x480
> framebuffer removes 1024x768 from both connectors' lists. With this
> series userspace sees that mode again, but fbdev still can't use it, so
> this doesn't replace that RFC:
> https://lore.kernel.org/r/a48e0b33-7eab-478e-a396-b6e76b7a066f@huawei.com
>
> I sent an amdgpu fix for the same symptom separately. It makes amdgpu
> fall back to the encoder's native mode on eDP and LVDS:
> https://lore.kernel.org/r/20261014223041.171317-1-hugo@hsal.es
> This series fixes the shared mode list for every driver instead. Either
> one alone fixes the reported bug, from my testing
>
> On amd-staging-drm-next with only this series applied, with an HDMI
> hotplug and suspend/resume (pm_test=platform) in a loop, 255 of 255
> resumes kept the native timing. Without it, 28 of 29 came back with the
> wrong timing, and the same loop on unpatched v7.2.8 got it wrong in 103
> of 103. The drm KUnit tests pass, also under KASAN, which reports
> nothing in the code this series touches
>
> Hugo Sales (2):
> drm/client: Probe connectors with the device's mode size limits
> drm/tests: Add KUnit tests for the client mode size limits
>
> drivers/gpu/drm/drm_client_modeset.c | 57 +++--
> .../gpu/drm/tests/drm_client_modeset_test.c | 222 +++++++++++++++++-
> 2 files changed, 260 insertions(+), 19 deletions(-)
>
> --
> 2.55.0
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2026-10-16 12:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 21:25 [PATCH 0/2] drm/client: Keep larger modes in connector->modes on fbdev hotplug Hugo Sales
2026-10-15 21:25 ` [PATCH 1/2] drm/client: Probe connectors with the device's mode size limits Hugo Sales
2026-10-15 21:32 ` sashiko-bot
2026-10-15 21:25 ` [PATCH 2/2] drm/tests: Add KUnit tests for the client " Hugo Sales
2026-10-15 21:34 ` sashiko-bot
2026-10-16 12:28 ` Ville Syrjälä [this message]
[not found] ` <20261016131652.483525-1-hugo@hsal.es>
2026-10-16 13:57 ` [PATCH 0/2] drm/client: Keep larger modes in connector->modes on fbdev hotplug Ville Syrjälä
[not found] ` <20261016144013.1014546-1-hugo@hsal.es>
2026-10-16 15:20 ` Ville Syrjälä
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atIYd0dd6ynXulwQ@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hugo@hsal.es \
--cc=javierm@redhat.com \
--cc=jfalempe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.