[PATCH:xf86-video-mga] Fix pointer cast warning.

2015-02-23 Thread Thomas Klausner 
cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

Signed-off-by: Thomas Klausner w...@netbsd.org
---
 src/mga_exa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mga_exa.c b/src/mga_exa.c
index 69ffa16..5024f54 100644
--- a/src/mga_exa.c
+++ b/src/mga_exa.c
@@ -729,7 +729,7 @@ mgaDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, 
int h,
 {
 PMGA(pSrc);
 
-char *src = (char *) exaGetPixmapFirstPixel(pSrc);
+char *src = (char *)(unsigned long) exaGetPixmapFirstPixel(pSrc);
 int src_pitch = exaGetPixmapPitch(pSrc);
 
 int cpp = (pSrc-drawable.bitsPerPixel + 7) / 8;
-- 
2.3.0

___
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:xf86-video-mga 2/2] Use correct type in function call.

2015-02-23 Thread Thomas Klausner 
Fixes
passing argument 2 of 'pci_device_cfg_read_u32' from incompatible pointer type
pciaccess.h:153:5: note: expected '__uint32_t *' but argument is of type 
'CARD32 *'

Signed-off-by: Thomas Klausner w...@netbsd.org
---
 src/mga_dac3026.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/mga_dac3026.c b/src/mga_dac3026.c
index 97c2c7a..e825702 100644
--- a/src/mga_dac3026.c
+++ b/src/mga_dac3026.c
@@ -852,8 +852,12 @@ MGA3026Save(ScrnInfoPtr pScrn, vgaRegPtr vgaReg, MGARegPtr 
mgaReg,
mgaReg-DacRegs[i]   = inTi3026(MGADACregs[i]);

 #ifdef XSERVER_LIBPCIACCESS
-   pci_device_cfg_read_u32(pMga-PciInfo,  mgaReg-Option, 
+{
+   uint32_t Option;
+   pci_device_cfg_read_u32(pMga-PciInfo,  Option, 
PCI_OPTION_REG);
+mgaReg-Option = Option;
+}
 #else
mgaReg-Option = pciReadLong(pMga-PciTag, PCI_OPTION_REG);
 #endif
-- 
2.3.0

___
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] dri2: work around broken DRI2CreateDrawable callers

2015-02-23 Thread Daniel Drake 
Hi Chris,

On Sat, Feb 21, 2015 at 11:55 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 I recently came across something very similar because it affects mesa
 also. The problem is that we do want to track a reference per Client, so
 simply creating a single reference seems fraught with danger. For mesa,
 I thought using a named reference, i.e. passing the dri2_id from the
 Client to use for the reference, and then destroying that reference
 along with mesa's glXDrawable, actually fixes a few bugs in
 mesa/src/glx/dri2_glx.c

 Did you find an alternative solution for mali? If not, I think I can
 generalise this into only allocating a single reference per DRI2 Client
 per Drawable.

Thanks for looking into this! I'm attaching an updated version of the
workaround; I found a problem with the first one, but I can't recall
exactly what happened. Also, the latest version of Mali (almost) fixes
this issue.

Anyway, fixing this properly does sound like a good idea. You
mentioned GLX though - would that also solve the issue in the case
where EGL is used instead of GLX?

Thanks
Daniel
https://github.com/endlessm/eos-hw-enablement/issues/3

From 2ccbff37be778e2c13dc26fa6cd0f6ecd6f227c3 Mon Sep 17 00:00:00 2001
From: Daniel Drake dr...@endlessm.com
Date: Fri, 7 Feb 2014 08:29:38 -0600
Subject: [PATCH] dri2: work around broken DRI2CreateDrawable callers

The state of the DRI2CreateDrawable request is a little unclear.
dri2proto.txt states that it was dropped in version 1.99.2, but
actually this must still be called exactly once for each drawable
before GetBuffers and friends can be called, because it is the only
way that the internal DRI2DrawableRec structure will be allocated.

Mali fails to obey this unwritten rule and instead calls CreateDrawable
before each and every GetBuffers request. That causes a new dri2_id and
internal reference to be created every time. When we then come to
invalidate the drawable after GetBuffers+SwapBuffers for frame N, we end
up generating N invalidate events from DRI2InvalidateDrawable. Things
quickly get out of hand.

Fix this by detecting the fact that we're being called from
the DRI2CreateDrawable request context (i.e. caller does not get to
learn about the assigned dri2_id). In that case, just ensure that
we have allocated the relevant internal DRI2 private data, and return.

Signed-off-by: Daniel Drake dr...@endlessm.com
---
 hw/xfree86/dri2/dri2.c | 7 +++
 1 file changed, 7 insertions(+)

Index: xorg-server-1.13.3/hw/xfree86/dri2/dri2.c
===
--- xorg-server-1.13.3.orig/hw/xfree86/dri2/dri2.c	2014-02-25 10:37:59.002464709 -0600
+++ xorg-server-1.13.3/hw/xfree86/dri2/dri2.c	2014-02-25 11:38:29.229158820 -0600
@@ -101,6 +101,7 @@
 int swap_limit; /* for N-buffering */
 unsigned long serialNumber;
 Bool needInvalidate;
+Bool client_created;
 int prime_id;
 PixmapPtr prime_slave_pixmap;
 PixmapPtr redirectpixmap;
@@ -215,6 +216,7 @@
 if (pPriv == NULL)
 return NULL;
 
+pPriv-client_created = FALSE;
 pPriv-dri2_screen = ds;
 pPriv-drawable = pDraw;
 pPriv-width = pDraw-width;
@@ -343,6 +345,15 @@
 int rc;
 
 pPriv = DRI2GetDrawable(pDraw);
+if (pPriv  dri2_id_out == NULL  pPriv-client_created) {
+/* We already allocated a DRI2Drawable for this drawable, the client
+ * has called into this function (so will receive invalidate events)
+ * and now we're being called by the client again (we know this because
+ * the caller doesn't care about the dri2_id). This means we don't need
+ * to allocate another one, we have nothing else to do. */
+pPriv-prime_id = dri2_client-prime_id;
+return Success;
+}
 if (pPriv == NULL)
 pPriv = DRI2AllocateDrawable(pDraw);
 if (pPriv == NULL)
@@ -357,6 +368,11 @@
 
 if (dri2_id_out)
 *dri2_id_out = dri2_id;
+else {
+/* The client has called in for the first time, it will now receive
+ * invalidate events. Record this for later. */
+pPriv-client_created = TRUE;
+}
 
 return Success;
 }
