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 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.