On Thu, Aug 16, 2012 at 8:00 AM, Ville Syrjälä
<ville.syrjala@xxxxxxxxxxxxxxx> wrote:
> 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?
non-good things.. basically as part of re-working the
omapdss<->omapdrm stuff, I'll have a good point in omapdrm before
setting GO bit(s) where I can calculate the actual z-order from that
is set from userspace. If two planes had same z-order from userspace,
omapdrm would simply put one in front of the other. If the planes
aren't overlapping, this is fine.
> 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.
I was thinking about this, but then you run into the same issue if you
move a plane from one CRTC to another without userspace setting the
property again. In the end if userspace is ambiguous the driver has
to just arbitrarily pick some z-order to keep the hw happy.
BR,
-R
> --
> 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
--
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
