date:20101108

On Mon, Nov  8, 2010 at 08:30:37 +0100, Mark Kettenis wrote:

 Actually, I don't think this is a good idea.  Unless I'm mistaken, the
 newport driver only supports one particular range of SGI graphics
 hardware.  There are quite a few other SGI graphics boards out there
 and other non-SGI mips hardware platforms.
 
The driver's probe function looks for 'SGI Indy' or 'SGI Indigo2' in
/proc/cpuinfo.  Are there any of those using a different graphics chip?

Disclaimer: I know nothing about that hw.

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: [PATCH 1/3] Xi: split hierarchy manipulation into static functions.

On Mon, Nov  8, 2010 at 10:06:31 +1000, Peter Hutterer wrote:

[...]
 +static int
 +remove_master(ClientPtr client, xXIRemoveMasterInfo *r,
 +  int flags[MAXDEVICES])
 +{
 +DeviceIntPtr ptr, keybd, XTestptr, XTestkeybd;
 +int rc = Success;
 +
 +if (r-return_mode != XIAttachToMaster 
 +r-return_mode != XIFloating)
 +return BadValue;
 +
Probably for a followup patch, but set client-errorValue to
r-return_mode here?  There's a couple other places around there that
might want to set errorValue as well, I think.

For the patch itself,
Reviewed-by: Julien Cristau jcris...@debian.org

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: [PATCH 2/3] Xi: rename two variables from ptr to dev.

On Mon, Nov  8, 2010 at 10:06:32 +1000, Peter Hutterer wrote:

 They were named ptr when everything was in one function to save one more
 variable. Now that the stuff is split out, dev makes more sense.
 
 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
  Xi/xichangehierarchy.c |   28 ++--
  1 files changed, 14 insertions(+), 14 deletions(-)
 
Reviewed-by: Julien Cristau jcris...@debian.org

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: [PATCH 3/3] Xi: if XTEST device creation fails, fail the master devices.

On Mon, Nov  8, 2010 at 10:06:33 +1000, Peter Hutterer wrote:

 When getting close to the MAXDEVICES limit, the creation of XTEST devices
 may fail due to device id exhaustion. In that case, fail the creation of
 master devices too and return an error to the client.
 
 Theoretically, we could alloc the MDs without the XTEST devices but that
 will get interesting when a client starts sending XTEST events through those
 devices.
 
 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
  Xi/xichangehierarchy.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)
 
Reviewed-by: Julien Cristau jcris...@debian.org

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] Stop mentioning server's -scanpci option.

It got removed in server's 9727db88d57089be6483104de435626cdbad883a
(long time ago).

Signed-off-by: Cyril Brulebois k...@debian.org
---
 man/fbdev.man |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/man/fbdev.man b/man/fbdev.man
index 9c3d24a..bda0ed6 100644
--- a/man/fbdev.man
+++ b/man/fbdev.man
@@ -37,9 +37,7 @@ driver can pick up the currently used video mode from the 
framebuffer
 driver and will use it if there are no video modes configured.
 .PP
 For PCI boards you might have to add a BusID line to the Device
-section.  See above for a sample line.  You can use \*q\__xservername__
--scanpci\*q
-to figure out the correct values.
+section.  See above for a sample line.
 .PP
 The following driver 
 .B Options
-- 
1.7.2.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] Avoid unused variables when XSERVER_LIBPCIACCESS is defined.

Signed-off-by: Cyril Brulebois k...@debian.org
---
 src/fbdev.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/fbdev.c b/src/fbdev.c
index 4cde790..99672d3 100644
--- a/src/fbdev.c
+++ b/src/fbdev.c
@@ -284,7 +284,9 @@ FBDevProbe(DriverPtr drv, int flags)
ScrnInfoPtr pScrn;
GDevPtr *devSections;
int numDevSections;
+#ifndef XSERVER_LIBPCIACCESS
int bus,device,func;
+#endif
char *dev;
Bool foundScreen = FALSE;
 
-- 
1.7.2.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] Allow building without XV.

Julien Cristau jcris...@debian.org (07/11/2010):
 This should probably just add #ifdef XV around that block in
 src/fbdev.c, so it follows the configuration of the server you're
 building against (xorg-server.h).

In which case, one would have to ship two flavours of the header: one
for the normal X server, and one for the udeb (micro-deb, for the
Debian Installer), which sounds a bit of an overhead just for an
extension?

Mraw,
KiBi.


signature.asc
Description: Digital 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] Allow building without XV.

On Mon, Nov  8, 2010 at 13:41:35 +0100, Cyril Brulebois wrote:

 Julien Cristau jcris...@debian.org (07/11/2010):
  This should probably just add #ifdef XV around that block in
  src/fbdev.c, so it follows the configuration of the server you're
  building against (xorg-server.h).
 
 In which case, one would have to ship two flavours of the header: one
 for the normal X server, and one for the udeb (micro-deb, for the
 Debian Installer), which sounds a bit of an overhead just for an
 extension?
 
We can just patch that #if XV to #if 0 locally, no need to clutter
upstream with such an option.

Cheers,
Julien


signature.asc
Description: Digital 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] Stop mentioning server's -scanpci option.

On Mon, Nov  8, 2010 at 13:36:21 +0100, Cyril Brulebois wrote:

 It got removed in server's 9727db88d57089be6483104de435626cdbad883a
 (long time ago).
 
 Signed-off-by: Cyril Brulebois k...@debian.org
 ---
  man/fbdev.man |4 +---
  1 files changed, 1 insertions(+), 3 deletions(-)
 
Maybe add a 'man:' prefix to the commit message, but
Reviewed-by: Julien Cristau jcris...@debian.org

Cheers,
Julien


signature.asc
Description: Digital 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] Avoid unused variables when XSERVER_LIBPCIACCESS is defined.

On Mon, Nov  8, 2010 at 13:36:47 +0100, Cyril Brulebois wrote:

 Signed-off-by: Cyril Brulebois k...@debian.org
 ---
  src/fbdev.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
Reviewed-by: Julien Cristau jcris...@debian.org

Cheers,
Julien


signature.asc
Description: Digital 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

[PATCH] Perform XV initialization only if the server supports it.

Use XV from server's xorg-server.h to determine whether to perform XV
initialization.

Signed-off-by: Cyril Brulebois k...@debian.org
---
 src/fbdev.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/fbdev.c b/src/fbdev.c
index 99672d3..7e12b1d 100644
--- a/src/fbdev.c
+++ b/src/fbdev.c
@@ -896,6 +896,7 @@ FBDevScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, 
char **argv)
fPtr-CloseScreen = pScreen-CloseScreen;
pScreen-CloseScreen = FBDevCloseScreen;
 
+#if XV
{
XF86VideoAdaptorPtr *ptr;
 
@@ -904,6 +905,7 @@ FBDevScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, 
char **argv)
xf86XVScreenInit(pScreen,ptr,n);
}
}
+#endif
 
TRACE_EXIT(FBDevScreenInit);
 
-- 
1.7.2.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] Allow building without XV.

Julien Cristau jcris...@debian.org (08/11/2010):
 We can just patch that #if XV to #if 0 locally, no need to clutter
 upstream with such an option.

ACK, patch updated. Thanks for the review(s).

Mraw,
KiBi.


signature.asc
Description: Digital 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] Perform XV initialization only if the server supports it.

On Mon, Nov  8, 2010 at 14:24:46 +0100, Cyril Brulebois wrote:

 Use XV from server's xorg-server.h to determine whether to perform XV
 initialization.
 
 Signed-off-by: Cyril Brulebois k...@debian.org
 ---
  src/fbdev.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
 diff --git a/src/fbdev.c b/src/fbdev.c
 index 99672d3..7e12b1d 100644
 --- a/src/fbdev.c
 +++ b/src/fbdev.c
 @@ -896,6 +896,7 @@ FBDevScreenInit(int scrnIndex, ScreenPtr pScreen, int 
 argc, char **argv)
   fPtr-CloseScreen = pScreen-CloseScreen;
   pScreen-CloseScreen = FBDevCloseScreen;
  
 +#if XV
   {
   XF86VideoAdaptorPtr *ptr;
  
 @@ -904,6 +905,7 @@ FBDevScreenInit(int scrnIndex, ScreenPtr pScreen, int 
 argc, char **argv)
   xf86XVScreenInit(pScreen,ptr,n);
   }
   }
 +#endif
  
   TRACE_EXIT(FBDevScreenInit);
  
Reviewed-by: Julien Cristau jcris...@debian.org

Cheers,
Julien


signature.asc
Description: Digital 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] Stop mentioning server's -scanpci option.

2010-11-08 Thread Alan Coopersmith

Cyril Brulebois wrote:
 It got removed in server's 9727db88d57089be6483104de435626cdbad883a
 (long time ago).
 
 Signed-off-by: Cyril Brulebois k...@debian.org
 ---
  man/fbdev.man |4 +---
  1 files changed, 1 insertions(+), 3 deletions(-)
 
 diff --git a/man/fbdev.man b/man/fbdev.man
 index 9c3d24a..bda0ed6 100644
 --- a/man/fbdev.man
 +++ b/man/fbdev.man
 @@ -37,9 +37,7 @@ driver can pick up the currently used video mode from the 
 framebuffer
  driver and will use it if there are no video modes configured.
  .PP
  For PCI boards you might have to add a BusID line to the Device
 -section.  See above for a sample line.  You can use \*q\__xservername__
 --scanpci\*q
 -to figure out the correct values.
 +section.  See above for a sample line.
  .PP
  The following driver 
  .B Options

Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com

-- 
-Alan Coopersmith-alan.coopersm...@oracle.com
 Oracle Solaris Platform Engineering: X Window System

___
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] try the newport driver on mips

2010-11-08 Thread Matt Turner

On Mon, Nov 8, 2010 at 6:13 AM, Julien Cristau jcris...@debian.org wrote:
 On Mon, Nov  8, 2010 at 08:30:37 +0100, Mark Kettenis wrote:

 Actually, I don't think this is a good idea.  Unless I'm mistaken, the
 newport driver only supports one particular range of SGI graphics
 hardware.  There are quite a few other SGI graphics boards out there
 and other non-SGI mips hardware platforms.

 The driver's probe function looks for 'SGI Indy' or 'SGI Indigo2' in
 /proc/cpuinfo.  Are there any of those using a different graphics chip?

I think it covers all Indys. Indigo2s can also have an impact graphics
card, which would be the xf86-video-impact driver. I actually didn't
know it existed until now.
___
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

Dri2 buffer format

2010-11-08 Thread Russell Shaw


Hi,
How should the format of a DRI2 buffer be determined?


http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt

DRI2ATTACH_FORMAT { attachment: CARD32
format: CARD32 }

The DRI2ATTACH_FORMAT describes an attachment and the associated
format.  'attachment' describes the attachment point for the buffer,
'format' describes an opaque, device-dependent format for the buffer.


xorg-server-1.7.7/hw/xfree86/dri2/dri2ext.c
___
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: The future of Xephyr and Kdriver

2010-11-08 Thread Jamey Sharp

On Mon, Nov 8, 2010 at 1:45 AM, Feng, Haitao haitao.f...@intel.com wrote:
 Have you noticed Kristian's Wayland project? In an email discussion,
 Kristian mentioned the Xorg on Xorg idea and discussed its design and
 implementation. Quoted from the email:

 I imagine a new module called 'hosted' that lets the DDX drivers detect
 that they're running under an existing display server (Xorg or wayland)
 and then use that instead of KMS for modesetting and allocating front
 buffers.  Ideally this can be done in a way so that the DDX driver
 doesn't need to know what the host display server is, but just
 interfaces with the 'hosted' module.  Then there will be a little bit of
 code that each DDX driver needs to add that talks to the 'hosted' module
 to get the DRM fd, to set the front buffer and to post damage.

That's fascinating. I haven't heard Kristian mention the 'hosted'
module idea before.

That approach should get great performance for nested displays, and
sounds fairly easy to implement. It only works if both servers are
running on the same machine though. Obviously that's an important use
case, and covers what you need for Meego. It doesn't address several
other use cases we care about, where there are one or more backend X
servers on different machines.

Our project will go ahead on a pure X basis. If somebody builds this
'hosted' module, maybe at some point in the future we could find a way
for the two to cooperate. Something like, if the backend server has
working DRI2 then try loading the hosted and hardware drivers
automatically?

Jamey
___
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 xmessage] man: point to the X manpage for more command line options

It was already listed in 'SEE ALSO', but adding a reference in the
'OPTIONS' section is probably easier to find.

Reported-by: Ivan Vilata i Balaguer i...@selidor.net
Cc: 505...@bugs.debian.org
Signed-off-by: Julien Cristau jcris...@debian.org
---
 xmessage.man |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/xmessage.man b/xmessage.man
index 016ba88..6e5f547 100644
--- a/xmessage.man
+++ b/xmessage.man
@@ -48,7 +48,9 @@ sizes itself to fit the message, up to a maximum size.
 If the message is too big for the window, \fIxmessage\fP will display
 scroll bars.
 .SH OPTIONS
-These are the command line options that \fIxmessage\fP understands.
+These are the command line options that \fIxmessage\fP understands, in addition
+to the standard ones listed in
+.BR X (__miscmansuffix__).
 .TP 8
 .B \-buttons \fIbutton,button,.\|.\|.\fP
 This option will cause \fIxmessage\fP to create one button for each
-- 
1.7.2.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] Fix for bug Bug 13040 'Make the cursor option in xorg.conf useful'

2010-11-08 Thread Manuel Reimer


Hello,

at first: Forget the last patch ;-)
I completely disassembled the pen for this tablet, assembled it again (I 
placed the small magnet in the pen in in reverse direction, but I'm 
unsure if this is the reason why it works) and now pen and puck are 
working again, the way they should...


Just to get sure, I'll now order a new pen as spare part. At least in 
germany it's still possible to get spare parts for a very small price.


I'll now try to get this driver work with two separate X input devices 
(one for puck, one for pen).


Does someone mind if I fix the indentation of the code, first. This 
looks just crazy in my editor... Maybe this should be a separate patch?


Yours

Manuel

___
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: The future of Xephyr and Kdriver

2010-11-08 Thread Kristian Høgsberg

On Mon, Nov 8, 2010 at 11:01 AM, Jamey Sharp ja...@minilop.net wrote:
 On Mon, Nov 8, 2010 at 1:45 AM, Feng, Haitao haitao.f...@intel.com wrote:
 Have you noticed Kristian's Wayland project? In an email discussion,
 Kristian mentioned the Xorg on Xorg idea and discussed its design and
 implementation. Quoted from the email:

 I imagine a new module called 'hosted' that lets the DDX drivers detect
 that they're running under an existing display server (Xorg or wayland)
 and then use that instead of KMS for modesetting and allocating front
 buffers.  Ideally this can be done in a way so that the DDX driver
 doesn't need to know what the host display server is, but just
 interfaces with the 'hosted' module.  Then there will be a little bit of
 code that each DDX driver needs to add that talks to the 'hosted' module
 to get the DRM fd, to set the front buffer and to post damage.

 That's fascinating. I haven't heard Kristian mention the 'hosted'
 module idea before.

 That approach should get great performance for nested displays, and
 sounds fairly easy to implement. It only works if both servers are
 running on the same machine though. Obviously that's an important use
 case, and covers what you need for Meego. It doesn't address several
 other use cases we care about, where there are one or more backend X
 servers on different machines.

 Our project will go ahead on a pure X basis. If somebody builds this
 'hosted' module, maybe at some point in the future we could find a way
 for the two to cooperate. Something like, if the backend server has
 working DRI2 then try loading the hosted and hardware drivers
 automatically?

