On Fri, Jul 22, 2011 at 10:30 AM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > 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. > I'm ok with this.. we can always add a common ioctl later if we end up with multiple drivers doing things the same way BR, -R > -- > Jesse Barnes, Intel Open Source Technology Center > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel