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 18:20:02 +0300 [thread overview]
Message-ID: <atJAora2ehsbYz90@intel.com> (raw)
In-Reply-To: <20261016144013.1014546-1-hugo@hsal.es>
On Fri, Oct 16, 2026 at 03:40:13PM +0100, Hugo Sales wrote:
> On Fri, Oct 16, 2026 at 04:57:30PM +0300, Ville Syrjälä wrote:
> > Connectors aren't probed before something actually probes them.
> > Typically that would be fbdev.
>
> I think I may have misspoken before. fbdev's first probe already uses
> the device's limits: __drm_fb_helper_initial_config_and_unlock() passes
> max_width and max_height. Only drm_fb_helper_hotplug_event() passes the
> framebuffer size, so the list starts with every mode and loses the
> larger ones on the first hotplug. This series makes the hotplug probe
> match the first one
Right, forgot about the initial probe. And I think we definitely
want the initial probe to use the max size because we don't want
to keep the BIOS framebuffer if it's tiny. A long time ago we
kept the BIOS fb no matter what, but that made the console pretty
much unusable (due to being too small) on some machines.
>
> Are you suggesting a different approach?
Nah, I guess what you're doing should be fine.
--
Ville Syrjälä
Intel
prev parent reply other threads:[~2026-10-16 15:20 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 ` [PATCH 0/2] drm/client: Keep larger modes in connector->modes on fbdev hotplug Ville Syrjälä
[not found] ` <20261016131652.483525-1-hugo@hsal.es>
2026-10-16 13:57 ` Ville Syrjälä
[not found] ` <20261016144013.1014546-1-hugo@hsal.es>
2026-10-16 15:20 ` Ville Syrjälä [this message]
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=atJAora2ehsbYz90@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.