I already wrote it:

  http://cgit.freedesktop.org/~krh/xserver/log/?h=hosted

Right now that only supports Xorg on wayland, but I've started
separating out the backend, to let it run on either wayland or Xorg.

Kristian
___
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 hyperpen] Fixed indentation, dropped trailing whitespaces

2010-11-08 Thread Manuel Reimer


This patch shouldn't change the way the hyperpen driver works.
Anything, it does, is to fix the indentation and it drops some useless trailing 
whitespaces. Without this, the code is nearly unreadable.

I used this as reference: http://www.x.org/wiki/CodingStyle

Signed-off-by: Manuel Reimer manuel.rei...@gmx.de
---
 src/xf86HyperPen.c | 1255 +---
 1 files changed, 606 insertions(+), 649 deletions(-)

diff --git a/src/xf86HyperPen.c b/src/xf86HyperPen.c
index 3920a04..4e265bb 100644
--- a/src/xf86HyperPen.c
+++ b/src/xf86HyperPen.c
@@ -1,17 +1,18 @@
+// -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-
 /*
  * xf86HyperPen
  *
  * Based on the xf86Summa driver.
- *
+ *
  * Modified for the Aiptek HyperPen 6000 / Tevion MD 9310
  *   (c) 2000 Roland Jansen rol...@lut.rwth-aachen.de
- *
- *
- *
+ *
+ *
+ *
  * added button and 19200 bps stuff from the DigitalEdge driver on sourceforge
  *   (c) 2000 Christian Herzog dad...@dataway.ch
- *
- *
+ *
+ *
  */

 /* xf86Summa
@@ -55,7 +56,7 @@
 #endif
 #include xf86_OSproc.h
 #include xf86Xinput.h
-#include exevents.h/* Needed for InitValuator/Proximity stuff */
+#include exevents.h/* Needed for InitValuator/Proximity stuff */
 #include X11/keysym.h
 #include mipointer.h

@@ -77,21 +78,20 @@
 #undef PRIVATE
 #define PRIVATE(x) XI_PRIVATE(x)

-/*
+/*
  * Be sure to set vmin appropriately for your device's protocol. You want to
  * read a full packet before returning
  */

-static const char *default_options[] =
-{
-   BaudRate,   9600,
-   DataBits,   8,
-   StopBits,   1,
-   Parity, Odd,
-   FlowControl,Xoff,
-   VTime,  10,
-   VMin,   7,
-   NULL
+static const char *default_options[] = {
+BaudRate,9600,
+DataBits,8,
+StopBits,1,
+Parity,  Odd,
+FlowControl, Xoff,
+VTime,   10,
+VMin,7,
+NULL
 };

 static InputDriverPtr hypDrv;
@@ -115,64 +115,63 @@ static InputDriverPtr hypDrv;
 static int debug_level = INI_DEBUG_LEVEL;
 #define DEBUG 1
 #if DEBUG
-#defineDBG(lvl, f) {if ((lvl) = debug_level) f;}
+#define DBG(lvl, f) {if ((lvl) = debug_level) f;}
 #else
-#defineDBG(lvl, f)
+#define DBG(lvl, f)
 #endif

 /*
 ** Device records
 */
-#define ABSOLUTE_FLAG  1
-#define STYLUS_FLAG2
-#define INVX_FLAG  4
-#define INVY_FLAG  8
-#define BAUD_19200_FLAG16  
+#define ABSOLUTE_FLAG   1
+#define STYLUS_FLAG 2
+#define INVX_FLAG   4
+#define INVY_FLAG   8
+#define BAUD_19200_FLAG 16

 int stylus;

-typedef struct
-{
-   char*hypDevice; /* device file name */
-   int hypButTrans;/* button translation flags */
-   int hypOldX;/* previous X position */
-   int hypOldY;/* previous Y position */
-   int hypOldZ;/* previous Z position */
-   int hypOldProximity; /* previous proximity */
-   int hypOldPush;   /* previous buttons state */
-   int hypOldButtons;   /* previous buttons state */
-   int hypOldBarrel; /* previous buttons state */
-   int hypOldBarrel1;/* previous buttons state */
-   int hypOldPressure;   /* previous pen pressure */
-   int hypMaxX;/* max X value */
-   int hypMaxY;/* max Y value */
-   int hypMaxZ;/* max Z value */
-   int hypXSize;   /* active area X size */
-   int hypXOffset; /* active area X offset */
-   int hypYSize;   /* active area Y size */
-   int hypYOffset; /* active area Y offset */
-   int hypRes; /* resolution in lines per inch */
-   int flags;  /* various flags */
-   int hypIndex;   /* number of bytes read */
-   int modelid;/* model id */
-   int PT; /* pressure threshold */
-int AutoPT; /* automatically set PT*/
-int PMax;   /* maximum pressure read from tablet */
-   unsigned char hypData[7];   /* data read on the device */
+typedef struct {
+char *hypDevice;  /* device file name */
+int hypButTrans;  /* button translation flags */
+int hypOldX;  /* previous X position */
+int hypOldY;  /* previous Y position */
+int hypOldZ;  /* previous Z position */
+int hypOldProximity;  /* previous proximity */
+int hypOldPush;   /* previous buttons state */
+int hypOldButtons;/* previous buttons state */
+int hypOldBarrel; /* previous buttons state */
+int hypOldBarrel1;/* previous buttons state */
+int hypOldPressure;   /* previous pen pressure */
+int hypMaxX;  /* max X value */
+int hypMaxY;

[PATCH sgml-doctools] Upgrade xorg-sgml-doctools to Autoconf 2.60 directory architecture

2010-11-08 Thread Gaetan Nadon

Currently the value of sgmlrootdir is hard coded relative to $prefix.
In Autoconf 2.60, $datarootdir has been added to define the architecture
independent data directory.

  --datarootdir=DIR   read-only arch.-independent data root [PREFIX/share]

Relative to that location, a number of subdirectories have been defined:

  --datadir=DIR  read-only architecture-independent data [DATAROOTDIR]
  --infodir=DIR  info documentation [DATAROOTDIR/info]
  --localedir=DIRlocale-dependent data [DATAROOTDIR/locale]
  --mandir=DIR   man documentation [DATAROOTDIR/man]
  --docdir=DIR   documentation root
 [DATAROOTDIR/doc/xorg-sgml-doctools]
  --htmldir=DIR  html documentation [DOCDIR]
  --dvidir=DIR   dvi documentation [DOCDIR]
  --pdfdir=DIR   pdf documentation [DOCDIR]
  --psdir=DIRps documentation [DOCDIR]

The sgmlrootdir should hang off datarootdir. If there is a need to specify
a different location, a new configure option should be added:

  --sgmldir=DIR  sgml stylesheets and entities [DATAROOTDIR/sgml]

An sgmlrootdir Automake variable is defined in configure.ac to provide
a unique value holder for the sgmlrootdir.

Variable PACKAGE_VERSION is preferred over the undocumented VERSION variable.

Signed-off-by: Gaetan Nadon mems...@videotron.ca
---
 Makefile.am  |2 +-
 configure.ac |2 ++
 xorg-sgml-doctools.pc.in |7 ---
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 049abac..e3fcca5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,7 +19,7 @@
 #  TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 #  PERFORMANCE OF THIS SOFTWARE.
 
-sgmldir = $(prefix)/share/sgml/X11
+sgmldir = $(sgmlrootdir)/X11
 
 dist_sgml_DATA = defs.ent xorg.css xorg.xsl
 
diff --git a/configure.ac b/configure.ac
index 6ca9198..9a05526 100644
--- a/configure.ac
+++ b/configure.ac
@@ -34,6 +34,8 @@ m4_ifndef([XORG_MACROS_VERSION],
 XORG_MACROS_VERSION(1.3)
 XORG_DEFAULT_OPTIONS
 
+AC_SUBST([sgmlrootdir],['${datarootdir}/sgml'])
+
 AC_PROG_INSTALL
 
 AC_OUTPUT([
diff --git a/xorg-sgml-doctools.pc.in b/xorg-sgml-doctools.pc.in
index ae1422a..9546fa7 100644
--- a/xorg-sgml-doctools.pc.in
+++ b/xorg-sgml-doctools.pc.in
@@ -1,6 +1,7 @@
 pref...@prefix@
-sgmlrootdir=${prefix}/share/sgml
+datarootd...@datarootdir@
+sgmlrootd...@sgmlrootdir@
 
 Name: xorg-sgml-doctools
-Description: SGML entities for X.Org documentation
-Version: @VERSION@
+Description: Stylesheets and entities for X.Org documentation
+Version: @PACKAGE_VERSION@
-- 
1.6.0.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] Extract LogFinishInit from LogInit

Mikhail Gusarov dotted...@dottedmag.net (25/10/2010):
 diff --git a/os/log.c b/os/log.c
 […]
 +void
 +LogFinishInit(void)
 +{
 +if (saveBuffer) {
 + free(saveBuffer);   /* Must be free(), not free() */


That probably can go away, see 3f3ff971. There are also some other
comments about malloc and friends which are said not to be usable at
this point (git grep can't be used -- os/log.c).

Mraw,
KiBi.


signature.asc
Description: Digital 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 x11perf] Install x11perfcomp auxiliary scripts in $datadir, not $libdir.

On Mon, Nov  8, 2010 at 10:40:20 +1000, Peter Hutterer wrote:

 From: Adam Jackson a...@redhat.com
 
 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
  Makefile.am |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
They're shell scripts, so this looks like a good change.

Acked-by: Julien Cristau jcris...@debian.org

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: [PATCH] Extract LogFinishInit from LogInit

2010-11-08 Thread Mikhail Gusarov


Twas brillig at 20:53:40 08.11.2010 UTC+01 when k...@debian.org did gyre and 
gimble:

  diff --git a/os/log.c b/os/log.c
  […]
  +void
  +LogFinishInit(void)
  +{
  +if (saveBuffer) {
  +free(saveBuffer);/* Must be free(), not free() */
 CB 

 CB That probably can go away, see 3f3ff971.

Right, as well as if (saveBuffer).

-- 
  http://fossarchy.blogspot.com/


pgph21dZa7j7n.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

1.9.3rc1 Firday

2010-11-08 Thread Jeremy Huddleston

I'd like to round up changes for a 1.9.3rc1 this Friday.  I know there are some 
good input fixes (one of which was delayed from 1.9.2 due to a regression that 
should now be fixed), and there are probably others.  If you think you've got a 
fix that should land in 1.9.3, please nominate it this week.  Fixes should be 
limited to memory management, crashes, performance, documentation, and new 
architecture support.

Thanks,
Jeremy

___
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: displayid: dubious assignments

On Sat, 2010-10-30 at 21:03 +0200, Nicolas Kaiser wrote:
 Hi there!
 
 I noticed two assignments that look a bit peculiar to me.
 n is assigned MAX_HSYNC and MAX_VREFRESH, but these values
 get either overwritten or remain unused.
 I hope that's not a problem?

Well, it's not a problem at the moment, since the DisplayID code isn't
hooked up to anything.

Effectively the code is ignoring sync specifiers beyond
MAX_{HSYNC,VREFRESH} because the xf86MonPtr we're storing them into only
has that many slots.  Which is a bit lame in theory?  But even in EDID I
don't think I've _ever_ seen a monitor that specifies more than one sync
range, so it's a bit of a theoretical concern.

- ajax

___
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] Multi-Touch (MT) support - arbitration or not

On Mon, Nov 8, 2010 at 2:08 AM, Benjamin Tissoires tisso...@cena.fr wrote:
 Le 08/11/2010 04:51, Peter Hutterer a écrit :

 fwiw, I'm not sure arbitrate is the right word here, filtering seems
 easier to understand in this context. I guess arbitrate would apply more
 if we emit the events across multiple devices like in the bamboo case.
 that's mostly bikeshedding though, my points below apply regardless of
 what
 word we choose :)

 note that we also have two different approaches - single kernel device or
 multiple kernel devices and depending on the approach the device uses the
 options below have different advantages and disadvantages.

 the tablets I've dealt with so far exposed a single event device, so
 that's
 what I'm focusing on in this email.

 On Fri, Nov 05, 2010 at 11:47:28AM -0700, Ping Cheng wrote:

 Recent changes and discussion about MT support at LKML, UDS, and
 xorg-devel encouraged me to migrate Wacom MT devices to the slot-based
 MT protocol (introduced in kernel 2.6.36). Since Wacom supports both
 digitizer and touch devices, I need to decide how to report touch data
 when the pen is in proximity.

 My goal is to understand how X server would like the MT data to be
 reported from the kernel. I hope to keep kernel and X server driver MT
 support in sync so we can avoid unnecessary confusion or extra work in
 the userland.

 The existing solution for single touch events is to arbitrate touch
 when pen is in prox. This is based on the assumption that we do not
 want to have two cursors competing on the screen.

 With the introduction of MT, the touch data are most likely translated
 into something other than pointer events. So, reporting both pen and
 touch data makes sense now. However, I want to assure a smooth
 tansition from single touch to MT for end users so they still get the
 single touch behavior as they used to be. I gathered the following
 approaches:

 1.     Arbitrate all touch data in the kernel.

 This is the simplest solution for device driver developers. But I do
 not feel it is end user and userland client friendly.

 I'm strongly opposed to this. kernel filtering of these devices is hard to
 circumvent and there _will_ be use-cases where we need more than one tool
 to
 work simultaneously. right now we're worrying about pen + touch, but what
 stops tablets from becoming large enough to be used by 2+ users with 2+
 pens simultaneously?

 from a purely event-stream focused viewpoint: why do we even care whether
 something is a pen or a touch? both are just tools and how these should be
 used is mostly up to the clients anyway.  IMO, the whole point of
 MT_TOOL_TYPE is that we don't have to assume use-cases for the tools but
 just forward the information to someone who knows how to deal with this.

 2.     Report first finger touch as ABS_X/Y events when pen is not in
 prox.  Arbitrating single touch data when pen is in prox. Pen data is
 reported as ABS_X/Y events. Both ABS_X/Y for pen or the first finger
 and ABS_MT_* for MT data are reported.

 This approach reduces the overhead in dealing with two cursors in
 userland.

 3.    Report first finger touch as ABS_X/Y events when pen is not in
 prox;
        Report pen data as ABS_X/Y events when there is no finger touch;
        Report touch data as MT_TOOL_TOUCH and pen data as MT_TOOL_PEN
 events when both pen and touch data are received. No ABS_X/Y are
 reported when pen and tocuh or multi-touch data are received.

 I feel this one makes sense to userland since pen can be considered as
 another touch.

 4.    Report first finger touch as ABS_X/Y events when pen is not in
 prox;
        Report pen data as ABS_X/Y events when there is no finger touch;
        Report touch data as MT_TOOL_TOUCH and pen data as MT_TOOL_PEN
 events when both pen and touch data are received. ABS_X/Y are also
 reported for pen when both pen and tocuh data are received.

 I'd vote for this one. It provides all the data necessary for MT clients
 (and all the data the device can support) but has a reasonable
 single-touch
 strategy. Given that wacom tablets are still primarily pen-centric
 tablets,
 the emphasis on pen overriding touch makes sense to me.

 Hi,

 I'd also vote for this.

 I don't think that the kernel should make any assumption on the final
 application. The data are available, so we have to pass them.

 1. I read that people worry about sending false events (touch) while using
 the pen. But in my mind, this is a _design_ problem of the final
 application. I think the final application will have to filter these events:
 for instance, what happens if the user is too lazy to remove his pen (or
 just want to keep the hover on the application) out of the proximity range
 and want to move its digital sheet of paper in his (her) design application?
 The final application will have to choose whether using or not the touch
 features (depending on the pressure for instance...).

 The solution 4. (*technical solution*) addresses the

Re: Smooth scrolling again

2010-11-08 Thread Max Schwarz

Hi Simon,

 That sounds fine. But how are button events being generated which match
 a potential only-smooth-scrolling input?
I'm not sure I understand your question. I didn't change the generation of 
button events in any way. They are just emitted in parallel by the old code.

  You want that distinction in the server? That would require more changes,
  since non-integrating valuators would need to be handled the same as
  relative valuators in most contexts.
 
 True, though negligible for bit-flag based modes.
Okay, now we need a decision ;-)
I'll change it if it's wanted, but it'll blow the patch quite a bit up ;-)

 We have axis labels ( = properties + some shi shi), why not use
 properties to communicate the axis resolution? It seems that the axis
 resolution field is well-intentioned, but hasn't actually been used.
I'm doing that already in one direction (client - driver) if someone wants to 
change the evdev wheel resolution. I think the right solution would be to emit 
a XI event telling the client that the device has changed.

Max
___
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: Smooth scrolling again

2010-11-08 Thread Simon Thum

On 11/07/10 18:03, Max Schwarz wrote:
 Hi Simon,
 
 A thing I'm
 missing is how you're establishing the relationship of smooth and button
 scrolling? It might just be me since I'm only looking at the diffs.
 It's certainly subtle ;-)
 Look at EvdevProcessRelativeMotionEvent().
 In case of a change on REL_(H)WHEEL the clicks are queued and value is 
 multiplied by the current resolution, which is 42 if mouse wheel emulation is 
 enabled, and 1 otherwise. The mouse wheel emulation code just injects the raw 
 values from the axes.
 The toolkit-space code interprets the valuator resolution as ticks per old-
 style scroll button click, e.g.
 float clicks = event_value / resolution;
That sounds fine. But how are button events being generated which match
a potential only-smooth-scrolling input?

 A minor objection is that the evdev wheel resolution is not
 axis-dependent. This may (or may not) be a problem.
 Well, it was not handled differently up to this point (same count of clicks 
 emitted for both directions).
It's certainly an easy fix should it bubble up.

 
 Also minor: axes seem to gain a mode (rel/abs), maybe we can make that
 (rel/abs/non-integrating rel)?
 You want that distinction in the server? That would require more changes, 
 since non-integrating valuators would need to be handled the same as relative 
 valuators in most contexts.
True, though negligible for bit-flag based modes.

 Something that I just thought of: Runtime-changing of the resolution is not 
 really supported right now. You can change the property, but the resolution 
 field of the valuator is not updated, and no XIDeviceChanged events are sent 
 to 
 clients...
 That would definitely be needed for fine-tuning the wheel resolution (= 
 scroll 
 speed).
We have axis labels ( = properties + some shi shi), why not use
properties to communicate the axis resolution? It seems that the axis
resolution field is well-intentioned, but hasn't actually been used.

Cheers,

Simon
___
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 xmessage] man: point to the X manpage for more command line options

On Mon, Nov 08, 2010 at 05:20:29PM +0100, Julien Cristau wrote:
 It was already listed in 'SEE ALSO', but adding a reference in the
 'OPTIONS' section is probably easier to find.
 
 Reported-by: Ivan Vilata i Balaguer i...@selidor.net
 Cc: 505...@bugs.debian.org
 Signed-off-by: Julien Cristau jcris...@debian.org
 ---
  xmessage.man |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/xmessage.man b/xmessage.man
 index 016ba88..6e5f547 100644
 --- a/xmessage.man
 +++ b/xmessage.man
 @@ -48,7 +48,9 @@ sizes itself to fit the message, up to a maximum size.
  If the message is too big for the window, \fIxmessage\fP will display
  scroll bars.
  .SH OPTIONS
 -These are the command line options that \fIxmessage\fP understands.
 +These are the command line options that \fIxmessage\fP understands, in 
 addition
 +to the standard ones listed in
 +.BR X (__miscmansuffix__).
  .TP 8
  .B \-buttons \fIbutton,button,.\|.\|.\fP
  This option will cause \fIxmessage\fP to create one button for each
 -- 
 1.7.2.3

Reviewed-by: Peter Hutterer peter.hutte...@who-t.net

Cheers,
  Peter
___
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 x11proto] Add XF86XK_TouchpadOn/Off

On Sun, Nov 7, 2010 at 11:24 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 Patch is fine with me. any NAKs?

 The udev patch to standardise the behaviour is already in, see
 http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=a1ca5f60e0770299c5c5f21bd371f5823802412b
 It requires an update to xkeyboard-config as well, synchronised with udev to
 maintain consistency. That's possible once this change is in.


And just to stress, at this point we need a commit made somewhere.
Might as well make this one.

udev submission above has changed existing F22 values to F21 so at
minimum to align with them we need to update below value from
xkeyboard-config's inet + synchronized udev release to prevent
breakage of existing feature.

key FK22   {  [ XF86TouchpadToggle]   };

Chris
___
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 2/2] Remove more superfluous if(p!=NULL) checks around free(p).

This patch has been generated by the following Coccinelle semantic patch:

@@
expression E;
@@
- if (E != NULL)
-   free(E);
+ free(E);

Signed-off-by: Cyril Brulebois k...@debian.org
---
 dix/grabs.c |7 ++-
 glx/single2.c   |3 +--
 hw/xfree86/modes/xf86Crtc.c |3 +--
 mi/mispans.c|2 +-
 miext/rootless/rootlessScreen.c |3 +--
 os/log.c|6 ++
 xkb/XKBMAlloc.c |6 ++
 xkb/ddxLoad.c   |6 ++
 8 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/dix/grabs.c b/dix/grabs.c
index f850e3d..69c58df 100644
--- a/dix/grabs.c
+++ b/dix/grabs.c
@@ -117,11 +117,8 @@ CreateGrab(
 static void
 FreeGrab(GrabPtr pGrab)
 {
-if (pGrab-modifiersDetail.pMask != NULL)
-   free(pGrab-modifiersDetail.pMask);
-
-if (pGrab-detail.pMask != NULL)
-   free(pGrab-detail.pMask);
+free(pGrab-modifiersDetail.pMask);
+free(pGrab-detail.pMask);
 
 if (pGrab-cursor)
FreeCursor(pGrab-cursor, (Cursor)0);
diff --git a/glx/single2.c b/glx/single2.c
index 56ad86d..f93ce6e 100644
--- a/glx/single2.c
+++ b/glx/single2.c
@@ -377,8 +377,7 @@ int DoGetString(__GLXclientState *cl, GLbyte *pc, GLboolean 
need_swap)
 
 __GLX_SEND_HEADER();
 WriteToClient(client, length, (char *) string); 
-if (buf != NULL)
-   free(buf);
+free(buf);
 
 return Success;
 }
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index b2daec7..7fc2a60 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -2964,8 +2964,7 @@ xf86OutputSetEDID (xf86OutputPtr output, xf86MonPtr 
edid_mon)
 intsize;
 #endif
 
-if (output-MonInfo != NULL)
-   free(output-MonInfo);
+free(output-MonInfo);
 
 output-MonInfo = edid_mon;
 
diff --git a/mi/mispans.c b/mi/mispans.c
index 9f56e3c..53539e5 100644
--- a/mi/mispans.c
+++ b/mi/mispans.c
@@ -215,7 +215,7 @@ void miAppendSpans(SpanGroup *spanGroup, SpanGroup 
*otherGroup, Spans *spans)
 
 void miFreeSpanGroup(SpanGroup *spanGroup)
 {
-if (spanGroup-group != NULL) free(spanGroup-group);
+free(spanGroup-group);
 }
 
 static void QuickSortSpansX(
diff --git a/miext/rootless/rootlessScreen.c b/miext/rootless/rootlessScreen.c
index 43b9cbb..61d2f5d 100644
--- a/miext/rootless/rootlessScreen.c
+++ b/miext/rootless/rootlessScreen.c
@@ -92,8 +92,7 @@ RootlessUpdateScreenPixmap(ScreenPtr pScreen)
 rowbytes = PixmapBytePad(pScreen-width, pScreen-rootDepth);
 
 if (s-pixmap_data_size  rowbytes) {
-if (s-pixmap_data != NULL)
-free(s-pixmap_data);
+free(s-pixmap_data);
 
 s-pixmap_data_size = rowbytes;
 s-pixmap_data = malloc(s-pixmap_data_size);
diff --git a/os/log.c b/os/log.c
index ee4b45f..7d10783 100644
--- a/os/log.c
+++ b/os/log.c
@@ -489,8 +489,7 @@ AuditFlush(OsTimerPtr timer, CARD32 now, pointer arg)
ErrorF(%slast message repeated %d times\n,
   prefix != NULL ? prefix : , nrepeat);
nrepeat = 0;
-   if (prefix != NULL)
-   free(prefix);
+   free(prefix);
return AUDIT_TIMEOUT;
 } else {
/* if the timer expires without anything to print, flush the message */
@@ -523,8 +522,7 @@ VAuditF(const char *f, va_list args)
nrepeat = 0;
auditTimer = TimerSet(auditTimer, 0, AUDIT_TIMEOUT, AuditFlush, NULL);
 }
-if (prefix != NULL)
-   free(prefix);
+free(prefix);
 }
 
 void
diff --git a/xkb/XKBMAlloc.c b/xkb/XKBMAlloc.c
index 6b186c1..e9afe31 100644
--- a/xkb/XKBMAlloc.c
+++ b/xkb/XKBMAlloc.c
@@ -292,11 +292,9 @@ KeyCode
matchingKeys[XkbMaxKeyCount],nMatchingKeys;
 }
 type= xkb-map-types[type_ndx];
 if (map_count==0) {
-   if (type-map!=NULL)
-   free(type-map);
+   free(type-map);
type-map= NULL;
-   if (type-preserve!=NULL)
-   free(type-preserve);
+   free(type-preserve);
type-preserve= NULL;
type-map_count= 0;
 }
diff --git a/xkb/ddxLoad.c b/xkb/ddxLoad.c
index 5e6ab87..cfc6198 100644
--- a/xkb/ddxLoad.c
+++ b/xkb/ddxLoad.c
@@ -267,8 +267,7 @@ XkbDDXCompileKeymapByNames( XkbDescPtr  xkb,
strncpy(nameRtrn,keymap,nameRtrnLen);
nameRtrn[nameRtrnLen-1]= '\0';
}
-if (buf != NULL)
-free(buf);
+free(buf);
return TRUE;
}
else
@@ -287,8 +286,7 @@ XkbDDXCompileKeymapByNames( XkbDescPtr  xkb,
 }
 if (nameRtrn)
nameRtrn[0]= '\0';
-if (buf != NULL)
-free(buf);
+free(buf);
 return FALSE;
 }
 
-- 
1.7.2.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 1/2] Remove more superfluous if(p) checks around free(p).