___
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] xwayland-input: Remove our XYToWindow handler

2015-02-23 Thread Daniel Stone 
On 21 February 2015 at 19:53, Jasper St. Pierre jstpie...@mecheye.net wrote:
 This was built as a hack for simple Wayland compositors like Weston
 which were lazy and didn't want to configure windows server-side when
 moved.

 Since comboboxes and menus are separate toplevel O-R windows, this hack
 breaks input as it needs to be traced normally, not simply sent to the
 focused window.

 X11 toolkits really do need their windows to be configured correctly
 for their O-R windows comboboxes or menus other things, so let's fix
 the lazy compositors and remove this.

 I have tested this patch with both Weston and Mutter and neither of
 them require any changes, and it fixes comboboxes and menus.

 If somebody then wants to revert 73698d4, that's fine by me, so we
 reduce the amount of API that DDXen have.

 Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net

Acked-by: Daniel Stone dani...@collabora.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] xwayland-input: Remove our XYToWindow handler

2015-02-23 Thread Olivier Fourdan 

On 21/02/15 20:53, Jasper St. Pierre wrote:

This was built as a hack for simple Wayland compositors like Weston
which were lazy and didn't want to configure windows server-side when
moved.

Since comboboxes and menus are separate toplevel O-R windows, this hack
breaks input as it needs to be traced normally, not simply sent to the
focused window.

X11 toolkits really do need their windows to be configured correctly
for their O-R windows comboboxes or menus other things, so let's fix
the lazy compositors and remove this.

I have tested this patch with both Weston and Mutter and neither of
them require any changes, and it fixes comboboxes and menus.

If somebody then wants to revert 73698d4, that's fine by me, so we
reduce the amount of API that DDXen have.

Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
---


That one works for me, the problem I had with the previous patch was 
precisely that it did not need coordinates translations.


Cheers,
Olivier
___
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:xf86-video-mga] Fix pointer cast warning.

