[Intel-gfx] [PATCH 01/11] drm: add plane support

[Inki Dae]

Hi, Jesse.

Jesse Barnes <jbarnes <at> virtuousgeek.org> writes:

> 
> On Mon, 31 Oct 2011 11:40:57 +0000 (UTC)
> Inki Dae <daeinki <at> gmail.com> wrote:
> > below is my simple idea.
> > 1. user requests buffer allocation with pixel format and resolution 
through 
> > gem framework.
> > 2. gem framework checks pixel format.
> > 3. specific gem framework allocates buffers as plane count according to 
the 
> > pixel format. (please, know that gem framework provides just interface so 
> > acctual implementation would be done at specific gem framework)
> > 4. user gets the gem handle from gem framework.
> > 5. user sets the gem handle to specific drm framebuffer through 
> > drm_mode_addfb2 function.
> > 6. user requests setcrtc with fb id and crtc id.
> > 7. drm framework sets framebuffer(corresponding to fb id) to drm_mode_set.
> > 8. crtc calls set_config callbacks to configure hardware.
> > 9. specific crtc framework gets all buffers through framebuffer(actually, 
it 
> > would be specific framebuffer)and sets them to overlay registers of 
hardware 
> > appropriately.
> > 
> > 
> > like this, how about using framebuffer and gem framework instead of plane? 
I'd 
> > be glad to give me your opinions.
> 
> I'm not opposed to pushing the multi-object stuff into GEM instead, but
> I don't think step (9) will be enough to avoid having a separate plane
> object.  Say the user passes in 3 RGB buffers.  How do you know which
> one is the primary and which are overlays?  Or are you saying the fb
> would have that information as well?  If so, it would be a little
> harder to specify things like blending options or colorspace correction
> on a per-plane basis...
> 
> But maybe I'm missing some part of things; do you have any patches to
> illustrate what you mean?  I can see how it might work, but I don't
> know if it would be any simpler or cleaner than exposing plane objects.
> 
> Thanks,

Sorry, there is my missing point. please, ignor step 6 ~ 9.
if user requests setplane then drm_mode_setplane function gets fb and crtc 
object to update the overlay corresponding to plane id. at that time I think 
we could know which overlay should be set and how many buffers does the 
overlay has through specific framebuffer object if specific framebuffer has 
gem object.
in our case, specific framebuffer has gem object. and I would try to implement 
multi planer the way I mentioned if need and I will post the patch. this work 
takes about a week. I think the way that user allocates buffers for multi 
planer only with pixel format and resolution(width, height) would be good. but 
there could be more good ways then this way.

please give me your opinion and advices.

Thank you,
Inki Dae.