This patch has been generated by the following Coccinelle semantic patch:

@@
expression E;
@@
- if (E)
-   free(E);
+ free(E);

Signed-off-by: Cyril Brulebois k...@debian.org
---
 hw/dmx/glxProxy/glxcmds.c |2 +-
 hw/dmx/glxProxy/glxext.c  |   18 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/dmx/glxProxy/glxcmds.c b/hw/dmx/glxProxy/glxcmds.c
index a9744e1..7602128 100644
--- a/hw/dmx/glxProxy/glxcmds.c
+++ b/hw/dmx/glxProxy/glxcmds.c
@@ -2565,7 +2565,7 @@ int __glXClientInfo(__GLXclientState *cl, GLbyte *pc)

 cl-GLClientmajorVersion = req-major;
 cl-GLClientminorVersion = req-minor;
-if (cl-GLClientextensions) free(cl-GLClientextensions);
+free(cl-GLClientextensions);
 buf = (const char *)(req+1);
 cl-GLClientextensions = strdup(buf);
 
diff --git a/hw/dmx/glxProxy/glxext.c b/hw/dmx/glxProxy/glxext.c
index a8fc0a8..886b317 100644
--- a/hw/dmx/glxProxy/glxext.c
+++ b/hw/dmx/glxProxy/glxext.c
@@ -77,10 +77,10 @@ static void ResetClientState(int clientIndex)
 Display **keep_be_displays;
 int i;
 
-if (cl-returnBuf) free(cl-returnBuf);
-if (cl-currentContexts) free(cl-currentContexts);
-if (cl-currentDrawables) free(cl-currentDrawables);
-if (cl-largeCmdBuf) free(cl-largeCmdBuf);
+free(cl-returnBuf);
+free(cl-currentContexts);
+free(cl-currentDrawables);
+free(cl-largeCmdBuf);
 
 for (i=0; i screenInfo.numScreens; i++) {
if (cl-be_displays[i])
@@ -97,7 +97,7 @@ static void ResetClientState(int clientIndex)
 */
 cl-GLClientmajorVersion = 1;
 cl-GLClientminorVersion = 0;
-if (cl-GLClientextensions) free(cl-GLClientextensions);
+free(cl-GLClientextensions);
 
 memset(cl-be_displays, 0, screenInfo.numScreens * sizeof(Display *));
 }
@@ -222,10 +222,10 @@ GLboolean __glXFreeContext(__GLXcontext *cx)
 {
 if (cx-idExists || cx-isCurrent) return GL_FALSE;
 
-if (cx-feedbackBuf) free(cx-feedbackBuf);
-if (cx-selectBuf) free(cx-selectBuf);
-if (cx-real_ids) free(cx-real_ids);
-if (cx-real_vids) free(cx-real_vids);
+free(cx-feedbackBuf);
+free(cx-selectBuf);
+free(cx-real_ids);
+free(cx-real_vids);
 
 if (cx-pGlxPixmap) {
/*
-- 
1.7.2.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] Extract LogFinishInit from LogInit

Mikhail Gusarov dotted...@dottedmag.net (08/11/2010):
   +if (saveBuffer) {
   +free(saveBuffer);/* Must be free(), not free() */
  CB 
 
  CB That probably can go away, see 3f3ff971.
 
 Right, as well as if (saveBuffer).

That reminded me I wanted to give Coccinelle a try. Just sent two
patches trying to fix most obvious if(foo[!=NULL]) free(foo) cases.

Mraw,
KiBi.


signature.asc
Description: Digital 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 xserver 1/9] Create/Destroy/Trigger/Reset Fence Sync objects

On Tue, 2010-09-21 at 16:32 -0700, James Jones wrote:

 +static int
 +FreeFence(void *obj, XID id)
 +{
 +SyncFence *pFence = (SyncFence *) obj;
 +
 +free(pFence);
 +
 +return Success;
 +}

Seems wordy, but sure.

- ajax

___
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 xserver 3/9] Create SyncObject base type.

