On Mon, 31 Oct 2011 11:40:57 +0000 (UTC) Inki Dae <daei...@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, -- Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
