[PATCH 2/2] Expose the OMAP Z-Order property through DRM

[Rob Clark]

On Thu, Aug 16, 2012 at 8:00 AM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
>> From: Andre Renaud <andre at bluewatersys.com>
>>
>> Added support for zorder changes through DRM plane properties
>>
>> Signed-off-by: Andre Renaud <andre at bluewatersys.com>
>> Signed-off-by: Rob Clark <rob at ti.com>
>> ---
>>  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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html