On Tue, 2010-09-21 at 16:32 -0700, James Jones wrote:

 diff --git a/Xext/syncsrv.h b/Xext/syncsrv.h
 index a805f28..cc104ff 100644
 --- a/Xext/syncsrv.h
 +++ b/Xext/syncsrv.h
 @@ -53,15 +53,30 @@ PERFORMANCE OF THIS SOFTWARE.
  
  #define CARD64 XSyncValue /* XXX temporary! need real 64 bit values for 
 Alpha */
  
 -typedef struct _SyncCounter {
 +/* Sync object types */
 +#define SYNC_COUNTER 0
 +#define SYNC_FENCE   1
 +
 +typedef struct _SyncObject {
  ClientPtrclient; /* Owning client. 0 for system counters 
 */
 -XSyncCounter id; /* resource ID */
 -CARD64   value;  /* counter value */
 +XID  id; /* resource ID */
  struct _SyncTriggerList *pTriglist;  /* list of triggers */
 -Bool beingDestroyed; /* in process of going away */
 +unsigned chartype;   /* SYNC_* */
 +Bool beingDestroyed; /* in process of going away */
 +} SyncObject;

20 bytes on ILP32, 32 on LP64, lots of holes.  Do this instead?

typedef struct _SyncObject {
ClientPtr client;
struct _SyncTriggerList *pTriglist;
XID id;
unsigned char type;
unsigned char beingDestroyed;
} SyncObject; 

14+2 on ILP32, 22+2 on LP64 (+2 for the padding at the end).  Not that I
expect to have huge numbers of fences but might as well get it right.

- ajax

___
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 xserver 7/9] Add XDamageSubtractAndTrigger operation

On Tue, 2010-09-21 at 16:32 -0700, James Jones wrote:

  COPYING |2 +-
  Xext/sync.c |   27 +++---
  Xext/syncsrv.h  |   68 ++
  configure.ac|   21 ++-
  damageext/damageext.c   |   64 +++--
  include/protocol-versions.h |2 +-
  miext/Makefile.am   |4 +-
  miext/X/Makefile.am |   14 +++
  miext/X/misync.c|   44 ++
  miext/X/misync.h|   36 ++
  miext/X/misyncstr.h |   84 
 +++

miext/ subdirs should be named after their functionality, this should
probably be miext/sync/.

- ajax

___
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] Multi-Touch (MT) support - arbitration or not

2010-11-08 Thread Ping Cheng

On Mon, Nov 8, 2010 at 1:54 PM, Chris Bagwell ch...@cnpbagwell.com wrote:
 I think we may be mixing some topics and so I'd like to try to
 re-frame the discussion.

 There are two different cases and they may have different answers
 because of it.

I'd like to cover both cases with an unified answer. There is only one
physical device no matter which case we are in, especially in the
kernel. The only difference is whether it is a serial or USB device.
So, my comments applies to both types of devices.

 Case 1) 1 input device can support multiple tools that are in
 proximity at same time.

 I believe this is currently a theoretical example (no driver exists like 
 this).

 In RFC example, this input devices has a pen and 2 finger touches.
 They all share ABS_X/Y/PRESSURE values.  The single touch (ST) input
 filtering breaks being able to support this case and what multitouch
 events (MT) were added for.

 To date, when converting drivers over to MT events the guideline is
 *always* send MT events (because what app wants to randomly switch
 between MT event processing and ST event processing for same
 X/Y/PRESSURE?) and send something sane for ST events to be backwards
 compatible with older apps.

 I think everyone is happy in this thread to always send pen+touch MT
 events and let X drivers or similar filter/arbitrate out unwanted
 touch events as needed.

Ok, the done deal so far is: we'll send MT events regardless of pen position.

 The ideal sane behavior for touch ST events has been leaning towards
 tracking 1st touch and continue sending 1st touch during multi-touch
 but there is some debate because tracking can be expensive in kernel.
 In case of pen+touch, the sane may change to prefer pen over touch and
 prefer first touch when 2 touches exist.

 Or sane can mean let the ST values go crazy during multi-touch and
 hope user can use GUI enough after new kernel install to get a
 MT-aware X driver.

 Its easy to implement preferring pen then preferring 1st touch so I
 suggest doing that.  This is for backwards compatibility only
 (un-modified xf86-input-wacom/synaptics/evdev/etc).  The future is MT
 events, in which case the ST events are meaningless and we are hiding
 nothing to applications that look at MT events.

 Case 2) 2 input devices can support multiple tools in proximity at same time.

 I believe it was Rafi that brought up point that dual pen+touch
 interfaces will have different properties.  Touch will be lower
 resolution then Pen and maybe different fuzz factor.  Also, on tablets
 I would think pretty easy to have different dimensions (one tool works
 over larger area of tablet).  This is easy to expose to user when 2
 input devices.

Kernel driver doesn't need to worry about this detail. X server driver
or clients should take care of them. Each tool has . Dual pen+touch
(ST) has been supported for a while

 Combining into single input to user would be nice but at least when
 dimensions are different, we probably do not want to remove that
 visibility to user and so must keep 2 input devices.

 In this case, the RFC example becomes 2 touches on 1 input device and
 1 pen on another input device.

 So using same MT guidelines, the touch input device would always send
 MT events and always send ST events tracking the first touch.

 For pen input, ST-only events are OK because its not competing with
 anything being in proximity at same time.  But we may wish to also
 send MT events for this 1 tool/slot as a hint to X drivers that
 somehow this input corresponds with another input device and so it
 needs to do filtering/arbitration.  We also need to somehow give info
 to applications so they can bind these 2 inputs.

 Also, non-MT ware drivers are also same apps that will not know how to
 bind 2 input devices and so can't filter/arbitrate the unwanted
 touches.  So problem, we do want to filter ST events on touch input
 when pen is in proximity.

Filtering touch events when pen is in prox is reasonable for existing
apps. We will add a new property in the X driver so future MT-aware
apps can turn ST/cursor events on/off when necessary. By default, the
ST/cursor will be on to support backward compatibility.

 There are lots of things needing to be addressed for this 2nd case so
 I'll not really give a personal opinion.  My opinion is likely to
 change as we make individual decisions.

You'll see that my opinion changes too. That's why we need this [RFC] ;).

I still have one decision to make though:

Do we really want to repeat the pen data with MT_TOOL_PEN? It is
already reported by ST events.

From my comments for proposal #4, you can tell that I was in favor of
repeating them. After comparing #2 with #4 a bit further, I see both
options have its pros and cons.

Which way should we go? #2 or #4?

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

Re: [PATCH 1/2] Remove more superfluous if(p) checks around free(p).

2010-11-08 Thread Matt Turner

On Mon, Nov 8, 2010 at 5:35 PM, Cyril Brulebois k...@debian.org wrote:
 This patch has been generated by the following Coccinelle semantic patch:

 @@
 expression E;
 @@
 - if (E)
 -   free(E);
 + free(E);

 Signed-off-by: Cyril Brulebois k...@debian.org
 ---
  hw/dmx/glxProxy/glxcmds.c |    2 +-
  hw/dmx/glxProxy/glxext.c  |   18 +-
  2 files changed, 10 insertions(+), 10 deletions(-)

 diff --git a/hw/dmx/glxProxy/glxcmds.c b/hw/dmx/glxProxy/glxcmds.c
 index a9744e1..7602128 100644
 --- a/hw/dmx/glxProxy/glxcmds.c
 +++ b/hw/dmx/glxProxy/glxcmds.c
 @@ -2565,7 +2565,7 @@ int __glXClientInfo(__GLXclientState *cl, GLbyte *pc)

     cl-GLClientmajorVersion = req-major;
     cl-GLClientminorVersion = req-minor;
 -    if (cl-GLClientextensions) free(cl-GLClientextensions);
 +    free(cl-GLClientextensions);
     buf = (const char *)(req+1);
     cl-GLClientextensions = strdup(buf);

 diff --git a/hw/dmx/glxProxy/glxext.c b/hw/dmx/glxProxy/glxext.c
 index a8fc0a8..886b317 100644
 --- a/hw/dmx/glxProxy/glxext.c
 +++ b/hw/dmx/glxProxy/glxext.c
 @@ -77,10 +77,10 @@ static void ResetClientState(int clientIndex)
     Display **keep_be_displays;
     int i;

 -    if (cl-returnBuf) free(cl-returnBuf);
 -    if (cl-currentContexts) free(cl-currentContexts);
 -    if (cl-currentDrawables) free(cl-currentDrawables);
 -    if (cl-largeCmdBuf) free(cl-largeCmdBuf);
 +    free(cl-returnBuf);
 +    free(cl-currentContexts);
 +    free(cl-currentDrawables);
 +    free(cl-largeCmdBuf);

     for (i=0; i screenInfo.numScreens; i++) {
        if (cl-be_displays[i])
 @@ -97,7 +97,7 @@ static void ResetClientState(int clientIndex)
     */
     cl-GLClientmajorVersion = 1;
     cl-GLClientminorVersion = 0;
 -    if (cl-GLClientextensions) free(cl-GLClientextensions);
 +    free(cl-GLClientextensions);

     memset(cl-be_displays, 0, screenInfo.numScreens * sizeof(Display *));
  }
 @@ -222,10 +222,10 @@ GLboolean __glXFreeContext(__GLXcontext *cx)
  {
     if (cx-idExists || cx-isCurrent) return GL_FALSE;

 -    if (cx-feedbackBuf) free(cx-feedbackBuf);
 -    if (cx-selectBuf) free(cx-selectBuf);
 -    if (cx-real_ids) free(cx-real_ids);
 -    if (cx-real_vids) free(cx-real_vids);
 +    free(cx-feedbackBuf);
 +    free(cx-selectBuf);
 +    free(cx-real_ids);
 +    free(cx-real_vids);

     if (cx-pGlxPixmap) {
        /*
 --
 1.7.2.3

Man, more of these?

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 2/2] Remove more superfluous if(p!=NULL) checks around free(p).

2010-11-08 Thread Matt Turner

On Mon, Nov 8, 2010 at 5:35 PM, Cyril Brulebois k...@debian.org wrote:
 This patch has been generated by the following Coccinelle semantic patch:

 @@
 expression E;
 @@
 - if (E != NULL)
 -   free(E);
 + free(E);

 Signed-off-by: Cyril Brulebois k...@debian.org
 ---
  dix/grabs.c                     |    7 ++-
  glx/single2.c                   |    3 +--
  hw/xfree86/modes/xf86Crtc.c     |    3 +--
  mi/mispans.c                    |    2 +-
  miext/rootless/rootlessScreen.c |    3 +--
  os/log.c                        |    6 ++
  xkb/XKBMAlloc.c                 |    6 ++
  xkb/ddxLoad.c                   |    6 ++
  8 files changed, 12 insertions(+), 24 deletions(-)

 diff --git a/dix/grabs.c b/dix/grabs.c
 index f850e3d..69c58df 100644
 --- a/dix/grabs.c
 +++ b/dix/grabs.c
 @@ -117,11 +117,8 @@ CreateGrab(
  static void
  FreeGrab(GrabPtr pGrab)
  {
 -    if (pGrab-modifiersDetail.pMask != NULL)
 -       free(pGrab-modifiersDetail.pMask);
 -
 -    if (pGrab-detail.pMask != NULL)
 -       free(pGrab-detail.pMask);
 +    free(pGrab-modifiersDetail.pMask);
 +    free(pGrab-detail.pMask);

     if (pGrab-cursor)
        FreeCursor(pGrab-cursor, (Cursor)0);
 diff --git a/glx/single2.c b/glx/single2.c
 index 56ad86d..f93ce6e 100644
 --- a/glx/single2.c
 +++ b/glx/single2.c
 @@ -377,8 +377,7 @@ int DoGetString(__GLXclientState *cl, GLbyte *pc, 
 GLboolean need_swap)

     __GLX_SEND_HEADER();
     WriteToClient(client, length, (char *) string);
 -    if (buf != NULL)
 -       free(buf);
 +    free(buf);

     return Success;
  }
 diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
 index b2daec7..7fc2a60 100644
 --- a/hw/xfree86/modes/xf86Crtc.c
 +++ b/hw/xfree86/modes/xf86Crtc.c
 @@ -2964,8 +2964,7 @@ xf86OutputSetEDID (xf86OutputPtr output, xf86MonPtr 
 edid_mon)
     int                        size;
  #endif

 -    if (output-MonInfo != NULL)
 -       free(output-MonInfo);
 +    free(output-MonInfo);

     output-MonInfo = edid_mon;

 diff --git a/mi/mispans.c b/mi/mispans.c
 index 9f56e3c..53539e5 100644
 --- a/mi/mispans.c
 +++ b/mi/mispans.c
 @@ -215,7 +215,7 @@ void miAppendSpans(SpanGroup *spanGroup, SpanGroup 
 *otherGroup, Spans *spans)

  void miFreeSpanGroup(SpanGroup *spanGroup)
  {
 -    if (spanGroup-group != NULL) free(spanGroup-group);
 +    free(spanGroup-group);
  }

  static void QuickSortSpansX(
 diff --git a/miext/rootless/rootlessScreen.c b/miext/rootless/rootlessScreen.c
 index 43b9cbb..61d2f5d 100644
 --- a/miext/rootless/rootlessScreen.c
 +++ b/miext/rootless/rootlessScreen.c
 @@ -92,8 +92,7 @@ RootlessUpdateScreenPixmap(ScreenPtr pScreen)
     rowbytes = PixmapBytePad(pScreen-width, pScreen-rootDepth);

     if (s-pixmap_data_size  rowbytes) {
 -        if (s-pixmap_data != NULL)
 -            free(s-pixmap_data);
 +        free(s-pixmap_data);

         s-pixmap_data_size = rowbytes;
         s-pixmap_data = malloc(s-pixmap_data_size);
 diff --git a/os/log.c b/os/log.c
 index ee4b45f..7d10783 100644
 --- a/os/log.c
 +++ b/os/log.c
 @@ -489,8 +489,7 @@ AuditFlush(OsTimerPtr timer, CARD32 now, pointer arg)
        ErrorF(%slast message repeated %d times\n,
               prefix != NULL ? prefix : , nrepeat);
        nrepeat = 0;
 -       if (prefix != NULL)
 -           free(prefix);
 +       free(prefix);
        return AUDIT_TIMEOUT;
     } else {
        /* if the timer expires without anything to print, flush the message */
 @@ -523,8 +522,7 @@ VAuditF(const char *f, va_list args)
        nrepeat = 0;
        auditTimer = TimerSet(auditTimer, 0, AUDIT_TIMEOUT, AuditFlush, NULL);
     }
 -    if (prefix != NULL)
 -       free(prefix);
 +    free(prefix);
  }

  void
 diff --git a/xkb/XKBMAlloc.c b/xkb/XKBMAlloc.c
 index 6b186c1..e9afe31 100644
 --- a/xkb/XKBMAlloc.c
 +++ b/xkb/XKBMAlloc.c
 @@ -292,11 +292,9 @@ KeyCode            
 matchingKeys[XkbMaxKeyCount],nMatchingKeys;
     }
     type= xkb-map-types[type_ndx];
     if (map_count==0) {
 -       if (type-map!=NULL)
 -           free(type-map);
 +       free(type-map);
        type-map= NULL;
 -       if (type-preserve!=NULL)
 -           free(type-preserve);
 +       free(type-preserve);
        type-preserve= NULL;
        type-map_count= 0;
     }
 diff --git a/xkb/ddxLoad.c b/xkb/ddxLoad.c
 index 5e6ab87..cfc6198 100644
 --- a/xkb/ddxLoad.c
 +++ b/xkb/ddxLoad.c
 @@ -267,8 +267,7 @@ XkbDDXCompileKeymapByNames( XkbDescPtr              xkb,
                strncpy(nameRtrn,keymap,nameRtrnLen);
                nameRtrn[nameRtrnLen-1]= '\0';
            }
 -            if (buf != NULL)
 -                free(buf);
 +            free(buf);
            return TRUE;
        }
        else
 @@ -287,8 +286,7 @@ XkbDDXCompileKeymapByNames( XkbDescPtr              xkb,
     }
     if (nameRtrn)
        nameRtrn[0]= '\0';
 -    if (buf != NULL)
 -        free(buf);
 +    free(buf);
     return FALSE;
  }

 --
 1.7.2.3

