On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
> From: Andre Renaud <andre@xxxxxxxxxxxxxxxx>
>
> Added support for zorder changes through DRM plane properties
>
> Signed-off-by: Andre Renaud <andre@xxxxxxxxxxxxxxxx>
> Signed-off-by: Rob Clark <rob@xxxxxx>
> ---
> drivers/staging/omapdrm/omap_drv.h | 1 +
> drivers/staging/omapdrm/omap_plane.c | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/staging/omapdrm/omap_drv.h b/drivers/staging/omapdrm/omap_drv.h
> index b103d28..9dc72d1 100644
> --- a/drivers/staging/omapdrm/omap_drv.h
> +++ b/drivers/staging/omapdrm/omap_drv.h
> @@ -62,6 +62,7 @@ struct omap_drm_private {
>
> /* properties: */
> struct drm_property *rotation_prop;
> + struct drm_property *zorder_prop;
> };
>
> /* this should probably be in drm-core to standardize amongst drivers */
> diff --git a/drivers/staging/omapdrm/omap_plane.c b/drivers/staging/omapdrm/omap_plane.c
> index 6931d06..4bde639 100644
> --- a/drivers/staging/omapdrm/omap_plane.c
> +++ b/drivers/staging/omapdrm/omap_plane.c
> @@ -433,6 +433,15 @@ void omap_plane_install_properties(struct drm_plane *plane,
> priv->rotation_prop = prop;
> }
> drm_object_attach_property(obj, prop, 0);
> +
> + prop = priv->zorder_prop;
> + if (!prop) {
> + prop = drm_property_create_range(dev, 0, "zorder", 0, 3);
> + if (prop == NULL)
> + return;
> + priv->zorder_prop = prop;
> + }
> + drm_object_attach_property(obj, prop, 0);
> }
>
> int omap_plane_set_property(struct drm_plane *plane,
> @@ -452,6 +461,16 @@ int omap_plane_set_property(struct drm_plane *plane,
> ret = omap_plane_dpms(plane, DRM_MODE_DPMS_ON);
> else
> ret = 0;
> + } else if (property == priv->zorder_prop) {
> + struct omap_overlay *ovl = omap_plane->ovl;
> +
> + DBG("%s: zorder: %d", ovl->name, (uint32_t)val);
> + omap_plane->info.zorder = val;
What would happen when there's a conflicting assignment between two
planes?
I tried to think of a decent way to do this stuff, but some hardware
can have rather complicated stacking order limitations. One idea I
came up with was to have an enum prop on the crtc, where the individual
enum value names would somehow describe the whole stacking order within
the crtc. That way user space couldn't even try to use an unsupported
configuration. The downside is that user space would need to parse
those strings if it wants to do some automagic stacking order changes,
which means the string format would need some though.
--
Ville Syrjälä
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
