Re: [PATCH] configure: Stop using AM_MAINTAINER_MODE

2012-10-02 Thread Julien Cristau
On Sun, Sep 30, 2012 at 16:45:17 -0400, Gaetan Nadon wrote: On 12-09-29 04:37 PM, Dan Nicholson wrote: Some distros may prefer maintainer mode. A way to appease everyone is: AM_MAINTAINER_MODE([enable]) Oh, yeah. That would be the best. The historical background is that mode

Re: [PATCH] configure: Stop using AM_MAINTAINER_MODE

2012-10-02 Thread Dan Nicholson
LOn Oct 2, 2012 1:09 PM, Julien Cristau jcris...@debian.org wrote: On Sun, Sep 30, 2012 at 16:45:17 -0400, Gaetan Nadon wrote: On 12-09-29 04:37 PM, Dan Nicholson wrote: Some distros may prefer maintainer mode. A way to appease everyone is: AM_MAINTAINER_MODE([enable])

Re: [PATCH] configure: Stop using AM_MAINTAINER_MODE

2012-10-02 Thread Gaetan Nadon
On 12-10-02 04:09 PM, Julien Cristau wrote: On Sun, Sep 30, 2012 at 16:45:17 -0400, Gaetan Nadon wrote: On 12-09-29 04:37 PM, Dan Nicholson wrote: Some distros may prefer maintainer mode. A way to appease everyone is: AM_MAINTAINER_MODE([enable]) Oh, yeah. That would be the best. The

splitting drawable and screens

2012-10-02 Thread Dave Airlie
So I've been looking into gpu switching and having all driver screens be GPU screens under a protocol screen. Now the biggest problem I've hit so far is that we all use pDrawable-pScreen to figure out what screen we are, however I'd like to abstract things so that you can get drawables from a

gc funcs and ops at screen level

2012-10-02 Thread Dave Airlie
It seems wierd that we have the GC carrying around a pointer to each of these, when I don't see any evidence we can't just stash one set of ops/funcs per screen. Did we every, do we currently to anyone knowledge modify gc ops or funcs at anything less than a screen level? Dave.

[PATCH] xfree86: add xf86UpdateDesktopDimensions()

2012-10-02 Thread Peter Hutterer
This call is required for external drivers (specifically NVIDIA) that do not share the xfree86 infrastructure to update the desktop dimensions. Without it, the driver would update the ScreenRecs but not update the total dimensions the input code relies on for transformation. This call is a thin

Re: [PATCH 0/3] Make timers even more resistant to signals

2012-10-02 Thread Peter Hutterer
On Fri, Sep 28, 2012 at 01:25:50AM -0700, Keith Packard wrote: Peter Hutterer peter.hutte...@who-t.net writes: Thanks, merged this into my tree. This should fix the remaining issues we're seeing with synaptics. Did you see my comments about this patch? I'm really not excited about

[PATCH xorg-gtest 1/2] Drop compat headers

2012-10-02 Thread Peter Hutterer
These headers were always internal anyway, drop them now that we've had 2 releases with them marked as deprecated. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- include/Makefile.am | 10 +- include/xorg/gtest/evemu/xorg-gtest_device.h | 2 --

[PATCH xorg-gtest 2/2] include: fix doxygen warning

2012-10-02 Thread Peter Hutterer
/home/whot/code/xorg-gtest/include/xorg/gtest/evemu/xorg-gtest-device.h:46: warning: the name `xorg-gtest_device.h' supplied as the argument of the \class, \struct, \union, or \include command is not an input file Signed-off-by: Peter Hutterer peter.hutte...@who-t.net ---

Re: gc funcs and ops at screen level

2012-10-02 Thread Aaron Plattner
On 10/02/2012 05:45 PM, Dave Airlie wrote: It seems wierd that we have the GC carrying around a pointer to each of these, when I don't see any evidence we can't just stash one set of ops/funcs per screen. Did we every, do we currently to anyone knowledge modify gc ops or funcs at anything less

Re: [PATCH] xfree86: add xf86UpdateDesktopDimensions()

2012-10-02 Thread Aaron Plattner
On 10/02/2012 08:12 PM, Peter Hutterer wrote: This call is required for external drivers (specifically NVIDIA) that do not share the xfree86 infrastructure to update the desktop dimensions. Without it, the driver would update the ScreenRecs but not update the total dimensions the input code

Re: [PATCH 0/3] Make timers even more resistant to signals

2012-10-02 Thread Daniel Kurtz
On Wed, Oct 3, 2012 at 11:25 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Fri, Sep 28, 2012 at 01:25:50AM -0700, Keith Packard wrote: Peter Hutterer peter.hutte...@who-t.net writes: Thanks, merged this into my tree. This should fix the remaining issues we're seeing with

Re: gc funcs and ops at screen level

2012-10-02 Thread Dave Airlie
On Wed, Oct 3, 2012 at 2:20 PM, Aaron Plattner aplatt...@nvidia.com wrote: On 10/02/2012 05:45 PM, Dave Airlie wrote: It seems wierd that we have the GC carrying around a pointer to each of these, when I don't see any evidence we can't just stash one set of ops/funcs per screen. Did we

Re: [PATCH 0/3] Make timers even more resistant to signals

2012-10-02 Thread Peter Hutterer
On Wed, Oct 03, 2012 at 12:26:54PM +0800, Daniel Kurtz wrote: On Wed, Oct 3, 2012 at 11:25 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Fri, Sep 28, 2012 at 01:25:50AM -0700, Keith Packard wrote: Peter Hutterer peter.hutte...@who-t.net writes: Thanks, merged this into my

Re: [PATCH xf86-input-mouse] Fix attempting to log data in a signal unsafe manner warning

2012-10-02 Thread Alan Coopersmith
On 08/31/12 09:13 AM, Markus Trippelsdorf wrote: (EE) BUG: triggered 'if (inSignalContext)' (EE) BUG: /var/tmp/portage/x11-base/xorg-server-1.12.99.905/work/xorg-server-1.12.99.905/os/log.c:472 in LogVMessageVerb() (EE) Warning: attempting to log data in a signal unsafe manner while in