Reviewed-by: Matt Turner matts...@gmail.com

Re: [PATCH xorg-docs 3/3] Add Makefile XML profiling support

2010-11-08 Thread Gaetan Nadon

On Fri, 2010-11-05 at 20:27 -0700, Alan Coopersmith wrote:

 When I tried building with this series, plus
 [PATCH sgml-doctools] Set stylesheet to provide XML profiling support
 
 I got:
 runtime error: file /usr/X11R7/share/sgml/X11/xorg.xsl line 254 element
 call-template
 The called template 'add-xml-base' was not found.
 
 (/usr/X11R7 being the --prefix I use for my git builds to keep them
  separate from the OS-packaged builds.)
 


One solution is to add the following import to xorg.xsl which contains
the missing template:

!-- This file must be included, because xorg.xsl is using templates 
from it --
xsl:import 
href=http://docbook.sourceforge.net/release/xsl/current/common/stripns.xsl/

Another solution is to remove the following instructions:

  !-- xml:base is eventually added to the root element --
  xsl:if test=not(../..) and $profile.baseuri.fixup
xsl:call-template name=add-xml-base/
  /xsl:if

The libxslt1.1 does not support adding an xml:base attribute to a node
set root element[0].
This is why I get the cannot add @xml:base to node set root element.
Relative paths may not work.
warning message. Docbook v5 has namespace aware stylesheet in
docbook-xsl-ns. Removing theese instructions
 makes the warning go away.

Would any of these solutions work for you?




signature.asc
Description: This is a digitally signed message part
___
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 sgml-doctools] Upgrade xorg-sgml-doctools to Autoconf 2.60 directory architecture

2010-11-08 Thread Alan Coopersmith

Gaetan Nadon wrote:
 Currently the value of sgmlrootdir is hard coded relative to $prefix.
 In Autoconf 2.60, $datarootdir has been added to define the architecture
 independent data directory.
 
   --datarootdir=DIR   read-only arch.-independent data root [PREFIX/share]
 
 Relative to that location, a number of subdirectories have been defined:
 
   --datadir=DIR  read-only architecture-independent data [DATAROOTDIR]
   --infodir=DIR  info documentation [DATAROOTDIR/info]
   --localedir=DIRlocale-dependent data [DATAROOTDIR/locale]
   --mandir=DIR   man documentation [DATAROOTDIR/man]
   --docdir=DIR   documentation root
  [DATAROOTDIR/doc/xorg-sgml-doctools]
   --htmldir=DIR  html documentation [DOCDIR]
   --dvidir=DIR   dvi documentation [DOCDIR]
   --pdfdir=DIR   pdf documentation [DOCDIR]
   --psdir=DIRps documentation [DOCDIR]
 
 The sgmlrootdir should hang off datarootdir. If there is a need to specify
 a different location, a new configure option should be added:
 
   --sgmldir=DIR  sgml stylesheets and entities [DATAROOTDIR/sgml]
 
 An sgmlrootdir Automake variable is defined in configure.ac to provide
 a unique value holder for the sgmlrootdir.
 
 Variable PACKAGE_VERSION is preferred over the undocumented VERSION variable.
 
 Signed-off-by: Gaetan Nadon mems...@videotron.ca
 ---
  Makefile.am  |2 +-
  configure.ac |2 ++
  xorg-sgml-doctools.pc.in |7 ---
  3 files changed, 7 insertions(+), 4 deletions(-)
 
 diff --git a/Makefile.am b/Makefile.am
 index 049abac..e3fcca5 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -19,7 +19,7 @@
  #  TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  #  PERFORMANCE OF THIS SOFTWARE.
  
 -sgmldir = $(prefix)/share/sgml/X11
 +sgmldir = $(sgmlrootdir)/X11
  
  dist_sgml_DATA = defs.ent xorg.css xorg.xsl
  
 diff --git a/configure.ac b/configure.ac
 index 6ca9198..9a05526 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -34,6 +34,8 @@ m4_ifndef([XORG_MACROS_VERSION],
  XORG_MACROS_VERSION(1.3)
  XORG_DEFAULT_OPTIONS
  
 +AC_SUBST([sgmlrootdir],['${datarootdir}/sgml'])
 +
  AC_PROG_INSTALL
  
  AC_OUTPUT([
 diff --git a/xorg-sgml-doctools.pc.in b/xorg-sgml-doctools.pc.in
 index ae1422a..9546fa7 100644
 --- a/xorg-sgml-doctools.pc.in
 +++ b/xorg-sgml-doctools.pc.in
 @@ -1,6 +1,7 @@
  pref...@prefix@
 -sgmlrootdir=${prefix}/share/sgml
 +datarootd...@datarootdir@
 +sgmlrootd...@sgmlrootdir@
  
  Name: xorg-sgml-doctools
 -Description: SGML entities for X.Org documentation
 -Version: @VERSION@
 +Description: Stylesheets and entities for X.Org documentation
 +Version: @PACKAGE_VERSION@

Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com

-- 
-Alan Coopersmith-alan.coopersm...@oracle.com
 Oracle Solaris Platform Engineering: X Window System

___
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 xserver (rev2) 5/9] Generalize comment above Sync CheckTriggered funcs

The comment referred only to counter sync objects
and did not include the new fence sync CheckTriggered
function.  Generalize the language so it applies
to all the CheckTriggered functions.

Signed-off-by: James Jones jajo...@nvidia.com
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
Reviewed-by: Robert Morell rmor...@nvidia.com
---
 Xext/sync.c |   21 +++--
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/Xext/sync.c b/Xext/sync.c
index 7cff365..77ad461 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -184,17 +184,18 @@ SyncAddTriggerToSyncObject(SyncTrigger *pTrigger)
 }
 
 
-/*  Below are four possible functions that can be plugged into
- *  pTrigger-CheckTrigger, corresponding to the four possible
- *  test-types.  These functions are called after the counter's
- *  value changes but are also passed the old counter value
- *  so they can inspect both the old and new values.
- *  (PositiveTransition and NegativeTransition need to see both
- *  pieces of information.)  These functions return the truth value
- *  of the trigger.
+/*  Below are five possible functions that can be plugged into
+ *  pTrigger-CheckTrigger for counter sync objects, corresponding to
+ *  the four possible test-types, and the one possible function that
+ *  can be plugged into pTrigger-CheckTrigger for fence sync objects.
+ *  These functions are called after the sync object's state changes
+ *  but are also passed the old state so they can inspect both the old
+ *  and new values.  (PositiveTransition and NegativeTransition need to
+ *  see both pieces of information.)  These functions return the truth
+ *  value of the trigger.
  *
- *  All of them include the condition pTrigger-pCounter == NULL.
- *  This is because the spec says that a trigger with a counter value
+ *  All of them include the condition pTrigger-pSync == NULL.
+ *  This is because the spec says that a trigger with a sync value
  *  of None is always TRUE.
  */
 
-- 
1.7.1

___
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 xserver (rev2) 3/9] Create SyncObject base type.

SyncObject is now the base type for SyncCounter
and SyncFence.  Data to be used by both types is
stored in the base object.  Both SyncCounter and
SyncFence can be safely cast to SyncObject, and
a SyncObject can be cast to the correct type
based on SyncObject::type.

Signed-off-by: James Jones jajo...@nvidia.com
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
Reviewed-by: Robert Morell rmor...@nvidia.com
---
 Xext/sync.c|  111 ++--
 Xext/syncsrv.h |   30 ++--
 2 files changed, 87 insertions(+), 54 deletions(-)

diff --git a/Xext/sync.c b/Xext/sync.c
index 16daa63..0c6de8d 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -90,7 +90,7 @@ static int SyncNumSystemCounters = 0;
 static SyncCounter **SysCounterList = NULL;
 
 #define IsSystemCounter(pCounter) \
-(pCounter  (pCounter-client == NULL))
+(pCounter  (pCounter-sync.client == NULL))
 
 /* these are all the alarm attributes that pertain to the alarm's trigger */
 #define XSyncCAAllTrigger \
@@ -119,7 +119,7 @@ SyncDeleteTriggerFromCounter(SyncTrigger *pTrigger)
return;
 
 pPrev = NULL;
