[PATCH] modesetting: Support native primary plane rotation

[Chris Wilson]

On Wed, Jul 09, 2014 at 10:44:17AM +0300, Pekka Paalanen wrote:
> On Wed,  9 Jul 2014 08:00:21 +0100
> Chris Wilson <chris at chris-wilson.co.uk> wrote:
> 
> > With the advent of universal drm planes and the introduction of generic
> > plane properties for rotations, we can query and program the hardware
> > for native rotation support.
> > 
> > NOTE: this depends upon the next release of libdrm to remove some
> > opencoded defines.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> >  configure.ac          |   2 +-
> >  src/drmmode_display.c | 223 +++++++++++++++++++++++++++++++++++++++++++-------
> >  src/drmmode_display.h |   7 +-
> >  3 files changed, 199 insertions(+), 33 deletions(-)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 1c1a36d..0b4e857 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -74,7 +74,7 @@ AM_CONDITIONAL(HAVE_XEXTPROTO_71, [ test "$HAVE_XEXTPROTO_71" = "yes" ])
> >  # Checks for header files.
> >  AC_HEADER_STDC
> >  
> > -PKG_CHECK_MODULES(DRM, [libdrm >= 2.4.46])
> > +PKG_CHECK_MODULES(DRM, [libdrm >= 2.4.54]) #.55 required for universal planes
> >  PKG_CHECK_MODULES([PCIACCESS], [pciaccess >= 0.10])
> >  AM_CONDITIONAL(DRM, test "x$DRM" = xyes)
> >  
> > diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> > index c533324..aaeda39 100644
> > --- a/src/drmmode_display.c
> > +++ b/src/drmmode_display.c
> > @@ -56,6 +56,11 @@
> >  
> >  #include "driver.h"
> >  
> > +#define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2
> > +#define DRM_PLANE_TYPE_OVERLAY 0
> > +#define DRM_PLANE_TYPE_PRIMARY 1
> > +#define DRM_PLANE_TYPE_CURSOR  2
> 
> Hi,
> 
> is this really something that is guaranteed to be kernel ABI stable?
> 
> I mean, the 'type' property is an enum. I have never seen the enum
> (numerical) values being defined in any public ABI header. Instead,
> the property system has a mechanism for listing the enum values by
> name string.
> 
> I have assumed that the name string is what is guaranteed ABI, and
> the numerical value is just an arbitrary handle. When I added
> universal planes support to Weston (not merged yet), I look up the
> numerical value by the name, instead of hardcoding the numerical
> value.
> 
> Should you do the same here, or are the numerical values really
> (going to be) part of the ABI?

Oops, I was trying to keep it generic and only use enum names and
overlooked that the plane type was an enum.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre