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? ;-)
BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
