[PATCH] modesetting: Support native primary plane rotation
chris at chris-wilson.co.uk
Wed Jul 9 01:05:32 PDT 2014
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
> 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
> 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 Wilson, Intel Open Source Technology Centre
More information about the xorg-devel