dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

      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