On Wed, 2 Nov 2011 02:20:58 +0000 (UTC) Inki Dae <daei...@gmail.com> wrote: > 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.
Right, that's the goal anyway. > 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. Ok, that would help. Rob and Daniel also wanted the addfb2 ioctl to be extended a bit more to handle planar formats and also to specify surface offsets. Now that I have the X driver working well enough to do clipping and multi-pipe, I'll update addfb2 and post an updated patchset today. You can see if it will address what you're trying to do with planar formats. 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
