[PATCH] modesetting: Support native primary plane rotation

2014-07-09 Thread Chris Wilson 
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 ch...@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
+
 static struct dumb_bo *dumb_bo_create(int fd,
  const unsigned width, const unsigned height,
  const unsigned bpp)
@@ -300,6 +305,136 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode,
 
 #endif
 
+static unsigned
+rotation_index(unsigned rotation)
+{
+#if _SVID_SOURCE || _BSD_SOURCE || _POSIX_C_SOURCE = 200809L || _XOPEN_SOURCE 
= 700
+   return ffs(rotation) - 1;
+#else
+   int i;
+
+   for (i = 0; i  32; i++) {
+   if ((1  i) == rotation)
+   break;
+   }
+
+   return i;
+#endif
+}
+
+static void
+rotation_init(xf86CrtcPtr crtc)
+{
+   drmmode_crtc_private_ptr drmmode_crtc = crtc-driver_private;
+   drmmode_ptr drmmode = drmmode_crtc-drmmode;
+   drmModePlaneRes *plane_resources;
+   int i, j, k;
+
+   drmSetClientCap(drmmode-fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
+
+   plane_resources = drmModeGetPlaneResources(drmmode-fd);
+   if (plane_resources == NULL)
+   return;
+
+   for (i = 0; i  plane_resources-count_planes; i++) {
+   drmModePlane *drm_plane;
+   drmModeObjectPropertiesPtr proplist;
+   int type = -1;
+
+   drm_plane = drmModeGetPlane(drmmode-fd,
+   plane_resources-planes[i]);
+   if (drm_plane == NULL)
+   continue;
+
+   if (!(drm_plane-possible_crtcs  (1  drmmode_crtc-index)))
+   goto free_plane;
+
+   proplist = drmModeObjectGetProperties(drmmode-fd,
+ drm_plane-plane_id,
+ DRM_MODE_OBJECT_PLANE);
+   if (proplist == NULL)
+   goto free_plane;
+
+   for (j = 0; type == -1  j  proplist-count_props; j++) {
+   drmModePropertyPtr prop;
+
+   prop = drmModeGetProperty(drmmode-fd, 
proplist-props[j]);
+   if (!prop)
+   continue;
+
+   if (strcmp(prop-name, type) == 0)
+   type = proplist-prop_values[j];
+
+   drmModeFreeProperty(prop);
+   }
+
+   if (type == DRM_PLANE_TYPE_PRIMARY) {
+   drmmode_crtc-primary_plane_id = drm_plane-plane_id;
+
+   for (j = 0; drmmode_crtc-rotation_prop_id == 0  j  
proplist-count_props; j++) {
+   drmModePropertyPtr prop;
+
+   prop = drmModeGetProperty(drmmode-fd, 
proplist-props[j]);
+   if (!prop)
+   continue;
+
+   if (strcmp(prop-name, rotation) == 0) {
+   drmmode_crtc-rotation_prop_id = 
proplist-props[j];
+   drmmode_crtc-current_rotation = 
proplist-prop_values[j];
+   for (k = 0; k  prop-count_enums; k++) 
{
+   int rr = -1;
+   if (strcmp(prop-enums[k].name, 
rotate-0) == 0)
+   rr = RR_Rotate_0;
+   else if 
(strcmp(prop-enums[k].name, rotate-90) == 0)
+   rr = RR_Rotate_90;
+   else if 
(strcmp(prop-enums[k].name, rotate-180) == 0)
+

Re: [PATCH libXi 2/2] XIPassiveGrab: Fix completely broken locking in XIGrabTouchBegin

2014-07-09 Thread walter harms 


Am 08.07.2014 23:01, schrieb Jasper St. Pierre:
 _XIPassiveGrabDevice calls LockDisplay as the first thing it does. That
 means that it expects the display to be unlocked. XIGrabTouchBegin locks
 the display to check for the XI extension, and then never unlocks it.
 Effectively, this meant that anybody that called XIGrabTouchBegin after
 XInitThreads just got a deadlock.
 
 Cool.
 ---
  src/XIPassiveGrab.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
 index f3a9924..88f1aff 100644
 --- a/src/XIPassiveGrab.c
 +++ b/src/XIPassiveGrab.c
 @@ -166,6 +166,7 @@ XIGrabTouchBegin(Display *dpy, int deviceid, Window 
 grab_window,
  LockDisplay(dpy);
  if (_XiCheckExtInit(dpy, XInput_2_2, extinfo) == -1)
   return -1;
 +UnlockDisplay(dpy);
  
  /* FIXME: allow selection of GrabMode for paired devices? */
  return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeTouchBegin, 0,


I am not an expert on this but you should  unlock the display on error also.
I would do it this way:

LockDisplay(dpy);
err=_XiCheckExtInit(dpy, XInput_2_2, extinfo);
UnlockDisplay(dpy);
if (err == -1)
return -1;

jz'ust my 2 cents
re,
 wh

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] modesetting: Support native primary plane rotation

2014-07-09 Thread walter harms 


Am 09.07.2014 09:00, schrieb Chris Wilson:
 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 ch...@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
 +
  static struct dumb_bo *dumb_bo_create(int fd,
 const unsigned width, const unsigned height,
 const unsigned bpp)
 @@ -300,6 +305,136 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode,
  
  #endif
  
 +static unsigned
 +rotation_index(unsigned rotation)
 +{
 +#if _SVID_SOURCE || _BSD_SOURCE || _POSIX_C_SOURCE = 200809L || 
 _XOPEN_SOURCE = 700
 + return ffs(rotation) - 1;
 +#else
 + int i;
 +
 + for (i = 0; i  32; i++) {
 + if ((1  i) == rotation)
 + break;
 + }
 +
 + return i;
 +#endif
 +}


perhaps it is better to provide an internal ffs for systems that lack one ?
than you can use ffs() directly and leave the rest to configure.
That would result in a generic HAVE_FFS instead of a list of defines like this 
now.

just my 2 cents,
re
 wh

 +static void
 +rotation_init(xf86CrtcPtr crtc)
 +{
 + drmmode_crtc_private_ptr drmmode_crtc = crtc-driver_private;
 + drmmode_ptr drmmode = drmmode_crtc-drmmode;
 + drmModePlaneRes *plane_resources;
 + int i, j, k;
 +
 + drmSetClientCap(drmmode-fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
 +
 + plane_resources = drmModeGetPlaneResources(drmmode-fd);
 + if (plane_resources == NULL)
 + return;
 +
 + for (i = 0; i  plane_resources-count_planes; i++) {
 + drmModePlane *drm_plane;
 + drmModeObjectPropertiesPtr proplist;
 + int type = -1;
 +
 + drm_plane = drmModeGetPlane(drmmode-fd,
 + plane_resources-planes[i]);
 + if (drm_plane == NULL)
 + continue;
 +
 + if (!(drm_plane-possible_crtcs  (1  drmmode_crtc-index)))
 + goto free_plane;
 +
 + proplist = drmModeObjectGetProperties(drmmode-fd,
 +   drm_plane-plane_id,
 +   DRM_MODE_OBJECT_PLANE);
 + if (proplist == NULL)
 + goto free_plane;
 +
 + for (j = 0; type == -1  j  proplist-count_props; j++) {
 + drmModePropertyPtr prop;
 +
 + prop = drmModeGetProperty(drmmode-fd, 
 proplist-props[j]);
 + if (!prop)
 + continue;
 +
 + if (strcmp(prop-name, type) == 0)
 + type = proplist-prop_values[j];
 +
 + drmModeFreeProperty(prop);
 + }
 +
 + if (type == DRM_PLANE_TYPE_PRIMARY) {
 + drmmode_crtc-primary_plane_id = drm_plane-plane_id;
 +
 + for (j = 0; drmmode_crtc-rotation_prop_id == 0  j  
 proplist-count_props; j++) {
 + drmModePropertyPtr prop;
 +
 + prop = drmModeGetProperty(drmmode-fd, 
 proplist-props[j]);
 + if (!prop)
 + continue;
 +
 + if (strcmp(prop-name, rotation) == 0) {
 + drmmode_crtc-rotation_prop_id = 
 proplist-props[j];
 + drmmode_crtc-current_rotation = 
 proplist-prop_values[j];
 + for (k = 0; k  prop-count_enums; k++) 
 {
 + int rr = -1;
 + if (strcmp(prop-enums[k].name, 
 rotate-0) == 0)
 + rr = RR_Rotate_0;

Re: [PATCH] modesetting: Support native primary plane rotation

2014-07-09 Thread Pekka Paalanen 
On Wed,  9 Jul 2014 08:00:21 +0100
Chris Wilson ch...@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 ch...@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?


Thanks,
pq


 +static void
 +rotation_init(xf86CrtcPtr crtc)
 +{
 + drmmode_crtc_private_ptr drmmode_crtc = crtc-driver_private;
 + drmmode_ptr drmmode = drmmode_crtc-drmmode;
 + drmModePlaneRes *plane_resources;
 + int i, j, k;
 +
 + drmSetClientCap(drmmode-fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
 +
 + plane_resources = drmModeGetPlaneResources(drmmode-fd);
 + if (plane_resources == NULL)
 + return;
 +
 + for (i = 0; i  plane_resources-count_planes; i++) {
 + drmModePlane *drm_plane;
 + drmModeObjectPropertiesPtr proplist;
 + int type = -1;
 +
 + drm_plane = drmModeGetPlane(drmmode-fd,
 + plane_resources-planes[i]);
 + if (drm_plane == NULL)
 + continue;
 +
 + if (!(drm_plane-possible_crtcs  (1  drmmode_crtc-index)))
 + goto free_plane;
 +
 + proplist = drmModeObjectGetProperties(drmmode-fd,
 +   drm_plane-plane_id,
 +   DRM_MODE_OBJECT_PLANE);
 + if (proplist == NULL)
 + goto free_plane;
 +
 + for (j = 0; type == -1  j  proplist-count_props; j++) {
 + drmModePropertyPtr prop;
 +
 + prop = drmModeGetProperty(drmmode-fd, 
 proplist-props[j]);
 + if (!prop)
 + continue;
 +
 + if (strcmp(prop-name, type) == 0)
 + type = proplist-prop_values[j];
 +
 + drmModeFreeProperty(prop);
 + }
 +
 + if (type == DRM_PLANE_TYPE_PRIMARY) {
 + drmmode_crtc-primary_plane_id = drm_plane-plane_id;
 +
 + for (j = 0; drmmode_crtc-rotation_prop_id == 0  j  
 proplist-count_props; j++) {
 + drmModePropertyPtr prop;
 +
 + prop = drmModeGetProperty(drmmode-fd, 
 proplist-props[j]);
 + if (!prop)
 + continue;
 +
 + if (strcmp(prop-name, rotation) == 0) {
 + drmmode_crtc-rotation_prop_id = 
 proplist-props[j];
 + drmmode_crtc-current_rotation = 
 proplist-prop_values[j];
 + for (k = 0; k  prop-count_enums; k++) 
 {
 + int rr = -1;
 + if (strcmp(prop-enums[k].name, 
 rotate-0) == 0)
 + rr = RR_Rotate_0;
 + else if 
 (strcmp(prop-enums[k].name, rotate-90) == 0)
 +

Re: [PATCH] modesetting: Support native primary plane rotation

2014-07-09 Thread 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 ch...@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 ch...@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
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] modesetting: Support native primary plane rotation

2014-07-09 Thread Chris Wilson 
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 one
opencoded define.

v2: Use enum to determine primary plane, suggested by Pekka Paalanen.
Use libobj for replacement ffs(), suggested by walter harms

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Pekka Paalanen ppaala...@gmail.com
Cc: walter harms wha...@bfs.de
---
 configure.ac  |   5 +-
 libobj/ffs.c  |  14 
 src/drmmode_display.c | 216 ++
 src/drmmode_display.h |  10 ++-
 4 files changed, 212 insertions(+), 33 deletions(-)
 create mode 100644 libobj/ffs.c

diff --git a/configure.ac b/configure.ac
index 1c1a36d..1694465 100644
--- a/configure.ac
+++ b/configure.ac
@@ -74,10 +74,13 @@ 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.47])
 PKG_CHECK_MODULES([PCIACCESS], [pciaccess = 0.10])
 AM_CONDITIONAL(DRM, test x$DRM = xyes)
 
+AC_CONFIG_LIBOBJ_DIR(libobj)
+AC_REPLACE_FUNCS(ffs)
+
 PKG_CHECK_MODULES(UDEV, [libudev], [udev=yes], [udev=no])
 if test x$udev = xyes; then
 AC_DEFINE(HAVE_UDEV,1,[Enable udev-based monitor hotplug detection])
diff --git a/libobj/ffs.c b/libobj/ffs.c
new file mode 100644
index 000..2d44dcc
--- /dev/null
+++ b/libobj/ffs.c
@@ -0,0 +1,14 @@
+extern int ffs(unsigned int value);
+
+int ffs(unsigned int value)
+{
+   int bit;
+
+   if (value == 0)
+   return 0;
+
+   bit = 0;
+   while ((value  (1  bit++)) == 0)
+   ;
+   return bit;
+}
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index c533324..e854502 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -56,6 +56,8 @@
 
 #include driver.h
 
+#define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2 /* from libdrm 2.4.55 */
+
 static struct dumb_bo *dumb_bo_create(int fd,
  const unsigned width, const unsigned height,
  const unsigned bpp)
@@ -300,6 +302,132 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode,
 
 #endif
 
+static unsigned
+rotation_index(unsigned rotation)
+{
+   return ffs(rotation) - 1;
+}
+
+static void
+rotation_init(xf86CrtcPtr crtc)
+{
+   drmmode_crtc_private_ptr drmmode_crtc = crtc-driver_private;
+   drmmode_ptr drmmode = drmmode_crtc-drmmode;
+   drmModePlaneRes *plane_resources;
+   int i, j, k;
+
+   drmSetClientCap(drmmode-fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
+
+   plane_resources = drmModeGetPlaneResources(drmmode-fd);
+   if (plane_resources == NULL)
+   return;
+
+   for (i = 0; drmmode_crtc-primary_plane_id == 0  i  
plane_resources-count_planes; i++) {
+   drmModePlane *drm_plane;
+   drmModeObjectPropertiesPtr proplist;
+   int is_primary = -1;
+
+   drm_plane = drmModeGetPlane(drmmode-fd,
+   plane_resources-planes[i]);
+   if (drm_plane == NULL)
+   continue;
+
+   if (!(drm_plane-possible_crtcs  (1  drmmode_crtc-index)))
+   goto free_plane;
+
+   proplist = drmModeObjectGetProperties(drmmode-fd,
+ drm_plane-plane_id,
+ DRM_MODE_OBJECT_PLANE);
+   if (proplist == NULL)
+   goto free_plane;
+
+   for (j = 0; is_primary == -1  j  proplist-count_props; j++) 
{
+   drmModePropertyPtr prop;
+
+   prop = drmModeGetProperty(drmmode-fd, 
proplist-props[j]);
+   if (!prop)
+   continue;
+
+   if (strcmp(prop-name, type) == 0) {
+   for (k = 0; k  prop-count_enums; k++) {
+   if (prop-enums[k].value != 
proplist-prop_values[j])
+   continue;
+
+   is_primary = 
strcmp(prop-enums[k].name, Primary) == 0;
+   break;
+   }
+   }
+
+   drmModeFreeProperty(prop);
+   }
+
+   if (is_primary) {
+   drmmode_crtc-primary_plane_id = drm_plane-plane_id;
+
+   for (j = 0; drmmode_crtc-rotation_prop_id == 0  j  
proplist-count_props; j++) {
+   drmModePropertyPtr prop;
+
+   prop = drmModeGetProperty(drmmode-fd, 
proplist-props[j]);
+   if (!prop)
+   continue;

Re: [PATCH] modesetting: Support native primary plane rotation

2014-07-09 Thread Mark Kettenis 
 Date: Wed, 09 Jul 2014 09:28:31 +0200
 From: walter harms wha...@bfs.de
 
 Am 09.07.2014 09:00, schrieb Chris Wilson:
  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 ch...@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
  +
   static struct dumb_bo *dumb_bo_create(int fd,
const unsigned width, const unsigned height,
const unsigned bpp)
  @@ -300,6 +305,136 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode,
   
   #endif
   
  +static unsigned
  +rotation_index(unsigned rotation)
  +{
  +#if _SVID_SOURCE || _BSD_SOURCE || _POSIX_C_SOURCE = 200809L || 
  _XOPEN_SOURCE = 700
  +   return ffs(rotation) - 1;
  +#else
  +   int i;
  +
  +   for (i = 0; i  32; i++) {
  +   if ((1  i) == rotation)
  +   break;
  +   }
  +
  +   return i;
  +#endif
  +}
 
 
 perhaps it is better to provide an internal ffs for systems that
 lack one ?  than you can use ffs() directly and leave the rest to
 configure.  That would result in a generic HAVE_FFS instead of a
 list of defines like this now.

Seriously though, what system that supports the modesetting interfaces
does actually lack ffs(3)?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] modesetting: Support native primary plane rotation

2014-07-09 Thread Pekka Paalanen 
On Wed,  9 Jul 2014 09:19:08 +0100
Chris Wilson ch...@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 one
 opencoded define.
 
 v2: Use enum to determine primary plane, suggested by Pekka Paalanen.
 Use libobj for replacement ffs(), suggested by walter harms
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Pekka Paalanen ppaala...@gmail.com
 Cc: walter harms wha...@bfs.de

My concerns have been addressed. On a second read, I found another
suspicious thing below.

 ---
  configure.ac  |   5 +-
  libobj/ffs.c  |  14 
  src/drmmode_display.c | 216 
 ++
  src/drmmode_display.h |  10 ++-
  4 files changed, 212 insertions(+), 33 deletions(-)
  create mode 100644 libobj/ffs.c
 
 diff --git a/configure.ac b/configure.ac
 index 1c1a36d..1694465 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -74,10 +74,13 @@ 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.47])
  PKG_CHECK_MODULES([PCIACCESS], [pciaccess = 0.10])
  AM_CONDITIONAL(DRM, test x$DRM = xyes)
  
 +AC_CONFIG_LIBOBJ_DIR(libobj)
 +AC_REPLACE_FUNCS(ffs)
 +
  PKG_CHECK_MODULES(UDEV, [libudev], [udev=yes], [udev=no])
  if test x$udev = xyes; then
  AC_DEFINE(HAVE_UDEV,1,[Enable udev-based monitor hotplug detection])
 diff --git a/libobj/ffs.c b/libobj/ffs.c
 new file mode 100644
 index 000..2d44dcc
 --- /dev/null
 +++ b/libobj/ffs.c
 @@ -0,0 +1,14 @@
 +extern int ffs(unsigned int value);
 +
 +int ffs(unsigned int value)
 +{
 + int bit;
 +
 + if (value == 0)
 + return 0;
 +
 + bit = 0;
 + while ((value  (1  bit++)) == 0)
 + ;
 + return bit;
 +}
 diff --git a/src/drmmode_display.c b/src/drmmode_display.c
 index c533324..e854502 100644
 --- a/src/drmmode_display.c
 +++ b/src/drmmode_display.c
 @@ -56,6 +56,8 @@
  
  #include driver.h
  
 +#define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2 /* from libdrm 2.4.55 */
 +
  static struct dumb_bo *dumb_bo_create(int fd,
 const unsigned width, const unsigned height,
 const unsigned bpp)
 @@ -300,6 +302,132 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode,
  
  #endif
  
 +static unsigned
 +rotation_index(unsigned rotation)
 +{
 + return ffs(rotation) - 1;
 +}
 +
 +static void
 +rotation_init(xf86CrtcPtr crtc)
 +{
 + drmmode_crtc_private_ptr drmmode_crtc = crtc-driver_private;
 + drmmode_ptr drmmode = drmmode_crtc-drmmode;
 + drmModePlaneRes *plane_resources;
 + int i, j, k;
 +
 + drmSetClientCap(drmmode-fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
 +
 + plane_resources = drmModeGetPlaneResources(drmmode-fd);
 + if (plane_resources == NULL)
 + return;
 +
 + for (i = 0; drmmode_crtc-primary_plane_id == 0  i  
 plane_resources-count_planes; i++) {
 + drmModePlane *drm_plane;
 + drmModeObjectPropertiesPtr proplist;
 + int is_primary = -1;
 +
 + drm_plane = drmModeGetPlane(drmmode-fd,
 + plane_resources-planes[i]);
 + if (drm_plane == NULL)
 + continue;
 +
 + if (!(drm_plane-possible_crtcs  (1  drmmode_crtc-index)))
 + goto free_plane;
 +
 + proplist = drmModeObjectGetProperties(drmmode-fd,
 +   drm_plane-plane_id,
 +   DRM_MODE_OBJECT_PLANE);
 + if (proplist == NULL)
 + goto free_plane;
 +
 + for (j = 0; is_primary == -1  j  proplist-count_props; j++) 
 {
 + drmModePropertyPtr prop;
 +
 + prop = drmModeGetProperty(drmmode-fd, 
 proplist-props[j]);
 + if (!prop)
 + continue;
 +
 + if (strcmp(prop-name, type) == 0) {
 + for (k = 0; k  prop-count_enums; k++) {
 + if (prop-enums[k].value != 
 proplist-prop_values[j])
 + continue;
 +
 + is_primary = 
 strcmp(prop-enums[k].name, Primary) == 0;
 + break;
 + }
 + }
 +
 + drmModeFreeProperty(prop);
 + }
 +
 + if (is_primary) {
 + drmmode_crtc-primary_plane_id = drm_plane-plane_id;
 +
 + for (j = 0; drmmode_crtc-rotation_prop_id == 0  j  
 proplist-count_props; j++) {
 +

Re: [PATCH] modesetting: Support native primary plane rotation

2014-07-09 Thread Chris Wilson 
On Wed, Jul 09, 2014 at 12:57:12PM +0300, Pekka Paalanen wrote:
 On Wed,  9 Jul 2014 09:19:08 +0100
 Chris Wilson ch...@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 one
  opencoded define.
  
  v2: Use enum to determine primary plane, suggested by Pekka Paalanen.
  Use libobj for replacement ffs(), suggested by walter harms
  
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Cc: Pekka Paalanen ppaala...@gmail.com
  Cc: walter harms wha...@bfs.de
 
 My concerns have been addressed. On a second read, I found another
 suspicious thing below.
 
  +   if (strcmp(prop-name, rotation) == 0) {
  +   drmmode_crtc-rotation_prop_id = 
  proplist-props[j];
  +   drmmode_crtc-current_rotation = 
  proplist-prop_values[j];
  +   for (k = 0; k  prop-count_enums; k++) 
  {
  +   int rr = -1;
  +   if (strcmp(prop-enums[k].name, 
  rotate-0) == 0)
  +   rr = RR_Rotate_0;
  +   else if 
  (strcmp(prop-enums[k].name, rotate-90) == 0)
  +   rr = RR_Rotate_90;
  +   else if 
  (strcmp(prop-enums[k].name, rotate-180) == 0)
  +   rr = RR_Rotate_180;
  +   else if 
  (strcmp(prop-enums[k].name, rotate-270) == 0)
  +   rr = RR_Rotate_270;
  +   else if 
  (strcmp(prop-enums[k].name, reflect-x) == 0)
  +   rr = RR_Reflect_X;
  +   else if 
  (strcmp(prop-enums[k].name, reflect-y) == 0)
  +   rr = RR_Reflect_Y;
  +   if (rr != -1) {
  +   
  drmmode_crtc-map_rotations[rotation_index(rr)] = 1  prop-enums[k].value;
  +   
  drmmode_crtc-supported_rotations |= rr;
 
 Comparing the above assignments to...
 
  +static Bool
  +rotation_set(xf86CrtcPtr crtc, unsigned rotation)
  +{
  +   drmmode_crtc_private_ptr drmmode_crtc = crtc-driver_private;
  +   drmmode_ptr drmmode = drmmode_crtc-drmmode;
  +
  +   if (drmmode_crtc-current_rotation == rotation)
  +   return TRUE;
  +
  +   if ((drmmode_crtc-supported_rotations  rotation) == 0)
  +   return FALSE;
  +
  +   if (drmModeObjectSetProperty(drmmode-fd,
  +drmmode_crtc-primary_plane_id,
  +DRM_MODE_OBJECT_PLANE,
  +drmmode_crtc-rotation_prop_id,
  +
  drmmode_crtc-map_rotations[rotation_index(rotation)]))
 
 ...the use here, it does not look like you are passing
 prop-enums[k].value here. It is like you are missing ffs() here or
 having a 1 too much in the assignment.

It doesn't take the enum.value but 1  enum.value.
 
 Btw. would it be possible to do e.g. rotate-90 with reflect?

Indeed. That's an issue from only using the first index...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC xf86-video-freedreno] add OutputClass conf

2014-07-09 Thread Thierry Reding 
On Tue, Jul 08, 2014 at 10:01:52AM -0400, Rob Clark wrote:
 This enables the xserver to associate the drm driver name msm to the
 xf86-video-freedreno driver.
 
 Signed-off-by: Rob Clark robdcl...@gmail.com
 ---
 Not sure if anyone has a better suggestion for how to do that videodrv
 abi check in configure.ac.  The problem is, we don't want to install
 the .conf file snippet(s) for older xserver, as it will error out at
 startup complaining about unknown section OutputClass.
 
 If this is the best way, I'll push it and update some of the other
 drivers.  (I assume Thierry already has patches for tegra.)
 
  Makefile.am|  2 +-
  conf/42-freedreno.conf |  5 +
  conf/Makefile.am   | 23 +++
  configure.ac   | 26 ++
  4 files changed, 55 insertions(+), 1 deletion(-)
  create mode 100644 conf/42-freedreno.conf
  create mode 100644 conf/Makefile.am

I came up with the attached patch. It's somewhat longer but I think the
version check becomes safer by using the header files of the server
that's being built against directly. Also it checks against a server
version number rather than a video ABI number. After all this isn't a
feature influenced by a change of video ABI.

Thierry
From d09a629792b3906feb14f785306fdd0c184eb275 Mon Sep 17 00:00:00 2001
From: Thierry Reding tred...@nvidia.com
Date: Wed, 19 Feb 2014 11:32:12 +0100
Subject: [PATCH] Install OutputClass xorg.conf.d snippet

Newer versions of the X server allow matching DDX modules to kernel
drivers using an OutputClass configuration snippet. Install such a
snippet that help autoload this driver when the DRM device's driver
is the Tegra DRM driver.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 Makefile.am| 30 ++
 configure.ac   | 21 +
 opentegra.conf |  5 +
 3 files changed, 56 insertions(+)
 create mode 100644 opentegra.conf

diff --git a/Makefile.am b/Makefile.am
index d184700242c7..2f4eba7e00f8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -22,6 +22,11 @@ ACLOCAL_AMFLAGS = -I m4
 
 SUBDIRS = src man
 
+if HAVE_OUTPUTCLASS
+sysconfig_DATA = \
+	opentegra.conf
+endif
+
 INSTALL:
 	$(INSTALL_CMD)
 
@@ -30,6 +35,31 @@ ChangeLog:
 
 dist-hook: ChangeLog INSTALL
 
+EXTRA_DIST = \
+	opentegra.conf
+
+#
+# This is needed to work around some weird behaviour in make distcheck. What
+# distcheck will try to do is run something like the following:
+#
+#   $ ./configure --prefix=$(distdir)/_inst
+#   $ make install
+#
+# However that will fail to install the opentegra.org file because the path
+# where it is to be installed is retrieved from the xorg-server.pc file's
+# sysconfigdir variable. Unfortunately that already has the ${prefix} value
+# expanded, so make distcheck will effectively try to install this file into
+# /usr/share/X11/xorg.conf.d, which will fail if run as normal user.
+#
+# We outsmart automake by overriding sysconfigdir on the configure command-
+# line, using ${datarootdir} as prefix so that the file ends up installed
+# somewhere below the prefix set by distcheck. Note that it's possible that
+# the path will not be what the X.Org X server was configured with, but the
+# workaround here is only used for sanity checking the distribution tarball
+# anyway, therefore the file will never be used, so the exact location does
+# not matter.
+#
+AM_DISTCHECK_CONFIGURE_FLAGS = sysconfigdir=\$${datarootdir}/X11/xorg.conf.d
 MAINTAINERCLEANFILES = ChangeLog INSTALL
 
 .PHONY: ChangeLog INSTALL
diff --git a/configure.ac b/configure.ac
index a7bd0c0c51a1..518a44c8fd76 100644
--- a/configure.ac
+++ b/configure.ac
@@ -77,6 +77,27 @@ if test x$udev = xyes; then
 	AC_DEFINE(HAVE_UDEV,1,[Enable udev-based monitor hotplug detection])
 fi
 
+AC_MSG_CHECKING([for OutputClass support in the X.Org X server])
+AC_PREPROC_IFELSE(
+	[AC_LANG_PROGRAM([
+		#include xorg/xorg-server.h
+		#include xorg/xorgVersion.h
+	], [
+		#if XORG_VERSION_CURRENT  XORG_VERSION_NUMERIC(1,15,99,904,0)
+		#  error xorg.conf OutputClass support requires 1.15.99.904
+		#endif
+	])], [have_outputclass=yes], [have_outputclass=no])
+AC_MSG_RESULT([$have_outputclass])
+
+if test x$have_outputclass = xyes; then
+	AC_MSG_CHECKING([for X.Org X server sysconfigdir variable])
+	PKG_CHECK_VAR([sysconfigdir], [xorg-server], [sysconfigdir])
+	AC_MSG_RESULT([$sysconfigdir])
+	AC_SUBST([sysconfigdir])
+fi
+
+AM_CONDITIONAL([HAVE_OUTPUTCLASS], [test x$have_outputclass = xyes])
+
 SAVE_CFLAGS=$CFLAGS
 SAVE_LIBS=$LIBS
 CFLAGS=$DRM_CFLAGS
diff --git a/opentegra.conf b/opentegra.conf
new file mode 100644
index ..aa28a99ebbd4
--- /dev/null
+++ b/opentegra.conf
@@ -0,0 +1,5 @@
+Section OutputClass
+Identifier NVIDIA Tegra open-source driver
+MatchDriver tegra
+Driver opentegra
+EndSection
-- 
2.0.1



pgpWo2PPuigE2.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives:

Re: [PATCH libXi 2/2] XIPassiveGrab: Fix completely broken locking in XIGrabTouchBegin

2014-07-09 Thread Jasper St. Pierre 
_XiCheckExtInit already unlocks the display on error. Yes, it's terrible.


On Wed, Jul 9, 2014 at 3:23 AM, walter harms wha...@bfs.de wrote:



 Am 08.07.2014 23:01, schrieb Jasper St. Pierre:
  _XIPassiveGrabDevice calls LockDisplay as the first thing it does. That
  means that it expects the display to be unlocked. XIGrabTouchBegin locks
  the display to check for the XI extension, and then never unlocks it.
  Effectively, this meant that anybody that called XIGrabTouchBegin after
  XInitThreads just got a deadlock.
 
  Cool.
  ---
   src/XIPassiveGrab.c | 1 +
   1 file changed, 1 insertion(+)
 
  diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
  index f3a9924..88f1aff 100644
  --- a/src/XIPassiveGrab.c
  +++ b/src/XIPassiveGrab.c
  @@ -166,6 +166,7 @@ XIGrabTouchBegin(Display *dpy, int deviceid, Window
 grab_window,
   LockDisplay(dpy);
   if (_XiCheckExtInit(dpy, XInput_2_2, extinfo) == -1)
return -1;
  +UnlockDisplay(dpy);
 
   /* FIXME: allow selection of GrabMode for paired devices? */
   return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeTouchBegin, 0,


 I am not an expert on this but you should  unlock the display on error
 also.
 I would do it this way:

 LockDisplay(dpy);
 err=_XiCheckExtInit(dpy, XInput_2_2, extinfo);
 UnlockDisplay(dpy);
 if (err == -1)
 return -1;

 jz'ust my 2 cents
 re,
  wh

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC xf86-video-freedreno] add OutputClass conf

2014-07-09 Thread Julien Cristau 
On Tue, Jul  8, 2014 at 10:01:52 -0400, Rob Clark wrote:

 This enables the xserver to associate the drm driver name msm to the
 xf86-video-freedreno driver.
 
 Signed-off-by: Rob Clark robdcl...@gmail.com
 ---
 Not sure if anyone has a better suggestion for how to do that videodrv
 abi check in configure.ac.  The problem is, we don't want to install
 the .conf file snippet(s) for older xserver, as it will error out at
 startup complaining about unknown section OutputClass.
 
Maybe this:
PKG_CHECK_EXISTS([xorg-server = 1.15.99.904], outputclass=yes, outputclass=no)
?

Also, any reason to install the file in sysconfdir instead of
${datadir}/X11/xorg.conf.d?

Cheers,
Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC xf86-video-freedreno] add OutputClass conf

2014-07-09 Thread Thierry Reding 
On Wed, Jul 09, 2014 at 12:26:24PM +0200, Julien Cristau wrote:
 On Tue, Jul  8, 2014 at 10:01:52 -0400, Rob Clark wrote:
 
  This enables the xserver to associate the drm driver name msm to the
  xf86-video-freedreno driver.
  
  Signed-off-by: Rob Clark robdcl...@gmail.com
  ---
  Not sure if anyone has a better suggestion for how to do that videodrv
  abi check in configure.ac.  The problem is, we don't want to install
  the .conf file snippet(s) for older xserver, as it will error out at
  startup complaining about unknown section OutputClass.
  
 Maybe this:
 PKG_CHECK_EXISTS([xorg-server = 1.15.99.904], outputclass=yes, 
 outputclass=no)
 ?

Hehe, that's a whole lot simpler than the AC_PREPROC_IFELSE snippet that
I came up with. And obvious too.

 Also, any reason to install the file in sysconfdir instead of
 ${datadir}/X11/xorg.conf.d?

It's sysconf*ig*dir, which is in fact ${datarootdir}/X11/xorg.conf.d.

Thierry


pgpNCPzHmWssW.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libXi 2/2] XIPassiveGrab: Fix completely broken locking in XIGrabTouchBegin

2014-07-09 Thread walter harms 


Am 09.07.2014 12:23, schrieb Jasper St. Pierre:
 _XiCheckExtInit already unlocks the display on error. Yes, it's terrible.
 
 

In this case,
it would be better to move the lock/unlock into _XiCheckExtInit.

re,
 wh


 On Wed, Jul 9, 2014 at 3:23 AM, walter harms wha...@bfs.de wrote:
 


 Am 08.07.2014 23:01, schrieb Jasper St. Pierre:
 _XIPassiveGrabDevice calls LockDisplay as the first thing it does. That
 means that it expects the display to be unlocked. XIGrabTouchBegin locks
 the display to check for the XI extension, and then never unlocks it.
 Effectively, this meant that anybody that called XIGrabTouchBegin after
 XInitThreads just got a deadlock.

 Cool.
 ---
  src/XIPassiveGrab.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
 index f3a9924..88f1aff 100644
 --- a/src/XIPassiveGrab.c
 +++ b/src/XIPassiveGrab.c
 @@ -166,6 +166,7 @@ XIGrabTouchBegin(Display *dpy, int deviceid, Window
 grab_window,
  LockDisplay(dpy);
  if (_XiCheckExtInit(dpy, XInput_2_2, extinfo) == -1)
   return -1;
 +UnlockDisplay(dpy);

  /* FIXME: allow selection of GrabMode for paired devices? */
  return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeTouchBegin, 0,


 I am not an expert on this but you should  unlock the display on error
 also.
 I would do it this way:

 LockDisplay(dpy);
 err=_XiCheckExtInit(dpy, XInput_2_2, extinfo);
 UnlockDisplay(dpy);
 if (err == -1)
 return -1;

 jz'ust my 2 cents
 re,
  wh

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel

 
 
 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC xf86-video-freedreno] add OutputClass conf

2014-07-09 Thread Julien Cristau 
On Wed, Jul  9, 2014 at 12:30:36 +0200, Thierry Reding wrote:

 On Wed, Jul 09, 2014 at 12:26:24PM +0200, Julien Cristau wrote:
  Also, any reason to install the file in sysconfdir instead of
  ${datadir}/X11/xorg.conf.d?
 
 It's sysconf*ig*dir, which is in fact ${datarootdir}/X11/xorg.conf.d.
 
Oh.  Must have missed that, thanks :)

Cheers,
Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH][V4][xserver] configure.ac: add option for xshmfence

2014-07-09 Thread Ross Burton 
Hi,

Changes since v3:
- XSHMFENCE variable renamed to LIBXSHMFENCE
- WANT_XSHMFENCE renamed to XSHMFENCE
- DRI3+xshmfence check correctly using XSHMFENCE not HAVE_XSHMFENCE
- Use LIBXSHMFENCE in REQUIRED_LIBS

Ross
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH][V4][xserver] configure.ac: add option for xshmfence

2014-07-09 Thread Ross Burton 
xshmfence is usable outside of DRI3, and is currently autodetected which isn't
good for distributions where deterministic builds are desired.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 configure.ac |   26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/configure.ac b/configure.ac
index c214638..8420d18 100644
--- a/configure.ac
+++ b/configure.ac
@@ -648,6 +648,7 @@ AC_ARG_ENABLE(kdrive-kbd, 
AS_HELP_STRING([--enable-kdrive-kbd], [Build kbd d
 AC_ARG_ENABLE(kdrive-mouse,   AS_HELP_STRING([--enable-kdrive-mouse], [Build 
mouse driver for kdrive (default: auto)]), [KDRIVE_MOUSE=$enableval], 
[KDRIVE_MOUSE=auto])
 AC_ARG_ENABLE(kdrive-evdev,   AS_HELP_STRING([--enable-kdrive-evdev], [Build 
evdev driver for kdrive (default: auto)]), [KDRIVE_EVDEV=$enableval], 
[KDRIVE_EVDEV=auto])
 AC_ARG_ENABLE(libunwind,  AS_HELP_STRING([--enable-libunwind], [Use 
libunwind for backtracing (default: auto)]), [LIBUNWIND=$enableval], 
[LIBUNWIND=auto])
+AC_ARG_ENABLE(xshmfence,  AS_HELP_STRING([--disable-xshmfence], [Disable 
xshmfence (default: auto)]), [XSHMFENCE=$enableval], [XSHMFENCE=auto])
 
 
 dnl chown/chmod to be setuid root as part of build
@@ -787,7 +788,7 @@ DMXPROTO=dmxproto = 2.2.99.1
 VIDMODEPROTO=xf86vidmodeproto = 2.2.99.1
 WINDOWSWMPROTO=windowswmproto
 APPLEWMPROTO=applewmproto = 1.4
-XSHMFENCE=xshmfence = 1.1
+LIBXSHMFENCE=xshmfence = 1.1
 
 dnl Required modules
 XPROTO=xproto = 7.0.26
@@ -1235,20 +1236,23 @@ esac
 
 AM_CONDITIONAL(BUSFAULT, test x$BUSFAULT = xyes)
 
-PKG_CHECK_MODULES([XSHMFENCE], $XSHMFENCE,
- [HAVE_XSHMFENCE=yes], [HAVE_XSHMFENCE=no])
 
-AM_CONDITIONAL(XSHMFENCE, test x$HAVE_XSHMFENCE = xyes)
+PKG_CHECK_MODULES([XSHMFENCE], $LIBXSHMFENCE, [HAVE_XSHMFENCE=yes], 
[HAVE_XSHMFENCE=no])
+if test x$XSHMFENCE = xauto; then
+XSHMFENCE=$HAVE_XSHMFENCE
+fi
 
-case x$HAVE_XSHMFENCE in
-   xyes)
-   AC_DEFINE(HAVE_XSHMFENCE, 1, [Have X Shared Memory Fence 
library])
-   REQUIRED_LIBS=$REQUIRED_LIBS xshmfence
-   ;;
-esac
+if test x$XSHMFENCE = xyes; then
+if test x$HAVE_XSHMFENCE != xyes; then
+AC_MSG_ERROR([xshmfence requested but not installed.])
+fi
+AC_DEFINE(HAVE_XSHMFENCE, 1, [Have xshmfence support])
+REQUIRED_LIBS=$REQUIRED_LIBS $LIBXSHMFENCE
+fi
 
+AM_CONDITIONAL(XSHMFENCE, [test x$XSHMFENCE = xyes])
 
-case $DRI3,$HAVE_XSHMFENCE in
+case $DRI3,$XSHMFENCE in
yes,yes | auto,yes)
;;
yes,no)
-- 
1.7.10.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libXi 2/2] XIPassiveGrab: Fix completely broken locking in XIGrabTouchBegin

2014-07-09 Thread Jasper St. Pierre 
But all the other existing code that uses _XiCheckExtInit expects it to
unlock on error, but not on success. Peter wrote this code, though, so I'll
let him have the final say.


On Wed, Jul 9, 2014 at 6:31 AM, walter harms wha...@bfs.de wrote:



 Am 09.07.2014 12:23, schrieb Jasper St. Pierre:
  _XiCheckExtInit already unlocks the display on error. Yes, it's terrible.
 
 

 In this case,
 it would be better to move the lock/unlock into _XiCheckExtInit.

 re,
  wh


  On Wed, Jul 9, 2014 at 3:23 AM, walter harms wha...@bfs.de wrote:
 
 
 
  Am 08.07.2014 23:01, schrieb Jasper St. Pierre:
  _XIPassiveGrabDevice calls LockDisplay as the first thing it does. That
  means that it expects the display to be unlocked. XIGrabTouchBegin
 locks
  the display to check for the XI extension, and then never unlocks it.
  Effectively, this meant that anybody that called XIGrabTouchBegin after
  XInitThreads just got a deadlock.
 
  Cool.
  ---
   src/XIPassiveGrab.c | 1 +
   1 file changed, 1 insertion(+)
 
  diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
  index f3a9924..88f1aff 100644
  --- a/src/XIPassiveGrab.c
  +++ b/src/XIPassiveGrab.c
  @@ -166,6 +166,7 @@ XIGrabTouchBegin(Display *dpy, int deviceid, Window
  grab_window,
   LockDisplay(dpy);
   if (_XiCheckExtInit(dpy, XInput_2_2, extinfo) == -1)
return -1;
  +UnlockDisplay(dpy);
 
   /* FIXME: allow selection of GrabMode for paired devices? */
   return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeTouchBegin,
 0,
 
 
  I am not an expert on this but you should  unlock the display on error
  also.
  I would do it this way:
 
  LockDisplay(dpy);
  err=_XiCheckExtInit(dpy, XInput_2_2, extinfo);
  UnlockDisplay(dpy);
  if (err == -1)
  return -1;
 
  jz'ust my 2 cents
  re,
   wh
 
  ___
  xorg-devel@lists.x.org: X.Org development
  Archives: http://lists.x.org/archives/xorg-devel
  Info: http://lists.x.org/mailman/listinfo/xorg-devel
 
 
 
 




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC xf86-video-freedreno] add OutputClass conf

2014-07-09 Thread Rob Clark 
On Wed, Jul 9, 2014 at 6:26 AM, Julien Cristau jcris...@debian.org wrote:
 On Tue, Jul  8, 2014 at 10:01:52 -0400, Rob Clark wrote:

 This enables the xserver to associate the drm driver name msm to the
 xf86-video-freedreno driver.

 Signed-off-by: Rob Clark robdcl...@gmail.com
 ---
 Not sure if anyone has a better suggestion for how to do that videodrv
 abi check in configure.ac.  The problem is, we don't want to install
 the .conf file snippet(s) for older xserver, as it will error out at
 startup complaining about unknown section OutputClass.

 Maybe this:
 PKG_CHECK_EXISTS([xorg-server = 1.15.99.904], outputclass=yes, 
 outputclass=no)
 ?

oh, heh, yeah that is easier


 Also, any reason to install the file in sysconfdir instead of
 ${datadir}/X11/xorg.conf.d?

Well, it is at least the same thing that glamor does.  Seems like for
fedora build at least, it ends up as /usr/share/X11/xorg.conf.d which
looks like the right spot.

BR,
-R

 Cheers,
 Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH:libX11 2/2] Fix validation of ctrls parameter to XkbGetPerClientControls()

2014-07-09 Thread Alan Coopersmith 
Nothing in the XKB spec states that the memory pointed to by ctrls has to
be initialized to any given value when passed to the function, only that
it is set by the function to the values returned by the X server:
http://www.x.org/releases/X11R7.7/doc/libX11/XKB/xkblib.html#The_Miscellaneous_Per_client_Controls

The check for the incoming value seems to be copied from
XkbSetPerClientControls without explanation.

Instead change it to checking if ctrls is non-NULL, since there's no
point asking the X server to return a value the caller won't even see.

Found while investigating report from cppcheck-1.65:
[src/xkb/XKB.c:699] - [src/xkb/XKB.c:719]: (warning) Possible null pointer
 dereference: ctrls - otherwise it is redundant to check it against null.

Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
 src/xkb/XKB.c |   11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/src/xkb/XKB.c b/src/xkb/XKB.c
index 6413ba2..03a89d0 100644
--- a/src/xkb/XKB.c
+++ b/src/xkb/XKB.c
@@ -696,9 +696,7 @@ XkbGetPerClientControls(Display *dpy, unsigned *ctrls)
 
 if ((dpy-flags  XlibDisplayNoXkb) ||
 (!dpy-xkb_info  !XkbUseExtension(dpy, NULL, NULL)) ||
-(*ctrls  ~(XkbPCF_GrabsUseXKBStateMask |
-XkbPCF_LookupStateWhenGrabbed |
-XkbPCF_SendEventUsesXKBState)))
+(ctrls == NULL))
 return False;
 LockDisplay(dpy);
 xkbi = dpy-xkb_info;
@@ -716,10 +714,9 @@ XkbGetPerClientControls(Display *dpy, unsigned *ctrls)
 }
 UnlockDisplay(dpy);
 SyncHandle();
-if (ctrls)
-*ctrls = (rep.value  (XkbPCF_GrabsUseXKBStateMask |
-   XkbPCF_LookupStateWhenGrabbed |
-   XkbPCF_SendEventUsesXKBState));
+*ctrls = (rep.value  (XkbPCF_GrabsUseXKBStateMask |
+   XkbPCF_LookupStateWhenGrabbed |
+   XkbPCF_SendEventUsesXKBState));
 return (True);
 }
 
-- 
1.7.9.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH:libX11 1/2] Fix map-num_types check in XkbAddKeyType()

2014-07-09 Thread Alan Coopersmith 
Check is intended to ensure we allocate at least XkbNumRequiredTypes
in map, but was accidentally marked with a ! causing the wrong check.

Reported-by: Harms wharms@bfs,de
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
 src/xkb/XKBMAlloc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/xkb/XKBMAlloc.c b/src/xkb/XKBMAlloc.c
index 0b86aa1..2e39634 100644
--- a/src/xkb/XKBMAlloc.c
+++ b/src/xkb/XKBMAlloc.c
@@ -300,7 +300,7 @@ XkbAddKeyType(XkbDescPtr xkb,
 }
 }
 }
-if ((!map) || (!map-types) || (!map-num_types  XkbNumRequiredTypes)) {
+if ((!map) || (!map-types) || (map-num_types  XkbNumRequiredTypes)) {
 tmp = XkbNumRequiredTypes + 1;
 if (XkbAllocClientMap(xkb, XkbKeyTypesMask, tmp) != Success)
 return NULL;
-- 
1.7.9.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH][V4][xserver] configure.ac: add option for xshmfence

2014-07-09 Thread Matt Turner 
Reviewed-by: Matt Turner matts...@gmail.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libXi 2/2] XIPassiveGrab: Fix completely broken locking in XIGrabTouchBegin

2014-07-09 Thread Peter Hutterer 
On Wed, Jul 09, 2014 at 06:45:06AM -0400, Jasper St. Pierre wrote:
 But all the other existing code that uses _XiCheckExtInit expects it to
 unlock on error, but not on success. Peter wrote this code, though, so I'll
 let him have the final say.

yeah, if someone wants to fix this on a global scale  (requires XI 1.x code
as well iirc) be my guest, but for now we just go with what we have.

both pushed, thanks.

Cheers,
   Peter

 
 
 On Wed, Jul 9, 2014 at 6:31 AM, walter harms wha...@bfs.de wrote:
 
 
 
  Am 09.07.2014 12:23, schrieb Jasper St. Pierre:
   _XiCheckExtInit already unlocks the display on error. Yes, it's terrible.
  
  
 
  In this case,
  it would be better to move the lock/unlock into _XiCheckExtInit.
 
  re,
   wh
 
 
   On Wed, Jul 9, 2014 at 3:23 AM, walter harms wha...@bfs.de wrote:
  
  
  
   Am 08.07.2014 23:01, schrieb Jasper St. Pierre:
   _XIPassiveGrabDevice calls LockDisplay as the first thing it does. That
   means that it expects the display to be unlocked. XIGrabTouchBegin
  locks
   the display to check for the XI extension, and then never unlocks it.
   Effectively, this meant that anybody that called XIGrabTouchBegin after
   XInitThreads just got a deadlock.
  
   Cool.
   ---
src/XIPassiveGrab.c | 1 +
1 file changed, 1 insertion(+)
  
   diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
   index f3a9924..88f1aff 100644
   --- a/src/XIPassiveGrab.c
   +++ b/src/XIPassiveGrab.c
   @@ -166,6 +166,7 @@ XIGrabTouchBegin(Display *dpy, int deviceid, Window
   grab_window,
LockDisplay(dpy);
if (_XiCheckExtInit(dpy, XInput_2_2, extinfo) == -1)
 return -1;
   +UnlockDisplay(dpy);
  
/* FIXME: allow selection of GrabMode for paired devices? */
return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeTouchBegin,
  0,
  
  
   I am not an expert on this but you should  unlock the display on error
   also.
   I would do it this way:
  
   LockDisplay(dpy);
   err=_XiCheckExtInit(dpy, XInput_2_2, extinfo);
   UnlockDisplay(dpy);
   if (err == -1)
   return -1;
  
   jz'ust my 2 cents
   re,
wh
  
   ___
   xorg-devel@lists.x.org: X.Org development
   Archives: http://lists.x.org/archives/xorg-devel
   Info: http://lists.x.org/mailman/listinfo/xorg-devel
  
  
  
  
 
 
 
 
 -- 
   Jasper

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Revert glamor: Fix coordinates handling for composite source/mask pictures

2014-07-09 Thread Michel Dänzer 
On 24.06.2014 16:09, Michel Dänzer wrote:
 
 This reverts commit 4e9aabb6fc15d8052934f20c6a07801c197ec36a.
 
 It broke kwin decorations with XRender compositing.

After several complaints about this revert from users of other DEs
(because it broke their systray icons again), I tried to reproduce the
kwin problem shown on
http://markus.members.selfnet.de/xorg/glamor_kwin.png without the revert
again, but couldn't. Markus, can you still reproduce this problem
without the revert? If yes, please provide detailed instructions to
reproduce. If not, it was probably fixed by something else in the meantime.


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:libX11 1/2] Fix map-num_types check in XkbAddKeyType()

2014-07-09 Thread Matthieu Herrb 

On 07/09/2014 10:34 PM, Alan Coopersmith wrote:

Check is intended to ensure we allocate at least XkbNumRequiredTypes
in map, but was accidentally marked with a ! causing the wrong check.

Reported-by: Harms wharms@bfs,de
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com


Reviewed-by: Matthieu Herrb matth...@herrb.eu


---
  src/xkb/XKBMAlloc.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/xkb/XKBMAlloc.c b/src/xkb/XKBMAlloc.c
index 0b86aa1..2e39634 100644
--- a/src/xkb/XKBMAlloc.c
+++ b/src/xkb/XKBMAlloc.c
@@ -300,7 +300,7 @@ XkbAddKeyType(XkbDescPtr xkb,
  }
  }
  }
-if ((!map) || (!map-types) || (!map-num_types  XkbNumRequiredTypes)) {
+if ((!map) || (!map-types) || (map-num_types  XkbNumRequiredTypes)) {
  tmp = XkbNumRequiredTypes + 1;
  if (XkbAllocClientMap(xkb, XkbKeyTypesMask, tmp) != Success)
  return NULL;



___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel