[Intel-gfx] [PATCH 01/11] drm: add plane support
jbarnes at virtuousgeek.org
Mon Oct 31 09:52:45 PDT 2011
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
> 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.
Jesse Barnes, Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the Intel-gfx