-pCur = pTrigger-pCounter-pTriglist;
+pCur = pTrigger-pCounter-sync.pTriglist;
 
 while (pCur)
 {
@@ -128,7 +128,7 @@ SyncDeleteTriggerFromCounter(SyncTrigger *pTrigger)
if (pPrev)
pPrev-next = pCur-next;
else
-   pTrigger-pCounter-pTriglist = pCur-next;
+   pTrigger-pCounter-sync.pTriglist = pCur-next;
 
free(pCur);
break;
@@ -152,7 +152,7 @@ SyncAddTriggerToCounter(SyncTrigger *pTrigger)
return Success;
 
 /* don't do anything if it's already there */
-for (pCur = pTrigger-pCounter-pTriglist; pCur; pCur = pCur-next)
+for (pCur = pTrigger-pCounter-sync.pTriglist; pCur; pCur = pCur-next)
 {
if (pCur-pTrigger == pTrigger)
return Success;
@@ -162,8 +162,8 @@ SyncAddTriggerToCounter(SyncTrigger *pTrigger)
return BadAlloc;
 
 pCur-pTrigger = pTrigger;
-pCur-next = pTrigger-pCounter-pTriglist;
-pTrigger-pCounter-pTriglist = pCur;
+pCur-next = pTrigger-pCounter-sync.pTriglist;
+pTrigger-pCounter-sync.pTriglist = pCur;
 
 if (IsSystemCounter(pTrigger-pCounter))
SyncComputeBracketValues(pTrigger-pCounter);
@@ -391,14 +391,14 @@ SyncSendCounterNotifyEvents(ClientPtr client, SyncAwait 
**ppAwait,
SyncTrigger *pTrigger = (*ppAwait)-trigger;
pev-type = SyncEventBase + XSyncCounterNotify;
pev-kind = XSyncCounterNotify;
-   pev-counter = pTrigger-pCounter-id;
+   pev-counter = pTrigger-pCounter-sync.id;
pev-wait_value_lo = XSyncValueLow32(pTrigger-test_value);
pev-wait_value_hi = XSyncValueHigh32(pTrigger-test_value);
pev-counter_value_lo = XSyncValueLow32(pTrigger-pCounter-value);
pev-counter_value_hi = XSyncValueHigh32(pTrigger-pCounter-value);
pev-time = currentTime.milliseconds;
pev-count = num_events - i - 1; /* events remaining */
-   pev-destroyed = pTrigger-pCounter-beingDestroyed;
+   pev-destroyed = pTrigger-pCounter-sync.beingDestroyed;
 }
 /* swapping will be taken care of by this */
 WriteEventsToClient(client, num_events, (xEvent *)pEvents);
@@ -533,7 +533,7 @@ SyncAwaitTriggerFired(SyncTrigger *pTrigger)
 *  always generated if the counter for one of the triggers is
 *  destroyed.
 */
-   if (pAwait-trigger.pCounter-beingDestroyed)
+   if (pAwait-trigger.pCounter-sync.beingDestroyed)
{
ppAwait[num_events++] = pAwait;
continue;
@@ -601,7 +601,7 @@ SyncChangeCounter(SyncCounter *pCounter, CARD64 newval)
 pCounter-value = newval;
 
 /* run through triggers to see if any become true */
-for (ptl = pCounter-pTriglist; ptl; ptl = pnext)
+for (ptl = pCounter-sync.pTriglist; ptl; ptl = pnext)
 {
pnext = ptl-next;
if ((*ptl-pTrigger-CheckTrigger)(ptl-pTrigger, oldval))
@@ -693,7 +693,8 @@ SyncChangeAlarmAttributes(ClientPtr client, SyncAlarm 
*pAlarm, Mask mask,
 XSyncCounter   counter;
 Mask  origmask = mask;
 
-counter = pAlarm-trigger.pCounter ? pAlarm-trigger.pCounter-id : None;
+counter =
+   pAlarm-trigger.pCounter ? pAlarm-trigger.pCounter-sync.id : None;
 
 while (mask)
 {
@@ -782,26 +783,56 @@ SyncChangeAlarmAttributes(ClientPtr client, SyncAlarm 
*pAlarm, Mask mask,
 return Success;
 }
 
-
-static SyncCounter *
-SyncCreateCounter(ClientPtr client, XSyncCounter id, CARD64 initialvalue)
+static SyncObject *
+SyncCreate(ClientPtr client, XID id, unsigned char type)
 {
-SyncCounter *pCounter;
+SyncObject *pSync;
+RESTYPE resType;
+unsigned long syncSize;
 
-if (!(pCounter = malloc(sizeof(SyncCounter
+switch (type) {
+case SYNC_COUNTER:
+   resType = RTCounter;
+   syncSize = sizeof(SyncCounter);
+   break;
+case SYNC_FENCE:

[PATCH xserver (rev2) 2/9] Add XSyncQueryFence()

Allows callers to query whether or not a given
fence sync object is currently triggered.

Signed-off-by: James Jones jajo...@nvidia.com
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
Reviewed-by: Robert Morell rmor...@nvidia.com
---
 Xext/sync.c |   49 +
 1 files changed, 49 insertions(+), 0 deletions(-)

diff --git a/Xext/sync.c b/Xext/sync.c
index 147eab8..16daa63 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -1836,6 +1836,38 @@ ProcSyncDestroyFence(ClientPtr client)
 return client-noClientException;
 }
 
+static int
+ProcSyncQueryFence(ClientPtr client)
+{
+REQUEST(xSyncQueryFenceReq);
+xSyncQueryFenceReply rep;
+SyncFence *pFence;
+int rc;
+
+REQUEST_SIZE_MATCH(xSyncQueryFenceReq);
+
+rc = dixLookupResourceByType((pointer *)pFence, stuff-fid,
+RTFence, client, DixReadAccess);
+if (rc != Success)
+   return rc;
+
+rep.type = X_Reply;
+rep.length = 0;
+rep.sequenceNumber = client-sequence;
+
+rep.triggered = pFence-triggered;
+
+if (client-swapped)
+{
+   char n;
+   swaps(rep.sequenceNumber, n);
+   swapl(rep.length, n);
+}
+
+WriteToClient(client, sizeof(xSyncQueryFenceReply), (char *) rep);
+return client-noClientException;
+}
+
 /*
  * ** Given an extension request, call the appropriate request procedure
  */
@@ -1882,6 +1914,8 @@ ProcSyncDispatch(ClientPtr client)
return ProcSyncResetFence(client);
   case X_SyncDestroyFence:
return ProcSyncDestroyFence(client);
+  case X_SyncQueryFence:
+   return ProcSyncQueryFence(client);
   default:
return BadRequest;
 }
@@ -2134,6 +2168,19 @@ SProcSyncDestroyFence(ClientPtr client)
 }
 
 static int
+SProcSyncQueryFence(ClientPtr client)
+{
+REQUEST(xSyncQueryFenceReq);
+char   n;
+
+swaps(stuff-length, n);
+REQUEST_SIZE_MATCH (xSyncQueryFenceReq);
+swapl(stuff-fid, n);
+
+return ProcSyncQueryFence(client);
+}
+
+static int
 SProcSyncDispatch(ClientPtr client)
 {
 REQUEST(xReq);
@@ -2176,6 +2223,8 @@ SProcSyncDispatch(ClientPtr client)
return SProcSyncResetFence(client);
   case X_SyncDestroyFence:
return SProcSyncDestroyFence(client);
+  case X_SyncQueryFence:
+   return SProcSyncQueryFence(client);
   default:
return BadRequest;
 }
-- 
1.7.1

___
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 xserver (rev2) 8/9] Add fence sync driver interface

-Add devPrivates to fence sync objects.

-Add a X sync module screen private

-Add wrappable functions to create and destroy
 fence sync objects

-Give fence sync objects wrappable functions to
 trigger, test, and reset their 'triggered' value.

-Give fence sync objects wrappable functions to
 notify driver when adding/removing triggers to/
 from the sync object.

Signed-off-by: James Jones jajo...@nvidia.com
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
Reviewed-by: Robert Morell rmor...@nvidia.com
---
 Xext/sync.c  |   38 +++
 dix/privates.c   |1 +
 hw/xfree86/loader/sdksyms.sh |3 +
 include/privates.h   |1 +
 miext/sync/misync.c  |  147 +-
 miext/sync/misync.h  |   43 -
 miext/sync/misyncstr.h   |6 +-
 7 files changed, 222 insertions(+), 17 deletions(-)

diff --git a/Xext/sync.c b/Xext/sync.c
index 9b087f6..3ca4d68 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -59,7 +59,7 @@ PERFORMANCE OF THIS SOFTWARE.
 #include X11/X.h
 #include X11/Xproto.h
 #include X11/Xmd.h
-#include misc.h
+#include scrnintstr.h
 #include os.h
 #include extnsionst.h
 #include dixstruct.h
@@ -145,6 +145,9 @@ SyncDeleteTriggerFromSyncObject(SyncTrigger *pTrigger)
 
if (IsSystemCounter(pCounter))
SyncComputeBracketValues(pCounter);
+} else if (SYNC_FENCE == pTrigger-pSync-type) {
+   SyncFence* pFence = (SyncFence*) pTrigger-pSync;
+   pFence-funcs.DeleteTrigger(pTrigger);
 }
 }
 
@@ -178,6 +181,9 @@ SyncAddTriggerToSyncObject(SyncTrigger *pTrigger)
 
if (IsSystemCounter(pCounter))
SyncComputeBracketValues(pCounter);
+} else if (SYNC_FENCE == pTrigger-pSync-type) {
+   SyncFence* pFence = (SyncFence*) pTrigger-pSync;
+   pFence-funcs.AddTrigger(pTrigger);
 }
 
 return Success;
@@ -252,10 +258,11 @@ SyncCheckTriggerNegativeTransition(SyncTrigger *pTrigger, 
CARD64 oldval)
 static Bool
 SyncCheckTriggerFence(SyncTrigger *pTrigger, CARD64 unused)
 {
+SyncFence* pFence = (SyncFence*) pTrigger-pSync;
 (void)unused;
 
-return (pTrigger-pSync == NULL ||
-   ((SyncFence *)pTrigger-pSync)-triggered);
+return (pFence == NULL ||
+   pFence-funcs.CheckTriggered(pFence));
 }
 
 static int
@@ -868,22 +875,22 @@ SyncCreate(ClientPtr client, XID id, unsigned char type)
 {
 SyncObject *pSync;
 RESTYPE resType;
-unsigned long syncSize;
 
 switch (type) {
 case SYNC_COUNTER:
resType = RTCounter;
-   syncSize = sizeof(SyncCounter);
+   pSync = malloc(sizeof(SyncCounter));
break;
 case SYNC_FENCE:
resType = RTFence;
-   syncSize = sizeof(SyncFence);
+   pSync = (SyncObject *)dixAllocateObjectWithPrivates(SyncFence,
+   PRIVATE_SYNC_FENCE);
break;
 default:
return NULL;
 }
 
-if (!(pSync = (SyncObject *)malloc(syncSize)))
+if (!pSync)
return NULL;
 
 if (!AddResource(id, resType, (pointer) pSync))
@@ -1909,8 +1916,7 @@ ProcSyncCreateFence(ClientPtr client)
   SYNC_FENCE)))
return BadAlloc;
 
-pFence-pScreen = pDraw-pScreen;
-pFence-triggered = stuff-initially_triggered;
+miSyncInitFence(pDraw-pScreen, pFence, stuff-initially_triggered);
 
 return client-noClientException;
 }
@@ -1930,7 +1936,9 @@ FreeFence(void *obj, XID id)
free(ptl); /* destroy the trigger list as we go */
 }
 
-free(pFence);
+miSyncDestroyFence(pFence);
+
+dixFreeObjectWithPrivates(pFence, PRIVATE_SYNC_FENCE);
 
 return Success;
 }
@@ -1980,10 +1988,10 @@ ProcSyncResetFence(ClientPtr client)
 if (rc != Success)
return rc;
 
-if (pFence-triggered != TRUE)
+if (pFence-funcs.CheckTriggered(pFence) != TRUE)
return BadMatch;
 
-pFence-triggered = FALSE;
+pFence-funcs.Reset(pFence);
 
 return client-noClientException;
 }
@@ -2025,7 +2033,7 @@ ProcSyncQueryFence(ClientPtr client)
 rep.length = 0;
 rep.sequenceNumber = client-sequence;
 
