From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: drm fb helpers hotplug/resize
Date: Fri, 7 Oct 2022 11:19:45 +0300 [thread overview]
Message-ID: <Yz/hIZaKJhtznFnc@intel.com> (raw)
In-Reply-To: <3e761cd0-7527-871e-5d53-1af223418fac@suse.de>
On Fri, Oct 07, 2022 at 09:58:31AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 07.10.22 um 09:15 schrieb Ville Syrjälä:
>
> >>
> >> For the absolute size of fbdev memory, I think we should introduce a
> >> module parameter in drm_fb_helper, which an option to set a default
> >> value in the kernel config. It would benefit all drivers that use fbdev
> >> emulation and work how overalloc works.
> >>
> >> If no size is given, the current approach would be used.
> >>
> >> I don't think resizing would work immediately. There isn't anything in
> >> the check_var and set_par functions that implements the necessary atomic
> >> check and commit.
> >
> > set_par() is the thing tht does the commit.
> >
>
> I know. There actually even is a commit statement in set_par, which can
> restore the initial mode. My point is that it has no means of changing
> the display mode. A full modeset would require us to convert the fb
> screeninfo into an atomic state and commit that instead. For the fbconv
> helper, I once made code to convert between the two. Leaving this here
> for reference. [1][2]
Uff. Right, we'd probably just want to properly implemnt set_par()
then.
BTW I had a slightly different take on the bitfiled stuff.
Maybe a bit easier to extend for new formats, but full of macros:
https://patchwork.freedesktop.org/patch/203189/?series=37820&rev=1
>
> Similarly, in check_var we sort out and reject all mode changes. We'd
> have to change that as well.
I guess we could do a TEST_ONLY commit there. Though I think
not doing that and just failing from set_par() should be fine
too.
>
> I guess we can continue to ignore non-atomic modesetting.
>
> Best regards
> Thomas
>
> [1]
> https://gitlab.freedesktop.org/tzimmermann/linux/-/commit/385161cd2d048b5cf80544bff8ced3da7a82dfa9
> [2]
> https://gitlab.freedesktop.org/tzimmermann/linux/-/commit/a541c405a638f47ee80389b222fbde6e311e8220
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
--
Ville Syrjälä
Intel
prev parent reply other threads:[~2022-10-07 8:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-05 19:49 drm fb helpers hotplug/resize Zack Rusin
2022-10-06 8:01 ` Thomas Zimmermann
2022-10-07 2:16 ` Zack Rusin
2022-10-07 7:10 ` Thomas Zimmermann
2022-10-07 7:15 ` Ville Syrjälä
2022-10-07 7:58 ` Thomas Zimmermann
2022-10-07 8:19 ` 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=Yz/hIZaKJhtznFnc@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox