On Fri, 22 Jul 2011 08:52:52 -0500
Rob Clark <robdclark@xxxxxxxxx> wrote:
> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
> > /**
> > + * drm_plane_funcs - driver plane control functions
> > + * @update_plane: update the plane configuration
> > + */
> > +struct drm_plane_funcs {
> > + int (*update_plane)(struct drm_plane *plane,
> > + struct drm_crtc *crtc, struct drm_framebuffer *fb,
> > + int crtc_x, int crtc_y,
> > + unsigned int crtc_w, unsigned int crtc_h,
> > + uint32_t src_x, uint32_t src_y,
> > + uint32_t src_w, uint32_t src_h);
> > + void (*disable_plane)(struct drm_plane *plane);
> > +};
> > +
>
>
> would it freak anyone out too much to ask about multi-planar formats?
> Ie. say you have an overlay that could display I420 w/ separate Y, U,
> & V addresses or NV12 w/ separate Y and UV addresses. Some of the
> SoC's out there require that chroma and luma is in different memory
> banks. In omap4xxx case we don't have this requirement, but we do
> have different tiling for Y and UV (NV12).
>
> Not something that directly affects this patchset.. I'm thinking more
> along the lines of having a way to create a drm_framebuffer w/ more
> than one GEM buffer, one per color plane. The other option is to bury
> this all behind a single GEM buffer.. although that seems like it
> could get ugly/hacky.
>
> Am I opening a can of worms here? ;-)
Yes. :)
Given the format constraints for planar, multi-buffer configs, it might
be best to expose those as driver specific ioctls. It's a big ugly to
have a driver specific addfb (only because we don't have one currently)
but should be doable for funkier things like this.
--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