-rep.triggered = pFence-triggered;
+rep.triggered = pFence-funcs.CheckTriggered(pFence);
 
 if (client-swapped)
 {
@@ -2555,6 +2563,10 @@ void
 SyncExtensionInit(void)
 {
 ExtensionEntry *extEntry;
+ints;
+
+for (s = 0; s  screenInfo.numScreens; s++)
+   miSyncSetup(screenInfo.screens[s]);
 
 if (RTCounter == 0)
 {
diff --git a/dix/privates.c b/dix/privates.c
index 687fa7a..d651258 100644
--- a/dix/privates.c
+++ b/dix/privates.c
@@ -447,6 +447,7 @@ static const char *key_names[PRIVATE_LAST] = {
 [PRIVATE_GLYPH] = GLYPH,
 [PRIVATE_GLYPHSET] = GLYPHSET,
 [PRIVATE_PICTURE] = PICTURE,
+[PRIVATE_SYNC_FENCE] = SYNC_FENCE,
 };
 
 void
diff --git a/hw/xfree86/loader/sdksyms.sh b/hw/xfree86/loader/sdksyms.sh
index 6ca368e..ac3e59b 100755
---

[PATCH xserver (rev2) 6/9] Add XSyncAwaitFence() handler

-Add the actual ProcSyncAwaitFence() dispatch func

-Factor out some more common code from ProcSyncAwait()
 into SyncAwaitPrologue() and SyncAwaitEpilogue().  Call
 these from both Await functions.

-Check and handle triggers when triggering or freeing
 a fence sync object.

-Fix a few bugs in the previous refactoring changes.

Signed-off-by: James Jones jajo...@nvidia.com
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
Reviewed-by: Robert Morell rmor...@nvidia.com
---
 Xext/sync.c |  300 +++
 1 files changed, 219 insertions(+), 81 deletions(-)

diff --git a/Xext/sync.c b/Xext/sync.c
index 77ad461..aee2ca1 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -265,7 +265,7 @@ SyncInitTrigger(ClientPtr client, SyncTrigger *pTrigger, 
XID syncObject,
 SyncObject *pSync = pTrigger-pSync;
 SyncCounter *pCounter = NULL;
 intrc;
-Bool   newcounter = FALSE;
+Bool   newSyncObject = FALSE;
 
 if (changes  XSyncCACounter)
 {
@@ -281,7 +281,7 @@ SyncInitTrigger(ClientPtr client, SyncTrigger *pTrigger, 
XID syncObject,
{ /* new counter for trigger */
SyncDeleteTriggerFromSyncObject(pTrigger);
pTrigger-pSync = pSync;
-   newcounter = TRUE;
+   newSyncObject = TRUE;
}
 }
 
@@ -310,30 +310,37 @@ SyncInitTrigger(ClientPtr client, SyncTrigger *pTrigger, 
XID syncObject,
 
 if (changes  XSyncCATestType)
 {
-   if (pTrigger-test_type != XSyncPositiveTransition 
-   pTrigger-test_type != XSyncNegativeTransition 
-   pTrigger-test_type != XSyncPositiveComparison 
-   pTrigger-test_type != XSyncNegativeComparison)
+   if (SYNC_FENCE == pSync-type)
{
-   client-errorValue = pTrigger-test_type;
-   return BadValue;
+   pTrigger-CheckTrigger = SyncCheckTriggerFence;
}
-   /* select appropriate CheckTrigger function */
-
-   switch (pTrigger-test_type)
+   else
{
-case XSyncPositiveTransition:
-   pTrigger-CheckTrigger = SyncCheckTriggerPositiveTransition;
-   break;
-case XSyncNegativeTransition:
-   pTrigger-CheckTrigger = SyncCheckTriggerNegativeTransition;
-   break;
-case XSyncPositiveComparison:
-   pTrigger-CheckTrigger = SyncCheckTriggerPositiveComparison;
-   break;
-case XSyncNegativeComparison:
-   pTrigger-CheckTrigger = SyncCheckTriggerNegativeComparison;
-   break;
+   if (pTrigger-test_type != XSyncPositiveTransition 
+   pTrigger-test_type != XSyncNegativeTransition 
+   pTrigger-test_type != XSyncPositiveComparison 
+   pTrigger-test_type != XSyncNegativeComparison)
+   {
+   client-errorValue = pTrigger-test_type;
+   return BadValue;
+   }
+   /* select appropriate CheckTrigger function */
+
+   switch (pTrigger-test_type)
+   {
+   case XSyncPositiveTransition:
+   pTrigger-CheckTrigger = SyncCheckTriggerPositiveTransition;
+   break;
+   case XSyncNegativeTransition:
+   pTrigger-CheckTrigger = SyncCheckTriggerNegativeTransition;
+   break;
+   case XSyncPositiveComparison:
+   pTrigger-CheckTrigger = SyncCheckTriggerPositiveComparison;
+   break;
+   case XSyncNegativeComparison:
+   pTrigger-CheckTrigger = SyncCheckTriggerNegativeComparison;
+   break;
+   }
}
 }
 
@@ -360,7 +367,7 @@ SyncInitTrigger(ClientPtr client, SyncTrigger *pTrigger, 
XID syncObject,
 /*  we wait until we're sure there are no errors before registering
  *  a new counter on a trigger
  */
-if (newcounter)
+if (newSyncObject)
 {
if ((rc = SyncAddTriggerToSyncObject(pTrigger)) != Success)
return rc;
@@ -607,14 +614,7 @@ SyncAwaitTriggerFired(SyncTrigger *pTrigger)
continue;
}
 
-   if (SYNC_FENCE == pAwait-trigger.pSync-type)
-   {
-   SyncFence *pFence = (SyncFence *) pAwait-trigger.pSync;
-
-   if (pFence-triggered)
-   ppAwait[num_events++] = pAwait;
-   }
-   else if (SYNC_COUNTER == pAwait-trigger.pSync-type)
+   if (SYNC_COUNTER == pAwait-trigger.pSync-type)
{
SyncCounter *pCounter = (SyncCounter *) pAwait-trigger.pSync;
 
@@ -654,10 +654,6 @@ SyncAwaitTriggerFired(SyncTrigger *pTrigger)
ppAwait[num_events++] = pAwait;
}
}
-   else
-   {
-   FatalError(Invalid sync object type);
-   }
 }
 if (num_events)
SyncSendCounterNotifyEvents(pAwaitUnion-header.client, ppAwait,
@@ -1491,6 +1487,66 @@ ProcSyncDestroyCounter(ClientPtr client)
 return Success;
 }
 
+static SyncAwaitUnion*
+SyncAwaitPrologue(ClientPtr client, int items)
+{
+

[PATCH xserver (rev2) 4/9] Make Await SyncTrigger functions generic

Update all the functions dealing with Await
sync triggers handle generic sync objects
instead of just counters.  This will
facilitate code sharing between the counter
sync waits and the fence sync waits.

Signed-off-by: James Jones jajo...@nvidia.com
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
Reviewed-by: Robert Morell rmor...@nvidia.com
---
 Xext/sync.c|  312 +---
 Xext/syncsrv.h |2 +-
 2 files changed, 210 insertions(+), 104 deletions(-)

diff --git a/Xext/sync.c b/Xext/sync.c
index 0c6de8d..7cff365 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -108,18 +108,19 @@ static void SyncInitIdleTime(void);
  *  delete and add triggers on this list.
  */
 static void
-SyncDeleteTriggerFromCounter(SyncTrigger *pTrigger)
+SyncDeleteTriggerFromSyncObject(SyncTrigger *pTrigger)
 {
 SyncTriggerList *pCur;
 SyncTriggerList *pPrev;
+SyncCounter *pCounter;
 
-/* pCounter needs to be stored in pTrigger before calling here. */
+/* pSync needs to be stored in pTrigger before calling here. */
 
-if (!pTrigger-pCounter)
+if (!pTrigger-pSync)
return;
 
 pPrev = NULL;
-pCur = pTrigger-pCounter-sync.pTriglist;
+pCur = pTrigger-pSync-pTriglist;
 
 while (pCur)
 {
@@ -128,7 +129,7 @@ SyncDeleteTriggerFromCounter(SyncTrigger *pTrigger)
if (pPrev)
pPrev-next = pCur-next;
else
-   pTrigger-pCounter-sync.pTriglist = pCur-next;
+   pTrigger-pSync-pTriglist = pCur-next;
 
free(pCur);
break;
@@ -138,21 +139,27 @@ SyncDeleteTriggerFromCounter(SyncTrigger *pTrigger)
pCur = pCur-next;
 }
 
-if (IsSystemCounter(pTrigger-pCounter))
-   SyncComputeBracketValues(pTrigger-pCounter);
+if (SYNC_COUNTER == pTrigger-pSync-type)
+{
+   pCounter = (SyncCounter *)pTrigger-pSync;
+
+   if (IsSystemCounter(pCounter))
+   SyncComputeBracketValues(pCounter);
+}
 }
 
 
 static int
-SyncAddTriggerToCounter(SyncTrigger *pTrigger)
+SyncAddTriggerToSyncObject(SyncTrigger *pTrigger)
 {
 SyncTriggerList *pCur;
+SyncCounter *pCounter;
 
-if (!pTrigger-pCounter)
+if (!pTrigger-pSync)
return Success;
 
 /* don't do anything if it's already there */
-for (pCur = pTrigger-pCounter-sync.pTriglist; pCur; pCur = pCur-next)
+for (pCur = pTrigger-pSync-pTriglist; pCur; pCur = pCur-next)
 {
if (pCur-pTrigger == pTrigger)
return Success;
@@ -162,11 +169,16 @@ SyncAddTriggerToCounter(SyncTrigger *pTrigger)
return BadAlloc;
 
 pCur-pTrigger = pTrigger;
-pCur-next = pTrigger-pCounter-sync.pTriglist;
-pTrigger-pCounter-sync.pTriglist = pCur;
+pCur-next = pTrigger-pSync-pTriglist;
+pTrigger-pSync-pTriglist = pCur;
 
-if (IsSystemCounter(pTrigger-pCounter))
-   SyncComputeBracketValues(pTrigger-pCounter);
+if (SYNC_COUNTER == pTrigger-pSync-type)
+{
+   pCounter = (SyncCounter *)pTrigger-pSync;
+
+   if (IsSystemCounter(pCounter))
+   SyncComputeBracketValues(pCounter);
+}
 
 return Success;
 }
@@ -189,69 +201,100 @@ SyncAddTriggerToCounter(SyncTrigger *pTrigger)
 static Bool
 SyncCheckTriggerPositiveComparison(SyncTrigger *pTrigger, CARD64 oldval)
 {
-return (pTrigger-pCounter == NULL ||
-   XSyncValueGreaterOrEqual(pTrigger-pCounter-value,
-pTrigger-test_value));
+SyncCounter *pCounter;
+
+assert(!pTrigger-pSync || (SYNC_COUNTER == pTrigger-pSync-type));
+pCounter = (SyncCounter *)pTrigger-pSync;
+
+return (pCounter == NULL ||
+   XSyncValueGreaterOrEqual(pCounter-value, pTrigger-test_value));
 }
 
 static Bool
 SyncCheckTriggerNegativeComparison(SyncTrigger *pTrigger,  CARD64 oldval)
 {
-return (pTrigger-pCounter == NULL ||
-   XSyncValueLessOrEqual(pTrigger-pCounter-value,
- pTrigger-test_value));
+SyncCounter *pCounter;
+
+assert(!pTrigger-pSync || (SYNC_COUNTER == pTrigger-pSync-type));
+pCounter = (SyncCounter *)pTrigger-pSync;
+
+return (pCounter == NULL ||
+   XSyncValueLessOrEqual(pCounter-value, pTrigger-test_value));
 }
 
 static Bool
 SyncCheckTriggerPositiveTransition(SyncTrigger *pTrigger, CARD64 oldval)
 {
-return (pTrigger-pCounter == NULL ||
+SyncCounter *pCounter;
+
+assert(!pTrigger-pSync || (SYNC_COUNTER == pTrigger-pSync-type));
+pCounter = (SyncCounter *)pTrigger-pSync;
+
+return (pCounter == NULL ||
(XSyncValueLessThan(oldval, pTrigger-test_value) 
-XSyncValueGreaterOrEqual(pTrigger-pCounter-value,
- pTrigger-test_value)));
+XSyncValueGreaterOrEqual(pCounter-value, pTrigger-test_value)));
 }
 
 static Bool
 SyncCheckTriggerNegativeTransition(SyncTrigger *pTrigger, CARD64 oldval)
 {
-return (pTrigger-pCounter == NULL ||
+SyncCounter *pCounter;

[PATCH xserver (rev2) 9/9] Export SyncVerifyFence() in new SDK header

Add syncsdk.h, a new xorg SDK header.  It
contains SyncVerifyFence() and the helper
functions that use it to look up fence sync
objects.  Exporting this functionality in an
SDK header allows 3rd party extensions to
look up fence objects in their interop APIs.

Signed-off-by: James Jones jajo...@nvidia.com
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
Reviewed-by: Robert Morell rmor...@nvidia.com
---
 Xext/Makefile.am |3 +-
 Xext/sync.c  |1 +
 Xext/syncsdk.h   |   47 ++
 Xext/syncsrv.h   |   17 ---
 damageext/damageext.c|4 +-
 hw/xfree86/loader/sdksyms.sh |1 +
 6 files changed, 53 insertions(+), 20 deletions(-)
 create mode 100644 Xext/syncsdk.h

diff --git a/Xext/Makefile.am b/Xext/Makefile.am
index e444fd0..b6c95cb 100644
--- a/Xext/Makefile.am
+++ b/Xext/Makefile.am
@@ -15,7 +15,7 @@ INCLUDES = -I$(top_srcdir)/hw/xfree86/dixmods/extmod
 AM_CFLAGS = $(DIX_CFLAGS)
 
 if XORG
-sdk_HEADERS = xvdix.h xvmcext.h geext.h geint.h shmint.h
+sdk_HEADERS = xvdix.h xvmcext.h geext.h geint.h shmint.h syncsdk.h
 endif
 
 # Sources always included in libXextbuiltin.la  libXext.la
@@ -26,6 +26,7 @@ BUILTIN_SRCS =\
sleepuntil.c\
sleepuntil.h\
sync.c  \
+   syncsdk.h   \
syncsrv.h   \
xcmisc.c\
xtest.c
diff --git a/Xext/sync.c b/Xext/sync.c
index 3ca4d68..1af3b03 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -68,6 +68,7 @@ PERFORMANCE OF THIS SOFTWARE.
 #include opaque.h
 #include X11/extensions/syncproto.h
 #include syncsrv.h
+#include syncsdk.h
 
 #include stdio.h
 #if !defined(WIN32)
diff --git a/Xext/syncsdk.h b/Xext/syncsdk.h
new file mode 100644
index 000..a72c585
--- /dev/null
+++ b/Xext/syncsdk.h
@@ -0,0 +1,47 @@
+/*
+ * Copyright Â© 2010 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _SYNCSDK_H_
+#define _SYNCSDK_H_
+
+#include misync.h
+
+extern _X_EXPORT int
+SyncVerifyFence(SyncFence **ppFence, XID fid, ClientPtr client, Mask mode);
+
+#define VERIFY_SYNC_FENCE(pFence, fid, client, mode)   \
+do {   \
+   int rc; \
+   rc = SyncVerifyFence((pFence), (fid), (client), (mode));   \
+   if (Success != rc) return rc;   \
+} while (0)
+
+#define VERIFY_SYNC_FENCE_OR_NONE(pFence, fid, client, mode)   \
+do {   \
+pFence = 0;\
+if (None != fid)   \
+   VERIFY_SYNC_FENCE((pFence), (fid), (client), (mode));   \
+} while (0)
+
+#endif /* _SYNCSDK_H_ */
+
diff --git a/Xext/syncsrv.h b/Xext/syncsrv.h
index 14d6019..7ca1fba 100644
--- a/Xext/syncsrv.h
+++ b/Xext/syncsrv.h
@@ -140,23 +140,6 @@ extern void SyncDestroySystemCounter(
 pointer pCounter
 );
 
-extern int SyncVerifyFence(SyncFence **ppFence, XID fid,
-  ClientPtr client, Mask mode);
-
-#define VERIFY_SYNC_FENCE(pFence, fid, client, mode)   \
-do {   \
-   int rc; \
-   rc = SyncVerifyFence((pFence), (fid), (client), (mode));   \
-   if (Success != rc) return rc;   \
-} while (0)
-
-#define VERIFY_SYNC_FENCE_OR_NONE(pFence, fid, client, mode)   \
-do {   \
-pFence = 0;

[PATCH xserver (rev2) 7/9] Add XDamageSubtractAndTrigger operation

XDamageSubtractAndTrigger behaves exactly like
XDamageSubtract except it receives an optional
fence sync object.  If the value of this object
is not None, it is triggered by X once all the
rendering associated with the damage regions
being subtracted has completed.

Signed-off-by: James Jones jajo...@nvidia.com
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
Reviewed-by: Robert Morell rmor...@nvidia.com
---
 COPYING |2 +-
 Xext/sync.c |   27 +++---
 Xext/syncsrv.h  |   68 ++
 configure.ac|   21 ++-
 damageext/damageext.c   |   64 +++--
 include/protocol-versions.h |2 +-
 miext/Makefile.am   |4 +-
 miext/sync/Makefile.am  |   14 +++
 miext/sync/misync.c |   44 ++
 miext/sync/misync.h |   36 ++
 miext/sync/misyncstr.h  |   84 +++
 11 files changed, 280 insertions(+), 86 deletions(-)
 create mode 100644 miext/sync/Makefile.am
 create mode 100644 miext/sync/misync.c
 create mode 100644 miext/sync/misync.h
 create mode 100644 miext/sync/misyncstr.h

diff --git a/COPYING b/COPYING
index 3fb06b8..3aad5fa 100644
--- a/COPYING
+++ b/COPYING
@@ -14,7 +14,7 @@ Copyright Â© 2006-2007 Intel Corporation
 Copyright Â© 2006 Nokia Corporation
 Copyright Â© 2006-2008 Peter Hutterer
 Copyright Â© 2006 Adam Jackson
-Copyright Â© 2009 NVIDIA Corporation
+Copyright Â© 2009-2010 NVIDIA Corporation
 Copyright Â© 1999 Keith Packard
 Copyright Â© 2007-2009 Red Hat, Inc.
 Copyright Â© 2005-2008 Daniel Stone
diff --git a/Xext/sync.c b/Xext/sync.c
index aee2ca1..9b087f6 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -1935,13 +1935,23 @@ FreeFence(void *obj, XID id)
 return Success;
 }
 
+int SyncVerifyFence(SyncFence **ppSyncFence, XID fid,
+   ClientPtr client, Mask mode)
+{
+int rc = dixLookupResourceByType((pointer *)ppSyncFence, fid, RTFence,
+client, mode);
+
+if (rc != Success)
+   client-errorValue = fid;
+
+return rc;
+}
+
 static int
 ProcSyncTriggerFence(ClientPtr client)
 {
 REQUEST(xSyncTriggerFenceReq);
 SyncFence *pFence;
-SyncTriggerList *ptl, *pNext;
-CARD64 unused;
 int rc;
 
 REQUEST_SIZE_MATCH(xSyncTriggerFenceReq);
@@ -1951,17 +1961,7 @@ ProcSyncTriggerFence(ClientPtr client)
 if (rc != Success)
return rc;
 
-pFence-triggered = TRUE;
-
-XSyncIntToValue(unused, 0L);
-
-/* run through triggers to see if any fired */
-for (ptl = pFence-sync.pTriglist; ptl; ptl = pNext)
-{
-   pNext = ptl-next;
-   if ((*ptl-pTrigger-CheckTrigger)(ptl-pTrigger, unused))
-   (*ptl-pTrigger-TriggerFired)(ptl-pTrigger);
-}
+miSyncTriggerFence(pFence);
 
 return client-noClientException;
 }
@@ -2548,7 +2548,6 @@ SyncResetProc(ExtensionEntry *extEntry)
 RTCounter = 0;
 }
 
-
 /*
  * ** Initialise the extension.
  */
diff --git a/Xext/syncsrv.h b/Xext/syncsrv.h
index 99c8bf4..14d6019 100644
--- a/Xext/syncsrv.h
+++ b/Xext/syncsrv.h
@@ -51,31 +51,8 @@ PERFORMANCE OF THIS SOFTWARE.
 #ifndef _SYNCSRV_H_
 #define _SYNCSRV_H_
 
-#define CARD64 XSyncValue /* XXX temporary! need real 64 bit values for Alpha 
*/
-
-/* Sync object types */
-#define SYNC_COUNTER   0
-#define SYNC_FENCE 1
-
-typedef struct _SyncObject {
-ClientPtr  client; /* Owning client. 0 for system counters */
-struct _SyncTriggerList *pTriglist;/* list of triggers */
-XIDid; /* resource ID */
-unsigned char  type;   /* SYNC_* */
-Bool   beingDestroyed; /* in process of going away */
-} SyncObject;
-
-typedef struct _SyncCounter {
-SyncObject sync;   /* Common sync object data */
-CARD64 value;  /* counter value */
-struct _SysCounterInfo *pSysCounterInfo; /* NULL if not a system counter */
-} SyncCounter;
-
-typedef struct _SyncFence {
-SyncObject sync;   /* Common sync object data */
-ScreenPtr   pScreen;   /* Screen of this fence object */
-Bool   triggered;  /* fence state */
-} SyncFence;
+#include misync.h
+#include misyncstr.h
 
 /*
  * The System Counter interface
@@ -107,29 +84,6 @@ typedef struct _SysCounterInfo {
 
 
 
-typedef struct _SyncTrigger {
-SyncObject *pSync;
-CARD64 wait_value; /* wait value */
-unsigned int value_type; /* Absolute or Relative */
-unsigned int test_type;/* transition or Comparision type */
-CARD64 test_value; /* trigger event threshold value */
-Bool   (*CheckTrigger)(
-   struct _SyncTrigger * /*pTrigger*/,
-   CARD64 /*newval*/
-   );
-void   (*TriggerFired)(
-

Re: [PATCH x11proto] Add XF86XK_TouchpadOn/Off

On Mon, Nov 8, 2010 at 4:37 PM, Bastien Nocera had...@hadess.net wrote:
On Mon, 2010-11-08 at 16:32 -0600, Chris Bagwell wrote:
On Sun, Nov 7, 2010 at 11:24 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
Patch is fine with me. any NAKs?

The udev patch to standardise the behaviour is already in, see
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=a1ca5f60e0770299c5c5f21bd371f5823802412b
It requires an update to xkeyboard-config as well, synchronised with udev
to
maintain consistency. That's possible once this change is in.

And just to stress, at this point we need a commit made somewhere.
Might as well make this one.

udev submission above has changed existing F22 values to F21 so at
minimum to align with them we need to update below value from
xkeyboard-config's inet + synchronized udev release to prevent
breakage of existing feature.

Except that it never actually worked properly, so you wouldn't be
breaking that much.

Yep. I'm not trying to stress the broken part but the mismatch part.

I was motivated by your work and I'm working to get eee pc's working.
In their ACPI driver (eeepc-laptop or eeepc-wmi) they map a hotkey
meant for touchpad toggle to F13 (mapped before udev). Its been this
way for quite a while and so not to useful out of the box.

I want to get that aligned to F21 or F22 or what ever people agree to
so it can benefit from the nice work you guys did in this area.

It makes sense for me to wait until both udev and xkeyboard-config
match before proceeding though.

Chris
___
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] Multi-Touch (MT) support - arbitration or not

On Mon, Nov 08, 2010 at 03:54:51PM -0600, Chris Bagwell wrote:
 On Mon, Nov 8, 2010 at 2:08 AM, Benjamin Tissoires tisso...@cena.fr wrote:
  Le 08/11/2010 04:51, Peter Hutterer a écrit :
 
  fwiw, I'm not sure arbitrate is the right word here, filtering seems
  easier to understand in this context. I guess arbitrate would apply more
  if we emit the events across multiple devices like in the bamboo case.
  that's mostly bikeshedding though, my points below apply regardless of
  what
  word we choose :)
 
  note that we also have two different approaches - single kernel device or
  multiple kernel devices and depending on the approach the device uses the
  options below have different advantages and disadvantages.
 
  the tablets I've dealt with so far exposed a single event device, so
  that's
  what I'm focusing on in this email.
 
  On Fri, Nov 05, 2010 at 11:47:28AM -0700, Ping Cheng wrote:
 
  Recent changes and discussion about MT support at LKML, UDS, and
  xorg-devel encouraged me to migrate Wacom MT devices to the slot-based
  MT protocol (introduced in kernel 2.6.36). Since Wacom supports both
  digitizer and touch devices, I need to decide how to report touch data
  when the pen is in proximity.
 
  My goal is to understand how X server would like the MT data to be
  reported from the kernel. I hope to keep kernel and X server driver MT
  support in sync so we can avoid unnecessary confusion or extra work in
  the userland.
 
  The existing solution for single touch events is to arbitrate touch
  when pen is in prox. This is based on the assumption that we do not
  want to have two cursors competing on the screen.
 
  With the introduction of MT, the touch data are most likely translated
  into something other than pointer events. So, reporting both pen and
  touch data makes sense now. However, I want to assure a smooth
  tansition from single touch to MT for end users so they still get the
  single touch behavior as they used to be. I gathered the following
  approaches:
 
  1.     Arbitrate all touch data in the kernel.
 
  This is the simplest solution for device driver developers. But I do
  not feel it is end user and userland client friendly.
 
  I'm strongly opposed to this. kernel filtering of these devices is hard to
  circumvent and there _will_ be use-cases where we need more than one tool
  to
  work simultaneously. right now we're worrying about pen + touch, but what
  stops tablets from becoming large enough to be used by 2+ users with 2+
  pens simultaneously?
 
  from a purely event-stream focused viewpoint: why do we even care whether
  something is a pen or a touch? both are just tools and how these should be
  used is mostly up to the clients anyway.  IMO, the whole point of
  MT_TOOL_TYPE is that we don't have to assume use-cases for the tools but
  just forward the information to someone who knows how to deal with this.
 
  2.     Report first finger touch as ABS_X/Y events when pen is not in
  prox.  Arbitrating single touch data when pen is in prox. Pen data is
  reported as ABS_X/Y events. Both ABS_X/Y for pen or the first finger
  and ABS_MT_* for MT data are reported.
 
  This approach reduces the overhead in dealing with two cursors in
  userland.
 
  3.    Report first finger touch as ABS_X/Y events when pen is not in
  prox;
         Report pen data as ABS_X/Y events when there is no finger touch;
         Report touch data as MT_TOOL_TOUCH and pen data as MT_TOOL_PEN
  events when both pen and touch data are received. No ABS_X/Y are
  reported when pen and tocuh or multi-touch data are received.
 
  I feel this one makes sense to userland since pen can be considered as
  another touch.
 
  4.    Report first finger touch as ABS_X/Y events when pen is not in
  prox;
         Report pen data as ABS_X/Y events when there is no finger touch;
         Report touch data as MT_TOOL_TOUCH and pen data as MT_TOOL_PEN
  events when both pen and touch data are received. ABS_X/Y are also
  reported for pen when both pen and tocuh data are received.
 
  I'd vote for this one. It provides all the data necessary for MT clients
  (and all the data the device can support) but has a reasonable
  single-touch
  strategy. Given that wacom tablets are still primarily pen-centric
  tablets,
  the emphasis on pen overriding touch makes sense to me.
 
  Hi,
 
  I'd also vote for this.
 
  I don't think that the kernel should make any assumption on the final
  application. The data are available, so we have to pass them.
 
  1. I read that people worry about sending false events (touch) while using
  the pen. But in my mind, this is a _design_ problem of the final
  application. I think the final application will have to filter these events:
  for instance, what happens if the user is too lazy to remove his pen (or
  just want to keep the hover on the application) out of the proximity range
  and want to move its digital sheet of paper in his (her) design application?
  The final

Re: [PATCH x11proto] Add XF86XK_TouchpadOn/Off

On Mon, Nov 08, 2010 at 09:17:23PM -0600, Chris Bagwell wrote:
On Mon, Nov 8, 2010 at 4:37 PM, Bastien Nocera had...@hadess.net wrote:
On Mon, 2010-11-08 at 16:32 -0600, Chris Bagwell wrote:
On Sun, Nov 7, 2010 at 11:24 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
Patch is fine with me. any NAKs?

The udev patch to standardise the behaviour is already in, see
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=a1ca5f60e0770299c5c5f21bd371f5823802412b
It requires an update to xkeyboard-config as well, synchronised with
udev to
maintain consistency. That's possible once this change is in.

And just to stress, at this point we need a commit made somewhere.
Might as well make this one.

Except that it never actually worked properly, so you wouldn't be
breaking that much.

hey, it worked on my lenovo :)

Yep. I'm not trying to stress the broken part but the mismatch part.

I want to get that aligned to F21 or F22 or what ever people agree to
so it can benefit from the nice work you guys did in this area.

It makes sense for me to wait until both udev and xkeyboard-config
match before proceeding though.

This is mostly juggling by distributions anyway, since they need to update
kernel, udev, xkeyboard-config and x11proto at the same time. We don't have
to perfectly synchronise it upstream, the number of people running these
four from latest git is reasonably small :)

Cheers,
Peter
___
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] Multi-Touch (MT) support - arbitration or not

On Mon, Nov 8, 2010 at 9:31 PM, Peter Hutterer peter.hutte...@who-t.net wrote:
 On Mon, Nov 08, 2010 at 03:54:51PM -0600, Chris Bagwell wrote:

 I think we may be mixing some topics and so I'd like to try to
 re-frame the discussion.

 There are two different cases and they may have different answers
 because of it.

 Case 1) 1 input device can support multiple tools that are in
 proximity at same time.

 I believe this is currently a theoretical example (no driver exists like 
 this).

 if you consider touch to be just another tool, we already have devices that
 support proximity of multiple tools. This isn't theoretical anymore.

Yes, I totally agree there.  I meant more a MT driver with both pen
and touch or really any case were one tool in proximity can invalidate
meaning of other tools in proximity.

2 paragraphs down describes todays 1 input device with MT behaviour.


 In RFC example, this input devices has a pen and 2 finger touches.
 They all share ABS_X/Y/PRESSURE values.  The single touch (ST) input
 filtering breaks being able to support this case and what multitouch
 events (MT) were added for.

 To date, when converting drivers over to MT events the guideline is
 *always* send MT events (because what app wants to randomly switch
 between MT event processing and ST event processing for same
 X/Y/PRESSURE?) and send something sane for ST events to be backwards
 compatible with older apps.

 I think everyone is happy in this thread to always send pen+touch MT
 events and let X drivers or similar filter/arbitrate out unwanted
 touch events as needed.

 The ideal sane behavior for touch ST events has been leaning towards
 tracking 1st touch and continue sending 1st touch during multi-touch
 but there is some debate because tracking can be expensive in kernel.
 In case of pen+touch, the sane may change to prefer pen over touch and
 prefer first touch when 2 touches exist.

 Or sane can mean let the ST values go crazy during multi-touch and
 hope user can use GUI enough after new kernel install to get a
 MT-aware X driver.

 Its easy to implement preferring pen then preferring 1st touch so I
 suggest doing that.  This is for backwards compatibility only
 (un-modified xf86-input-wacom/synaptics/evdev/etc).  The future is MT
 events, in which case the ST events are meaningless and we are hiding
 nothing to applications that look at MT events.

 Case 2) 2 input devices can support multiple tools in proximity at same time.

 I believe it was Rafi that brought up point that dual pen+touch
 interfaces will have different properties.  Touch will be lower
 resolution then Pen and maybe different fuzz factor.  Also, on tablets
 I would think pretty easy to have different dimensions (one tool works
 over larger area of tablet).  This is easy to expose to user when 2
 input devices.

 Yes and no. We're talking about kernel level here and I don't think this
 should be done at this level. The current behaviour of the X driver is to
 split multiple tools up into multiple X devices, so the points above can
 easily be achieved in userspace.


 Combining into single input to user would be nice but at least when
 dimensions are different, we probably do not want to remove that
 visibility to user and so must keep 2 input devices.

 If we run into issues with different axis ranges/resolutions for multiple
 MT_SLOT devices, this should be addressed in the kernel as well.

Yes, that seems a fair statement.

 I feel uncomfortable about splitting up a physical device into multiple
 devices, it takes information away that cannot easily be re-created in the
 userspace. Even with a method of associating multiple event devices to the
 same physical device, the parsing of simultaneous events is harder because
 you're essentially deserialising event streams. In userspace, you have to
 re-serialize based on parallel inputs.

 That said, it also goes counter the whole multi-touch approach - allowing
 more than one device on a single physical device.

Hmm, does this sum up your opinion?  You are a strong proponent of
having all related tools sent over a single input device so you get
natural context of events.  When you do it this way, todays sample MT
implementation for touchpad just work for pen+touch as well.  That
behaviour can basically be summed up with send MT events for all
tools and let clients figure it out.  For older ST events do something
sane to help older apps.

So I get and do agree with that part but you've not clearly stated if
your also saying something like refuse to support split input
solutions and we should fix kernel instead of defining a behaviour for
this case.  If we are forced to support split inputs, I suspect your
basically OK with behaviour #2 because its effectively emulating
single input behaviour as best it can and we are just picking what
sane means in this case odd case.

I've copied #2 below and added my own text in [] to be sure and
clarify text in context of case #2.

2. Report first

Re: [PATCH x11proto] Add XF86XK_TouchpadOn/Off

On Mon, Nov 8, 2010 at 9:42 PM, Bastien Nocera had...@hadess.net wrote:
On Mon, 2010-11-08 at 21:17 -0600, Chris Bagwell wrote:
On Mon, Nov 8, 2010 at 4:37 PM, Bastien Nocera had...@hadess.net wrote:
On Mon, 2010-11-08 at 16:32 -0600, Chris Bagwell wrote:
On Sun, Nov 7, 2010 at 11:24 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
Patch is fine with me. any NAKs?

The udev patch to standardise the behaviour is already in, see
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=a1ca5f60e0770299c5c5f21bd371f5823802412b
It requires an update to xkeyboard-config as well, synchronised with
udev to
maintain consistency. That's possible once this change is in.

And just to stress, at this point we need a commit made somewhere.
Might as well make this one.

Except that it never actually worked properly, so you wouldn't be
breaking that much.

Yep. I'm not trying to stress the broken part but the mismatch part.

I want to get that aligned to F21 or F22 or what ever people agree to
so it can benefit from the nice work you guys did in this area.

Then no. You want to use the keys I'm trying to get added in the kernel:
http://thread.gmane.org/gmane.linux.kernel.input/16320

Then map from those keys to the fXX function keys in udev. My guess
from:
151 { KE_KEY, 0x37, { KEY_F13 } }, /* Disable Touchpad */
152 { KE_KEY, 0x38, { KEY_F14 } },
is that one disables the key in hardware, and the other enables it,
right?

Then it would be F22 and F23 respectively. So a popup is shown, but
gnome-settings-daemon doesn't actually change the state of the driver in
software.

Its a real toggle indication on eee pc's and HW doesn't disable
anything. If I edit kernel today (Fedora 14) to send F22 instead of
F13 then I get a nice popup and disable/enable of touchpad threw
software. I guess if I understood udev better I could have done above
instead of recompiling kernel.

It looks like a done deal to get KEY_TOUCHPAD_TOGGLE patch in input.h
so technically I need to make both a kernel update and then a udev
update to map KEY_TOUCHPAD_TOOGLE to F2x.

Either way, it sounds like udev should change for eee pc's. I'll need
your or someones help to point me towards a udev mailing list when
that time comes.

Chris
___
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: Smooth scrolling again

On Sun, Nov 07, 2010 at 02:56:22PM +0100, Max Schwarz wrote:
 I finally found some time for smooth scrolling.
 I've got rebased patches against git versions for
 xserver, xf86-input-evdev, xf86-input-synaptics
 in my github repo at https://github.com/x-quadraht/pscroll.
 
 Would you mind checking them and telling me what needs to be done to get them 
 merged?
 
 Another question: The output from the synaptics driver fluctuates quite a bit 
 when one tries to stay at the current scrolling position. Do you think 
 filtering would need to be implemented in the synaptics driver or globally in 
 the server?

patches looking good and simple, I like it.
a few comments regarding the evdev patch:

wheel resolution: this is a bit confusing (a man page entry would help).
you're multiplying the actual value with the resolution value during event
generation. the default value is 42? I realise smooth scrolling is a
subset of Life, Universe and Everything, but how did you get to this number.
why is the resolution even necessary? 
also, maybe use a float? otherwise, slowing the wheel down would be tricky.

mouse wheel emulation doesn't take the resolution into account - is this
intended? is there a use-case where it should?

initialisation code doesn't quite work this way. the emulateWheel.enabled is
a dynamic variable and can change at runtime, well past DEVICE_INIT when
this code is called. so you either need to unconditionally set up the wheel
axes or change the device's capabilities at runtime (which we don't really
have the hooks for yet, so you're down to option 1 :)
keep in mind that properties are (hopefully) set by the desktop environment,
so you can't expect the value to be the user's value on device startup.

the warning about using build-in value might as well print that value.

are the axis labels initialized correctly? xinput --list-prop should tell
you. I assume so, given the pscrolltest checks for it, but please
double-check.

I don't understand the no_integration stuff. aside from it being a bit of a
misnomer, I'm missing the point of what is supposed to do. if the axis is in
relative mode, you can go past the axis ranges anyway. In absolute mode,
well, are wheels ever in absolute mode? I know there's ABS_WHEEL, but I
think we convert them over to relative events too, no?

Cheers,
  Peter
___
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] xfree86: remove user-configured AllowEmptyInput