2015-02-23 Thread Matt Turner 
On Mon, Feb 23, 2015 at 2:39 AM, Thomas Klausner w...@netbsd.org wrote:
 cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

 Signed-off-by: Thomas Klausner w...@netbsd.org
 ---
  src/mga_exa.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/mga_exa.c b/src/mga_exa.c
 index 69ffa16..5024f54 100644
 --- a/src/mga_exa.c
 +++ b/src/mga_exa.c
 @@ -729,7 +729,7 @@ mgaDownloadFromScreen(PixmapPtr pSrc, int x, int y, int 
 w, int h,
  {
  PMGA(pSrc);

 -char *src = (char *) exaGetPixmapFirstPixel(pSrc);
 +char *src = (char *)(unsigned long) exaGetPixmapFirstPixel(pSrc);

Use u/intptr_t. From there, I don't remember if the explicit char*
cast is necessary.
___
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:xf86-video-mga 2/2] Use correct type in function call.

2015-02-23 Thread Matt Turner 
On Mon, Feb 23, 2015 at 4:28 AM, Thomas Klausner w...@netbsd.org wrote:
 Fixes
 passing argument 2 of 'pci_device_cfg_read_u32' from incompatible pointer type
 pciaccess.h:153:5: note: expected '__uint32_t *' but argument is of type 
 'CARD32 *'

 Signed-off-by: Thomas Klausner w...@netbsd.org
 ---
  src/mga_dac3026.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/src/mga_dac3026.c b/src/mga_dac3026.c
 index 97c2c7a..e825702 100644
 --- a/src/mga_dac3026.c
 +++ b/src/mga_dac3026.c
 @@ -852,8 +852,12 @@ MGA3026Save(ScrnInfoPtr pScrn, vgaRegPtr vgaReg, 
 MGARegPtr mgaReg,
 mgaReg-DacRegs[i]   = inTi3026(MGADACregs[i]);

  #ifdef XSERVER_LIBPCIACCESS
 -   pci_device_cfg_read_u32(pMga-PciInfo,  mgaReg-Option,
 +{
 +   uint32_t Option;
 +   pci_device_cfg_read_u32(pMga-PciInfo,  Option,
 PCI_OPTION_REG);
 +mgaReg-Option = Option;

I don't understand why the previous code generated that warning (isn't
__uint32_t* implicitly castable to CARD32*?) but even so, why isn't a
cast the appropriate solution?
___
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] glamor: Fix up indentation

2015-02-23 Thread Adam Jackson 
Signed-off-by: Adam Jackson a...@redhat.com
---
 glamor/glamor_largepixmap.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/glamor/glamor_largepixmap.c b/glamor/glamor_largepixmap.c
index 9b24584..88ea899 100644
--- a/glamor/glamor_largepixmap.c
+++ b/glamor/glamor_largepixmap.c
@@ -920,10 +920,10 @@ glamor_get_transform_block_size(struct pixman_transform 
*transform,
 return TRUE;
 }
 
-#define VECTOR_FROM_POINT(p, x, y) \
+#define VECTOR_FROM_POINT(p, x, y) do {\
p.v[0] = x;  \
p.v[1] = y;  \
-   p.v[2] = 1.0;
+   p.v[2] = 1.0; } while (0)
 void
 glamor_get_transform_extent_from_box(struct pixman_box32 *box,
  struct pixman_transform *transform)
@@ -933,12 +933,12 @@ glamor_get_transform_extent_from_box(struct pixman_box32 
*box,
 
 struct pixman_f_transform ftransform;
 
-VECTOR_FROM_POINT(p0, box-x1, box-y1)
-VECTOR_FROM_POINT(p1, box-x2, box-y1)
-VECTOR_FROM_POINT(p2, box-x2, box-y2)
-VECTOR_FROM_POINT(p3, box-x1, box-y2)
+VECTOR_FROM_POINT(p0, box-x1, box-y1);
+VECTOR_FROM_POINT(p1, box-x2, box-y1);
+VECTOR_FROM_POINT(p2, box-x2, box-y2);
+VECTOR_FROM_POINT(p3, box-x1, box-y2);
 
-pixman_f_transform_from_pixman_transform(ftransform, transform);
+pixman_f_transform_from_pixman_transform(ftransform, transform);
 pixman_f_transform_point(ftransform, p0);
 pixman_f_transform_point(ftransform, p1);
 pixman_f_transform_point(ftransform, p2);
-- 
1.9.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

[PATCH libpciaccess 1/2] vgaarb: add a the trailing NULL character on read(vgaarb_fd)

2015-02-23 Thread Emil Velikov 
From: arsharma ankitprasad.r.sha...@intel.com

Issue was spotted by Klocwork, and fixed by arsharma as part of
Android-ia. Not 100% sure if the data read from /dev/vga_arbiter is not
already null terminated, but making sure won't hurt either.

[Emil Velikov: Split from larger patch, write commit message]
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
 src/common_vgaarb.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/common_vgaarb.c b/src/common_vgaarb.c
index 7a7d204..515275f 100644
--- a/src/common_vgaarb.c
+++ b/src/common_vgaarb.c
@@ -126,7 +126,7 @@ int
 pci_device_vgaarb_init(void)
 {
 struct pci_slot_match match;
-char buf[BUFSIZE];
+char buf[BUFSIZE + 1]; /* reading BUFSIZE characters, + 1 for NULL */
 int ret, rsrc;
 
 if (!pci_sys)
@@ -140,6 +140,8 @@ pci_device_vgaarb_init(void)
 if (ret = 0)
 return -1;
 
+buf[ret] = 0; /* ret will never be greater than BUFSIZE */
+
 memset(match, 0xff, sizeof(match));
 /* need to find the device to go back to and what it was decoding */
 rsrc = parse_string_to_decodes_rsrc(buf, pci_sys-vga_count, match);
@@ -226,7 +228,7 @@ int
 pci_device_vgaarb_set_target(struct pci_device *dev)
 {
 int len;
-char buf[BUFSIZE];
+char buf[BUFSIZE + 1]; /* reading BUFSIZE characters, + 1 for NULL */
 int ret;
 
 if (!dev)
@@ -245,6 +247,8 @@ pci_device_vgaarb_set_target(struct pci_device *dev)
 if (ret = 0)
 return -1;
 
+buf[ret] = 0; /* ret will never be greater than BUFSIZE */
+
 dev-vgaarb_rsrc = parse_string_to_decodes_rsrc(buf, pci_sys-vga_count, 
NULL);
 pci_sys-vga_target = dev;
 return 0;
@@ -254,7 +258,7 @@ int
 pci_device_vgaarb_decodes(int new_vgaarb_rsrc)
 {
 int len;
-char buf[BUFSIZE];
+char buf[BUFSIZE + 1]; /* reading BUFSIZE characters, + 1 for NULL */
 int ret;
 struct pci_device *dev = pci_sys-vga_target;
 
@@ -272,6 +276,8 @@ pci_device_vgaarb_decodes(int new_vgaarb_rsrc)
 if (ret = 0)
 return -1;
 
+buf[ret] = 0; /* ret will never be greater than BUFSIZE */
+
 parse_string_to_decodes_rsrc(buf, pci_sys-vga_count, NULL);
 
 return ret;
-- 
2.3.0

___
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

XDrawString issues with long strings

2015-02-23 Thread Matthieu Herrb 
Hi,

The program below demonstrates an issue with XDrawString. It's not very
clear to me how it should behave if the string that is passed is too
long (the man page does not specify it explicitely) but currently
there are odd things happending.

With an argument of 27 it will trigger an assertion in xcb_io.c:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has
not been called
[xcb] Aborting, sorry about that.
assertion !xcb_xlib_threads_sequence_lost failed: file
/usr/xenocara/lib/libX11/src/xcb_io.c, line 274, function
poll_for_event
Abort (core dumped)

With other large values it will trigger a BadLength X Error, but i)
it's not documented that this error can be thrown, ii) from reading
the code I think it's somehow by magic, it's not an intended
behaviour.

With Datalength values greater than 262144, the req-length computation in
Xlib/src/Text.c will overflow, since it's a 16bit value...

#include X11/Xlib.h
#include X11/Xutil.h

#include err.h
#include stdio.h
#include stdlib.h
#include string.h

Window
initWindow(Display *display, int xSize, int ySize, GC *gc)
{
Window w;
u_long attributeMask;
XSetWindowAttributes attribute;
XGCValues gc_val;
int screen = DefaultScreen(display);

attribute.background_pixel = WhitePixel(display, screen);
attribute.border_pixel = WhitePixel(display, screen);
attribute.bit_gravity = NorthWestGravity;
attribute.event_mask = KeyPressMask| ExposureMask;
attributeMask = CWBorderPixel | CWBackPixel
| CWEventMask | CWBitGravity;

w = XCreateWindow(display, RootWindow(display, screen),
0, 0, xSize, ySize, 0, DefaultDepth(display, screen), InputOutput,
XDefaultVisual(display, screen), attributeMask, attribute);

gc_val.foreground = BlackPixel(display, screen);
gc_val.background = WhitePixel(display, screen);
*gc = XCreateGC (display, w, GCForeground|GCBackground, gc_val);

/* map the image window */
XMapWindow(display, w);

return(w);
}
int
eventLoop(Display *display, Window window, GC gc, char *string, size_t n)
{
XEvent event;
int i;
char c;

while (1) {
XNextEvent(display, event);
switch(event.type) {
case KeyPress:
i = XLookupString(event.xkey, c, 1, NULL, NULL);
if ((i == 1)  ((c == 'q') || (c == 'Q')
|| (c == '\03'))) {
XCloseDisplay(display);
exit(0);
}
break;
case Expose:
XDrawString(display, window, gc, 5, 50,
   string, n);
break;
}
}
}


int
main(int argc, char *argv[])
{
Display *d;
Window w;
GC gc;
size_t n;
char *string;

if (argc == 2)
n = atoi(argv[1]);
else
n = 10;
printf(testing for %ld\n, n);
if ((string = malloc(n)) == NULL)
err(2, can't malloc string);
memset(string, 'A', n - 1);
string[n-1] = '\0';

if ((d = XOpenDisplay(NULL)) == NULL)
errx(2, Can't open display);
w = initWindow(d, 1000, 100, gc);
eventLoop(d, w, gc, string, n - 1);
return 0;
}

-- 
Matthieu Herrb
___
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:xf86-video-mga] Fix pointer cast warning.

2015-02-23 Thread Matthieu Herrb 
On Tue, Feb 24, 2015 at 08:16:33AM +0100, Mark Kettenis wrote:
  Date: Mon, 23 Feb 2015 22:55:51 -0800
  From: Alan Coopersmith alan.coopersm...@oracle.com
  
  On 02/23/15 10:36 PM, Mark Kettenis wrote:
 cast to pointer from integer of different size
 [-Werror=int-to-pointer-cast]
  
 Signed-off-by: Thomas Klausner w...@netbsd.org
 ---
  src/mga_exa.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
  
   This code makes no sense to me.  exaGetPixmapFirstPixel() returns a pixel
   value.  Interpreting that as a pointer to the first pixel must be wrong.
  
   Note that the actual usage of mgaDownloadFromScreen() is #if 0'ed out.
  
  Perhaps in your copy, but not upstream:
  
  http://cgit.freedesktop.org/xorg/driver/xf86-video-mga/tree/src/mga_exa.c#n896
 
 He, right.  Mattieu Herrb disabled this locally in OpenBSD's xenocara:
 
   revision 1.7
   date: 2013/06/14 21:21:54;  author: matthieu;  state: Exp;  lines: +2 -0;
   Disable broken EXA operations for now.
 
 Breakage was probably introduced with commit
 e9109a0b04695d6971c94abe271dda2dc1a5e886.  Not sure if simply
 reverting that commit is an option.

Hmm no. My commit to disable some EXA operations was done before
Tormold's one. My guess is that EXA support never got finished on mga
since XAA was the default until it was removed from xserver. Then we
started to use EXA but no one actually tested the drivers on actual
hardware.

There are a few others (mach64, cirrus on the top of my head) that
needed similar surgery. I was hoping that someone with EXA expertise
would figure out the proper fixes so that we could re-enable the
accelerated code at some point. But it's clear almost 2 years later
that this is not going to happen, and that only a handful of people
care about this.
-- 
Matthieu Herrb
___
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:xf86-video-mga] Fix pointer cast warning.

2015-02-23 Thread Mark Kettenis 
 Date: Mon, 23 Feb 2015 22:55:51 -0800
 From: Alan Coopersmith alan.coopersm...@oracle.com
 
 On 02/23/15 10:36 PM, Mark Kettenis wrote:
cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]
 
Signed-off-by: Thomas Klausner w...@netbsd.org
---
 src/mga_exa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
  This code makes no sense to me.  exaGetPixmapFirstPixel() returns a pixel
  value.  Interpreting that as a pointer to the first pixel must be wrong.
 
  Note that the actual usage of mgaDownloadFromScreen() is #if 0'ed out.
 
 Perhaps in your copy, but not upstream:
 
 http://cgit.freedesktop.org/xorg/driver/xf86-video-mga/tree/src/mga_exa.c#n896

He, right.  Mattieu Herrb disabled this locally in OpenBSD's xenocara:

  revision 1.7
  date: 2013/06/14 21:21:54;  author: matthieu;  state: Exp;  lines: +2 -0;
  Disable broken EXA operations for now.

Breakage was probably introduced with commit
e9109a0b04695d6971c94abe271dda2dc1a5e886.  Not sure if simply
reverting that commit is an option.
___
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