Re: Patch to fix wireless keyboard/mouse detection in libXi (xinput1)

2010-10-28 Thread Peter Hutterer
On Wed, Oct 27, 2010 at 09:27:37PM -0700, eric wrote:
 Attached is a patch that corrects a problem when using a wireless USB
 mouse/keyboard combination.  The USB wireless device ends up listing both
 the keyboard and the mouse as a keyboard device.  This prevents proper
 detection of the device type.
 
 There is more information in the Xorg bugzilla here:
 http://bugs.freedesktop.org/show_bug.cgi?id=29045
 
 And a bit more information can be found on the Ubuntu bug tracker here:
 https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/575465
 
 Please let me know if you have any questions.
 
 Thanks,
 
 Eric Kilfoil

 diff --git a/Xi/listdev.c b/Xi/listdev.c
 index 3b2272b..b38fbd1 100644
 --- a/Xi/listdev.c
 +++ b/Xi/listdev.c
 @@ -180,10 +180,10 @@ CopySwapDevice(ClientPtr client, DeviceIntPtr d, int 
 num_classes,
   dev-use = IsXKeyboard;
  else if (IsMaster(d)  IsPointerDevice(d))
   dev-use = IsXPointer;
 -else if (d-key  d-kbdfeed)
 -dev-use = IsXExtensionKeyboard;
  else if (d-valuator  d-button)
  dev-use = IsXExtensionPointer;
 +else if (d-key  d-kbdfeed)
 +dev-use = IsXExtensionKeyboard;
  else
   dev-use = IsXExtensionDevice;
  

merged, thanks.

please use git format-patch next time for the patch generation, it makes 
life for maintainers _a lot_ easier.

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: [ANNOUNCE] libXcomposite 0.4.3

2010-10-28 Thread Jeremy Huddleston
It looks like libXcomposite doesn't have a --disable-docs, --disable-specs, nor 
--disable-docs-devel, but it does have --without-fop ... 

Is there a reason why the docs/specs/docs-devel option is missing even though 
fop is there?  I was under the impression that the tool options were extra 
knobs to turn that only mattered if docs/specs/docs-devel were enabled.

On Oct 27, 2010, at 22:45, Alan Coopersmith wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 libXcomposite is the Xlib API for the X Composite Extension.
 
 This minor maintenance release provides build improvements and
 reduces both buildtime  runtime dependencies of the library.
 
 Alan Coopersmith (2):
  Remove unneeded dependencies from configure.ac  xcomposite.pc
  libXcomposite 0.4.3
 
 Fernando Carrijo (1):
  Purge macros NEED_EVENTS and NEED_REPLIES
 
 Gaetan Nadon (3):
  config: upgrade to util-macros 1.8 for additional man page support
  man: store shadow man pages in git rather than generating them
  man: list files to install only once
 
 git tag: libXcomposite-0.4.3
 
 http://xorg.freedesktop.org/archive/individual/lib/libXcomposite-0.4.3.tar.bz2
 MD5:  a60e0b5c276d0aa9e2d3b982c98f61c8
 SHA1: 081b26b556d55e20d7956c80a2ea2854962aecec
 
 http://xorg.freedesktop.org/archive/individual/lib/libXcomposite-0.4.3.tar.gz
 MD5:  b93dac50c86db6eba3f72e949f5bed2a
 SHA1: ccfa6f65e3e045e94966fc668088e43372482c65
 
 - --
   -Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.9 (SunOS)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iEYEARECAAYFAkzJDeEACgkQovueCB8tEw6YSwCfSD5AZsoRvYJzAHZAmXMFA0+K
 vAcAoIWdvMn8BZ94H9XyP3Riiq98mpGW
 =ALkW
 -END PGP SIGNATURE-
 ___
 x...@lists.freedesktop.org: X.Org support
 Archives: http://lists.freedesktop.org/archives/xorg
 Info: http://lists.freedesktop.org/mailman/listinfo/xorg
 Your subscription address: jerem...@freedesktop.org

___
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


How to create an floating device in Xorg input driver?

2010-10-28 Thread Park Sung-Jin
Hi,

Is there any one who knows how to create floting device in Xorg input driver ?

I'm writing an Xorg multitouch driver based on
xf86-input-evdev-multitouch driver.
In the driver, sub devices for multiple fingers will be created using
NewInputDeviceReuqest()
and will be removed using DeleteInputDeviceRequest().
If a device property was set by multitouch daemon application, the sub
devices will be created newly and will be removed.
For example, commands for doing that are : # multitouchctl 3
If the sub devices are created, then multitouch daemon gets a
XI_HierarchyChanged event, and set them as floating slaves
using XIChangeHierarchy() function.

What I want to do is creating the sub devices as floating slaves in
evdev-multitouch driver.
Is there any one who knows how to create floting device in Xorg input driver ?

Thanks,
Sung-Jin Park
___
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 0/4] Improve reporting of resource sizes.

2010-10-28 Thread Rami Ylimäki
The motivations of this patchset is to make xrestop and X resource
extension report resource sizes more accurately.

Currently xrestop is not taking pixmap references from extensions into
account. X server pixmap size reporting functions are improved to
include pixmaps referenced from render pictures and composite windows.

The server resource size functions are also abstracted so that size
calculation functions can be wrapped or overridden by drivers. For
example, it's useful to also report pixmaps referenced by DRI2
buffers, but this can be only done from drivers. These patches make it
possible to report extra pixmap references from drivers as well as
improve the default pixmap size calculation functions.

The xrestop application is currently estimating sizes of
non-predefined resources by constants because X resource extension
doesn't provide a way to query the sizes from X server. We'd like to
improve X resource extension in the near future so that the size of
any resource could be queried. We aren't planning to implement size
calculation for every resource. However, it'd be much better if
xrestop could first query the size of a resource from X server and
then fall back to estimating the size with a constant if X server
doesn't support size calculation of that particular resource. Then the
size calculation of most important resources, such as DRI2 drawables,
could be implemented in X server and X restop would be able to report
the size automatically.

Rami Ylimäki (4):
  dix: Provide means to report exact sizes of resources.
  dix: Add reverse resource name lookup function to registry.
  render: Report pixmap usage of pictures to resource extension.
  composite: Report pixmap usage of client windows to resource
extension.

 Xext/xres.c |   67 +
 composite/compext.c |   24 ++
 dix/registry.c  |   10 +++
 dix/resource.c  |  199 ++-
 include/registry.h  |6 ++
 include/resource.h  |   23 ++
 render/picture.c|   22 ++
 7 files changed, 318 insertions(+), 33 deletions(-)

___
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/4] dix: Add reverse resource name lookup function to registry.

2010-10-28 Thread Rami Ylimäki
Currently only some pre-defined resource types can be accessed from
headers. Make it possible to find out types of new resources that
aren't pre-defined but need to be registered separately.

Signed-off-by: Rami Ylimäki rami.ylim...@vincit.fi
---
 dix/registry.c |   10 ++
 include/registry.h |6 ++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/dix/registry.c b/dix/registry.c
index fc35dbb..15f85cc 100644
--- a/dix/registry.c
+++ b/dix/registry.c
@@ -273,6 +273,16 @@ LookupResourceName(RESTYPE resource)
 return resources[resource] ? resources[resource] : XREGISTRY_UNKNOWN;
 }
 
+RESTYPE
+LookupResourceType(const char *name)
+{
+RESTYPE resource = nresource;
+while (--resource  0)
+if (resources[resource]  !strcmp(resources[resource], name))
+return resource;
+return RT_NONE;
+}
+
 /*
  * Setup and teardown
  */
diff --git a/include/registry.h b/include/registry.h
index 325f765..99a3e65 100644
--- a/include/registry.h
+++ b/include/registry.h
@@ -41,6 +41,11 @@ extern _X_EXPORT const char *LookupErrorName(int error);
 extern _X_EXPORT const char *LookupResourceName(RESTYPE rtype);
 
 /*
+ * Reverse lookup functions.
+ */
+extern _X_EXPORT RESTYPE LookupResourceType(const char *name);
+
+/*
  * Setup and teardown
  */
 extern _X_EXPORT void dixResetRegistry(void);
@@ -57,6 +62,7 @@ extern _X_EXPORT void dixResetRegistry(void);
 #define LookupEventName(a) XREGISTRY_UNKNOWN
 #define LookupErrorName(a) XREGISTRY_UNKNOWN
 #define LookupResourceName(a) XREGISTRY_UNKNOWN
+#define LookupResourceType(a) RT_NONE
 
 #define dixResetRegistry() { ; }
 
-- 
1.6.3.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 3/4] render: Report pixmap usage of pictures to resource extension.

2010-10-28 Thread Rami Ylimäki
Signed-off-by: Rami Ylimäki rami.ylim...@vincit.fi
---
 Xext/xres.c  |   14 ++
 render/picture.c |   22 ++
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/Xext/xres.c b/Xext/xres.c
index e2fd8a7..ae9735a 100644
--- a/Xext/xres.c
+++ b/Xext/xres.c
@@ -216,6 +216,13 @@ ResFindGCPixmaps (pointer value, XID id, pointer cdata)
 ResFindResourcePixmaps(value, id, RT_GC, cdata);
 }
 
+static RESTYPE RT_PICTURE = RT_NONE;
+static void
+ResFindPicturePixmaps (pointer value, XID id, pointer cdata)
+{
+ResFindResourcePixmaps(value, id, RT_PICTURE, cdata);
+}
+
 static int
 ProcXResQueryClientPixmapBytes (ClientPtr client)
 {
@@ -252,6 +259,13 @@ ProcXResQueryClientPixmapBytes (ClientPtr client)
  ResFindGCPixmaps, 
   (pointer)(bytes));
 
+/* Render extension picture pixmaps. */
+RT_PICTURE = LookupResourceType(PICTURE);
+if (RT_PICTURE != RT_NONE)
+FindClientResourcesByType(clients[clientID], RT_PICTURE,
+  ResFindPicturePixmaps,
+  (pointer)(bytes));
+
 #ifdef COMPOSITE
 /* FIXME: include composite pixmaps too */
 #endif
diff --git a/render/picture.c b/render/picture.c
index 7fda6b9..64d9b72 100644
--- a/render/picture.c
+++ b/render/picture.c
@@ -606,6 +606,27 @@ PictureParseCmapPolicy (const char *name)
return PictureCmapPolicyInvalid;
 }
 
+/** @see GetDefaultBytes */
+static void
+GetPictureBytes(pointer value, XID id, ResourceSizePtr size)
+{
+PicturePtr picture = value;
+
+/* Currently only pixmap bytes are reported to clients. */
+size-resourceSize = 0;
+
+/* Calculate pixmap reference sizes. */
+size-pixmapRefSize = 0;
+if (picture-pDrawable  (picture-pDrawable-type == DRAWABLE_PIXMAP))
+{
+SizeType pixmapSizeFunc = GetResourceTypeSizeFunc(RT_PIXMAP);
+ResourceSizeRec pixmapSize = { 0, 0 };
+PixmapPtr pixmap = (PixmapPtr)picture-pDrawable;
+pixmapSizeFunc(pixmap, pixmap-drawable.id, pixmapSize);
+size-pixmapRefSize += pixmapSize.pixmapRefSize;
+}
+}
+
 Bool
 PictureInit (ScreenPtr pScreen, PictFormatPtr formats, int nformats)
 {
@@ -618,6 +639,7 @@ PictureInit (ScreenPtr pScreen, PictFormatPtr formats, int 
nformats)
PictureType = CreateNewResourceType (FreePicture, PICTURE);
if (!PictureType)
return FALSE;
+   SetResourceTypeSizeFunc(PictureType, GetPictureBytes);
PictFormatType = CreateNewResourceType (FreePictFormat, PICTFORMAT);
if (!PictFormatType)
return FALSE;
-- 
1.6.3.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 4/4] composite: Report pixmap usage of client windows to resource extension.

2010-10-28 Thread Rami Ylimäki
Signed-off-by: Rami Ylimäki rami.ylim...@vincit.fi
---
 Xext/xres.c |   16 +---
 composite/compext.c |   24 
 2 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/Xext/xres.c b/Xext/xres.c
index ae9735a..0d626e6 100644
--- a/Xext/xres.c
+++ b/Xext/xres.c
@@ -223,6 +223,13 @@ ResFindPicturePixmaps (pointer value, XID id, pointer 
cdata)
 ResFindResourcePixmaps(value, id, RT_PICTURE, cdata);
 }
 
+static RESTYPE RT_COMPOSITE_CLIENT_WINDOW = RT_NONE;
+static void
+ResFindCompositeClientWindowPixmaps (pointer value, XID id, pointer cdata)
+{
+ResFindResourcePixmaps(value, id, RT_COMPOSITE_CLIENT_WINDOW, cdata);
+}
+
 static int
 ProcXResQueryClientPixmapBytes (ClientPtr client)
 {
@@ -266,9 +273,12 @@ ProcXResQueryClientPixmapBytes (ClientPtr client)
   ResFindPicturePixmaps,
   (pointer)(bytes));
 
-#ifdef COMPOSITE
-/* FIXME: include composite pixmaps too */
-#endif
+/* Composite extension client window pixmaps. */
+RT_COMPOSITE_CLIENT_WINDOW = LookupResourceType(CompositeClientWindow);
+if (RT_COMPOSITE_CLIENT_WINDOW != RT_NONE)
+FindClientResourcesByType(clients[clientID], 
RT_COMPOSITE_CLIENT_WINDOW,
+  ResFindCompositeClientWindowPixmaps,
+  (pointer)(bytes));
 
 rep.type = X_Reply;
 rep.sequenceNumber = client-sequence;
diff --git a/composite/compext.c b/composite/compext.c
index 30d9dc2..676b9a5 100644
--- a/composite/compext.c
+++ b/composite/compext.c
@@ -508,6 +508,28 @@ SProcCompositeDispatch (ClientPtr client)
return BadRequest;
 }
 
+/** @see GetDefaultBytes */
+static void
+GetCompositeClientWindowBytes(pointer value, XID id, ResourceSizePtr size)
+{
+WindowPtr window = value;
+
+/* Currently only pixmap bytes are reported to clients. */
+size-resourceSize = 0;
+
+/* Calculate pixmap reference sizes. */
+size-pixmapRefSize = 0;
+if (window-redirectDraw != RedirectDrawNone)
+{
+SizeType pixmapSizeFunc = GetResourceTypeSizeFunc(RT_PIXMAP);
+ResourceSizeRec pixmapSize = { 0, 0 };
+ScreenPtr screen = window-drawable.pScreen;
+PixmapPtr pixmap = screen-GetWindowPixmap(window);
+pixmapSizeFunc(pixmap, pixmap-drawable.id, pixmapSize);
+size-pixmapRefSize += pixmapSize.pixmapRefSize;
+}
+}
+
 void
 CompositeExtensionInit (void)
 {
@@ -547,6 +569,8 @@ CompositeExtensionInit (void)
(FreeCompositeClientWindow, CompositeClientWindow);
 if (!CompositeClientWindowType)
return;
+SetResourceTypeSizeFunc(CompositeClientWindowType,
+GetCompositeClientWindowBytes);
 
 CompositeClientSubwindowsType = CreateNewResourceType
(FreeCompositeClientSubwindows, CompositeClientSubwindows);
-- 
1.6.3.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: CEA mode 61 wrong in EDID parser

2010-10-28 Thread Adam Jackson
On Thu, 2010-10-14 at 13:59 +0800, ykzhao wrote:

 From e968341dd14a32e70e35660ccf7aa3dc3c531eb0 Mon Sep 17 00:00:00 2001
 From: Zhao Yakui yakui.z...@intel.com
 Date: Thu, 14 Oct 2010 13:54:04 +0800
 Subject: [PATCH] EDID: fix the incorrect mode definition for VIC61 in CEA
 
 Signed-off-by: Zhao Yakui yakui.z...@intel.com
 Signed-off-by: Anssi Hannula anssi.hann...@iki.fi

Reviewed-by: Adam Jackson a...@redhat.com

- ajax


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 evdev 2/2] Reshuffle to avoid the need for XI86_CONFIGURED.

2010-10-28 Thread Benjamin Tissoires



Le 28/10/2010 05:11, Peter Hutterer a écrit :

On Tue, Oct 26, 2010 at 10:11:17AM +1000, Peter Hutterer wrote:

Signed-off-by: Peter Huttererpeter.hutte...@who-t.net
---
  src/evdev.c |   22 +-
  1 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 018843f..940f24d 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -63,7 +63,6 @@


[...]


@@ -2214,7 +2214,11 @@ EvdevPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
  xf86ProcessCommonOptions(pInfo, pInfo-options);

  if (NewEvdevPreInit(drv, pInfo, flags) == Success)
+{
+pInfo-flags = XI86_CONFIGURED;
  return pInfo;
+}
+


ftr, this should be pInfo-flags |= XI86_CONFIGURED;
who would have thought that = vs. |= makes a difference :)


Oops, I was so concerned by the undef that I didn't catch that.

Sorry Peter,

Cheers,
Benjamin





  xf86DeleteInput(pInfo, 0);
  return NULL;
--
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

___
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] dix: adds support for none root window background

2010-10-28 Thread Tiago Vignatti
This lets the driver notify the server whether it can draw a background when
-nr option is passed. If the driver can copy the framebuffer cleanly then it
can set the flag, otherwise the server will fallback to normal behaviour.

The commit is originally based on discussions happened on xorg-devel:
http://lists.freedesktop.org/archives/xorg-devel/2010-June/009755.html

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 dix/window.c |6 ++
 include/opaque.h |1 +
 include/scrnintstr.h |5 +
 os/utils.c   |3 +++
 4 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/dix/window.c b/dix/window.c
index cfebb9d..7a47221 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -137,6 +137,8 @@ Equipment Corporation.
  *ChangeWindowDeviceCursor
  **/
 
+Bool bgNoneRoot = FALSE;
+
 static unsigned char _back_lsb[4] = {0x88, 0x22, 0x44, 0x11};
 static unsigned char _back_msb[4] = {0x11, 0x44, 0x22, 0x88};
 
@@ -463,6 +465,10 @@ InitRootWindow(WindowPtr pWin)
 if (party_like_its_1989) {
 MakeRootTile(pWin);
 backFlag |= CWBackPixmap;
+} else if (pScreen-canDoBGNoneRoot  bgNoneRoot) {
+pWin-backgroundState = XaceBackgroundNoneState(pWin);
+pWin-background.pixel = pScreen-whitePixel;
+backFlag |= CWBackPixmap;
 } else {
if (whiteRoot)
 pWin-background.pixel = pScreen-whitePixel;
diff --git a/include/opaque.h b/include/opaque.h
index f8c..f1a0046 100644
--- a/include/opaque.h
+++ b/include/opaque.h
@@ -72,6 +72,7 @@ extern _X_EXPORT Bool defeatAccessControl;
 extern _X_EXPORT long maxBigRequestSize;
 extern _X_EXPORT Bool party_like_its_1989;
 extern _X_EXPORT Bool whiteRoot;
+extern _X_EXPORT Bool bgNoneRoot;
 
 extern _X_EXPORT Bool CoreDump;
 
diff --git a/include/scrnintstr.h b/include/scrnintstr.h
index e36b15f..b1d2d8e 100644
--- a/include/scrnintstr.h
+++ b/include/scrnintstr.h
@@ -479,6 +479,11 @@ typedef struct _Screen {
 short  numVisuals;
 VisualPtr  visuals;
 WindowPtr  root;
+
+/* set it in driver side if X server can copy the framebuffer content.
+ * Meant be used together with -nr option. */
+intcanDoBGNoneRoot;
+
 ScreenSaverStuffRec screensaver;
 
 /* Random screen procedures */
diff --git a/os/utils.c b/os/utils.c
index f176af4..9eb6084 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -502,6 +502,7 @@ void UseMsg(void)
 #endif
 ErrorF(-nolisten string   don't listen on protocol\n);
 ErrorF(-noreset   don't reset after last client exists\n);
+ErrorF(-nrcreate root window with no background\n);
 ErrorF(-reset reset after last client exists\n);
 ErrorF(-p #   screen-saver pattern duration (minutes)\n);
 ErrorF(-pnaccept failure to listen on all ports\n);
@@ -842,6 +843,8 @@ ProcessCommandLine(int argc, char *argv[])
defaultBackingStore = WhenMapped;
 else if ( strcmp( argv[i], -wr) == 0)
 whiteRoot = TRUE;
+else if ( strcmp( argv[i], -nr) == 0)
+bgNoneRoot = TRUE;
 else if ( strcmp( argv[i], -maxbigreqsize) == 0) {
  if(++i  argc) {
  long reqSizeArg = atol(argv[i]);
-- 
1.7.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: How to create an floating device in Xorg input driver?

2010-10-28 Thread Benjamin Tissoires

Hi,

If I understand correctly, you are trying to work with the patches I 
submitted, nearly a year ago.


First, I would just say that the work concerning this branch of evdev is 
not maintained as it has a lot of problems (limit of the maximum count 
of contact, etc).


Multitouch will be available with XInput 2.1.

My first Idea was to create floating devices, but I encountered a bug I 
did not have the time to patch. If the driver creates a floating device, 
and you attach this device to a master one, I had trouble transferring 
the events. That's why I did not created floating devices.


BTW, if want to give it a test, you can just uncomment the line:

EvdevReplaceOption(input_options, SendCoreEvents,off);

before calling NewInputDeviceRequest.

Cheers,
Benjamin

Le 28/10/2010 10:42, Park Sung-Jin a écrit :

Hi,

Is there any one who knows how to create floting device in Xorg input driver ?

I'm writing an Xorg multitouch driver based on
xf86-input-evdev-multitouch driver.
In the driver, sub devices for multiple fingers will be created using
NewInputDeviceReuqest()
and will be removed using DeleteInputDeviceRequest().
If a device property was set by multitouch daemon application, the sub
devices will be created newly and will be removed.
For example, commands for doing that are : # multitouchctl 3
If the sub devices are created, then multitouch daemon gets a
XI_HierarchyChanged event, and set them as floating slaves
using XIChangeHierarchy() function.

What I want to do is creating the sub devices as floating slaves in
evdev-multitouch driver.
Is there any one who knows how to create floting device in Xorg input driver ?

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

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


Re: [PATCH] Do not trap access to timer and keyboard

2010-10-28 Thread Adam Jackson
On Sun, 2010-10-24 at 15:18 +0200, Samuel Thibault wrote:
 Adam Jackson, le Fri 19 Mar 2010 14:29:55 -0400, a écrit :
  Well in that case, the ioperm() is definitely bogus on all platforms,
  since all it can do is make us crash.  But it indicates that the int10
  wrapper needs to do a better job of emulating those ports, since the
  kernel is definitely going to be using them.
 
 Could we at least apply the patch below to fix mga-g450?
 
 Samuel

Reviewed-by: Adam Jackson a...@redhat.com

- ajax


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] x86emu: fix jump_near_IMM to handle DATA: flag correctly.

2010-10-28 Thread Adam Jackson
On Sun, 2010-10-24 at 23:57 +0200, Luc Verhaegen wrote:
 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=24348
 
 Before (data flag ignored - broken):
 66  DATA:
 e944f1  JMP   1ff6
 
 After (fixed):
 66  DATA:
 e944f1  JMP   1ff8
 
 This subtle difference in the length of decoded instruction meant
 that the VBE call jumped to the routine setting AX=0x14F (VBE Failed)
 instead of the routine that set AX=0x4F (VBE success).
 
 The ability to run the same code in vm86 significantly aided the
 debugging of this issue. Those X.org developers who would like to drop
 vm86 better take special care towards _all_ vesa bugs, as those will
 expose further issues.
 
 Patch applies easily to even xserver 1.4.2.
 
 Signed-off-by: Luc Verhaegen l...@skynet.be
 Tested-by: Luc Verhaegen l...@skynet.be

Reviewed-by: Adam Jackson a...@redhat.com

- ajax


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: xserver: commit 80b5d3a3264d2c5167e5ac85a3b04af0f89cece1 seems to have a copy/paste error

2010-10-28 Thread Adam Jackson
On Sun, 2010-10-17 at 12:47 -0700, Linus Arver wrote:

 From 8c736a799c32757dfd052ad707ac91ba0c77c761 Mon Sep 17 00:00:00 2001
 From: Linus Arver linusar...@gmail.com
 Date: Sun, 17 Oct 2010 12:26:01 -0700
 Subject: [PATCH] Xext: panoramiXprocs: fix typo
 
 This fixes a typo introduced in commit
 80b5d3a3264d2c5167e5ac85a3b04af0f89cece1. The pointer pDst was changed
 unintentionally to pWin from a copy/paste error. This resulted in all
 QT-based apps and some tcl/tk ones (like fontforge) to crash X 1.9 on
 starting up, when Xinerama was enabled.
 
 Bug report: https://bbs.archlinux.org/viewtopic.php?id=106125
 
 Signed-off-by: Elie Bleton drozo...@gmail.com
 Tested-by: Linus Arver linusar...@gmail.com

Reviewed-by: Adam Jackson a...@redhat.com

- ajax


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] os: Fix BigReq ignoring when another request is pending

2010-10-28 Thread Adam Jackson
On Mon, 2010-10-25 at 22:01 -0700, Aaron Plattner wrote:
 Commit cf88363db0ebb42df7cc286b85d30d7898aea840 fixed the handling of
 BigReq requests that are way too large and handles the case where the
 read() syscall returns a short read.  However, it neglected to handle
 the case where it returns a long read, which happens when the client
 has another request in the queue after the bogus large one.
 
 Handle the long read case by subtracting the smaller of 'needed' and
 'gotnow' from oci-ignoreBytes.  If needed  gotnow, simply subtract
 the two, leaving gotnow equal to the number of extra bytes read.
 Since the code immediately following the (oci-ignoreBytes  0) block
 tries to handle the next request, advance oci-bufptr immediately
 instead of setting oci-lenLastReq and letting the next call to
 ReadRequestFromClient do it.
 
 Fixes the XTS pChangeKeyboardMapping-3 test.
 
  CASES TESTS  PASS UNSUP UNTST NOTIU  WARN   FIP  FAIL UNRES  UNIN 
 ABORT
 -Xproto122   389   367 219 0 0 0 1 0 0
  0
 +Xproto122   389   368 219 0 0 0 0 0 0
  0
 
 Signed-off-by: Aaron Plattner aplatt...@nvidia.com

Reviewed-by: Adam Jackson a...@redhat.com

 ---
 Sorry I screwed this up the first time.  Do you think I should revert the 
 first
 version and then reapply this one?

Meh.  The commit message is sufficiently informative.

- ajax


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] xinerama: drop unused PanoramiXScreenRegion

2010-10-28 Thread Adam Jackson
On Wed, 2010-10-27 at 15:44 +1000, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 I can't see this region actually being used anywhere in the code.

Reviewed-by: Adam Jackson a...@redhat.com

- ajax


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

[PATCH 00/15] xserver: cleanup and standardize startup options

2010-10-28 Thread Tiago Vignatti
Hi fellows,

Our culture is turning -option the default syntax for arguments to be passed
to the server. This patch set tries to standardize the rest of arguments that
are not on such shape yet, removing some superfluous ones and also doing some
other janitor work around.

I tried to be very conservative in this patchset, avoiding to do major
changes on behaviour. I have another patchset queued here to do more
surgical inspection, for instance removing things like -noacpi or
-disableVidMode options, which IMHO are not useful at all. But I'll let this
discussion to afterwards.


I appreciate your review!


Tiago Vignatti (15):
  os: remove superfluous -br option
  xfree86: xwin: do not parse -xf86config cmd line option
  xfree86: remove unused -s option
  xfree86: xquartz: remove superfluous -showconfig option
  dix: xfree86: remove superfluous +br simplifying backing store support options
  os: remove superfluous +xinerama option
  os: xinerama: remove hack and undocumented -disablexineramaextension option
  os: remove superfluous c option
  os: remove superfluous -I option
  os: remove superfluous r option
  os: standardize tty option to -tty instead
  os: remove superfluous v option
  os: standardize option to enabling/disabling extensions
  os: rename and document -pogo option
  dix: delete logo hack screen saver

 Xext/panoramiX.c|8 --
 dix/globals.c   |4 -
 dix/window.c|  209 +--
 doc/Xserver.man.pre |   12 ---
 hw/dmx/Xdmx.man |   18 ++--
 hw/dmx/config/test-k.in |2 +-
 hw/dmx/config/test-k.out|2 +-
 hw/xfree86/common/xf86Globals.c |4 +-
 hw/xfree86/common/xf86Helper.c  |   10 +-
 hw/xfree86/common/xf86Init.c|   18 +---
 hw/xfree86/common/xf86Priv.h|4 +-
 hw/xfree86/doc/man/Xorg.man.pre |8 --
 hw/xquartz/darwin.c |2 +-
 hw/xquartz/quartzStartup.c  |2 +-
 hw/xwin/winprocarg.c|3 +-
 include/globals.h   |4 -
 include/opaque.h|6 +-
 include/site.h  |3 -
 os/utils.c  |   76 +++---
 19 files changed, 44 insertions(+), 351 deletions(-)

___
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 04/15] xfree86: xquartz: remove superfluous -showconfig option

2010-10-28 Thread Tiago Vignatti
It's there since the first cvs revision there for compatibility reasons.
Therefore time to deprecate it now.

-version does the same job.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 hw/xfree86/common/xf86Init.c|2 +-
 hw/xfree86/doc/man/Xorg.man.pre |8 
 hw/xquartz/darwin.c |2 +-
 hw/xquartz/quartzStartup.c  |2 +-
 4 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index 1ea8322..533bbd7 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -1161,7 +1161,7 @@ ddxProcessArgument(int argc, char **argv, int i)
 xf86SetVerbosity(-1);
 return 1;
   }
-  if (!strcmp(argv[i],-showconfig) || !strcmp(argv[i],-version))
+  if (!strcmp(argv[i],-version))
   {
 xf86PrintBanner();
 exit(0);
diff --git a/hw/xfree86/doc/man/Xorg.man.pre b/hw/xfree86/doc/man/Xorg.man.pre
index 805f3a3..a8ff67f 100644
--- a/hw/xfree86/doc/man/Xorg.man.pre
+++ b/hw/xfree86/doc/man/Xorg.man.pre
@@ -389,14 +389,6 @@ section when there are no
 .B Layout
 sections.
 .TP 8
-.B \-showconfig
-This is the same as the
-.B \-version
-option, and is included for compatibility reasons.  It may be removed
-in a future release, so the
-.B \-version
-option should be used instead.
-.TP 8
 .B \-showDefaultModulePath
 Print out the default module path the server was compiled with.
 .TP 8
diff --git a/hw/xquartz/darwin.c b/hw/xquartz/darwin.c
index a99c0f1..dbf7bb4 100644
--- a/hw/xquartz/darwin.c
+++ b/hw/xquartz/darwin.c
@@ -723,7 +723,7 @@ int ddxProcessArgument( int argc, char *argv[], int i )
 return 2;
 }
 
-if (!strcmp( argv[i], -showconfig ) || !strcmp( argv[i], -version )) {
+if (!strcmp( argv[i], -version )) {
 DarwinPrintBanner();
 exit(0);
 }
diff --git a/hw/xquartz/quartzStartup.c b/hw/xquartz/quartzStartup.c
index ba92ece..27638aa 100644
--- a/hw/xquartz/quartzStartup.c
+++ b/hw/xquartz/quartzStartup.c
@@ -111,7 +111,7 @@ int server_main(int argc, char **argv, char **envp) {
 
 for (i = 1; i  argc; i++) {
 // Display version info without starting Mac OS X UI if requested
-if (!strcmp( argv[i], -showconfig ) || !strcmp( argv[i], -version 
)) {
+if (!strcmp(argv[i], -version)) {
 DarwinPrintBanner();
 exit(0);
 }
-- 
1.7.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


[PATCH 02/15] xfree86: xwin: do not parse -xf86config cmd line option

2010-10-28 Thread Tiago Vignatti
We have already -config for the same purpose, which is documented and doing
the proper job. Therefore remove superfluous -xf86config option.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 hw/xfree86/common/xf86Init.c |2 +-
 hw/xwin/winprocarg.c |3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index 877ebab..65afa0a 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -1071,7 +1071,7 @@ ddxProcessArgument(int argc, char **argv, int i)
   return 2;
 }
   }
-  if (!strcmp(argv[i], -config) || !strcmp(argv[i], -xf86config))
+  if (!strcmp(argv[i], -config))
   {
 CHECK_FOR_REQUIRED_ARGUMENT();
 if (getuid() != 0  !xf86PathIsSafe(argv[i + 1])) {
diff --git a/hw/xwin/winprocarg.c b/hw/xwin/winprocarg.c
index 1ce5c2d..c20e455 100644
--- a/hw/xwin/winprocarg.c
+++ b/hw/xwin/winprocarg.c
@@ -985,8 +985,7 @@ ddxProcessArgument (int argc, char *argv[], int i)
   /*
* Look for the '-config' argument
*/
-  if (IS_OPTION (-config)
-  || IS_OPTION (-xf86config))
+  if (IS_OPTION (-config))
 {
   CHECK_ARGS (1);
 #ifdef XWIN_XF86CONFIG
-- 
1.7.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


[PATCH 07/15] os: xinerama: remove hack and undocumented -disablexineramaextension option

2010-10-28 Thread Tiago Vignatti
We are not supposed to hack the server to address client issues (see bug #1846
for more details). This reverts commit cdc15e22.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 Xext/panoramiX.c  |8 
 include/globals.h |4 
 os/utils.c|7 ---
 3 files changed, 0 insertions(+), 19 deletions(-)

diff --git a/Xext/panoramiX.c b/Xext/panoramiX.c
index b73c53f..b7c5191 100644
--- a/Xext/panoramiX.c
+++ b/Xext/panoramiX.c
@@ -1014,15 +1014,7 @@ ProcXineramaIsActive(ClientPtr client)
 rep.type = X_Reply;
 rep.length = 0;
 rep.sequenceNumber = client-sequence;
-#if 1
-{
-   /* The following hack fools clients into thinking that Xinerama
-* is disabled even though it is not. */
-   rep.state = !noPanoramiXExtension  !PanoramiXExtensionDisabledHack;
-}
-#else
 rep.state = !noPanoramiXExtension;
-#endif
 if (client-swapped) {
int n;
swaps (rep.sequenceNumber, n);
diff --git a/include/globals.h b/include/globals.h
index 8b80a65..bcb94e0 100644
--- a/include/globals.h
+++ b/include/globals.h
@@ -34,10 +34,6 @@ extern _X_EXPORT Bool DPMSDisabledSwitch;
 extern _X_EXPORT Bool DPMSCapableFlag;
 #endif
 
-#ifdef PANORAMIX
-extern _X_EXPORT Bool PanoramiXExtensionDisabledHack;
-#endif
-
 #ifdef COMPOSITE
 extern _X_EXPORT Bool noCompositeExtension;
 #endif
diff --git a/os/utils.c b/os/utils.c
index 8ed0c7c..3a747ad 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -195,10 +195,6 @@ Bool noGEExtension = FALSE;
 
 Bool CoreDump;
 
-#ifdef PANORAMIX
-Bool PanoramiXExtensionDisabledHack = FALSE;
-#endif
-
 int auditTrailLevel = 1;
 
 #if defined(SVR4) || defined(__linux__) || defined(CSRG_BASED)
@@ -858,9 +854,6 @@ ProcessCommandLine(int argc, char *argv[])
else if ( strcmp( argv[i], -xinerama) == 0){
noPanoramiXExtension = FALSE;
}
-   else if ( strcmp( argv[i], -disablexineramaextension) == 0){
-   PanoramiXExtensionDisabledHack = TRUE;
-   }
 #endif
else if ( strcmp( argv[i], -I) == 0)
{
-- 
1.7.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


[PATCH 09/15] os: remove superfluous -I option

2010-10-28 Thread Tiago Vignatti
We don't need it.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 os/utils.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/os/utils.c b/os/utils.c
index 3a8e9cf..e9280bb 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -478,7 +478,6 @@ void UseMsg(void)
 ErrorF(-fn string default font name\n);
 ErrorF(-fp string default font path\n);
 ErrorF(-help  prints message with these options\n);
-ErrorF(-I ignore all remaining arguments\n);
 #ifdef RLIMIT_DATA
 ErrorF(-ld intlimit data space to N Kb\n);
 #endif
@@ -850,11 +849,6 @@ ProcessCommandLine(int argc, char *argv[])
noPanoramiXExtension = FALSE;
}
 #endif
-   else if ( strcmp( argv[i], -I) == 0)
-   {
-   /* ignore all remaining arguments */
-   break;
-   }
else if (strncmp (argv[i], tty, 3) == 0)
{
 /* init supplies us with this useless information */
-- 
1.7.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


[PATCH 13/15] os: standardize option to enabling/disabling extensions

2010-10-28 Thread Tiago Vignatti
+extension - -enableext
-extension - -disableext

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 os/utils.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/os/utils.c b/os/utils.c
index 0a4fca4..2f6eb0c 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -517,8 +517,8 @@ void UseMsg(void)
 ErrorF(-dumbSched Disable smart scheduling, enable old 
behavior\n);
 ErrorF(-schedInterval int Set scheduler interval in msec\n);
 ErrorF(-sigstop   Enable SIGSTOP based startup\n);
-ErrorF(+extension nameEnable extension\n);
-ErrorF(-extension nameDisable extension\n);
+ErrorF(-enableext nameEnable extension\n);
+ErrorF(-disableext name   Disable extension\n);
 #ifdef XDMCP
 XdmcpUseMsg();
 #endif
@@ -894,7 +894,7 @@ ProcessCommandLine(int argc, char *argv[])
{
RunFromSigStopParent = TRUE;
}
-   else if ( strcmp( argv[i], +extension) == 0)
+   else if ( strcmp( argv[i], -enableext) == 0)
{
if (++i  argc)
{
@@ -904,7 +904,7 @@ ProcessCommandLine(int argc, char *argv[])
else
UseMsg();
}
-   else if ( strcmp( argv[i], -extension) == 0)
+   else if ( strcmp( argv[i], -disableext) == 0)
{
if (++i  argc)
{
-- 
1.7.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


[PATCH 12/15] os: remove superfluous v option

2010-10-28 Thread Tiago Vignatti
screen saver is blanking by default already.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 os/utils.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/os/utils.c b/os/utils.c
index 2482ca1..0a4fca4 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -507,7 +507,6 @@ void UseMsg(void)
 ErrorF(-to #  connection time out\n);
 ErrorF(-tst   disable testing extensions\n);
 ErrorF(-ttyxx server started from init on /dev/ttyxx\n);
-ErrorF(v  video blanking for screen-saver\n);
 ErrorF(-v screen-saver without video blanking\n);
 ErrorF(-wmWhenMapped default backing-store\n);
 ErrorF(-wrcreate root window with white 
background\n);
@@ -815,8 +814,6 @@ ProcessCommandLine(int argc, char *argv[])
{
noTestExtensions = TRUE;
}
-   else if ( strcmp( argv[i], v) == 0)
-   defaultScreenSaverBlanking = PreferBlanking;
else if ( strcmp( argv[i], -v) == 0)
defaultScreenSaverBlanking = DontPreferBlanking;
else if ( strcmp( argv[i], -wm) == 0)
-- 
1.7.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


[PATCH 14/15] os: rename and document -pogo option

2010-10-28 Thread Tiago Vignatti
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 os/utils.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/os/utils.c b/os/utils.c
index 2f6eb0c..6a70509 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -517,6 +517,7 @@ void UseMsg(void)
 ErrorF(-dumbSched Disable smart scheduling, enable old 
behavior\n);
 ErrorF(-schedInterval int Set scheduler interval in msec\n);
 ErrorF(-sigstop   Enable SIGSTOP based startup\n);
+ErrorF(-shutdown  Shutdown the server just after start (for 
benchmark and debugging)\n);
 ErrorF(-enableext nameEnable extension\n);
 ErrorF(-disableext name   Disable extension\n);
 #ifdef XDMCP
@@ -772,7 +773,7 @@ ProcessCommandLine(int argc, char *argv[])
else
UseMsg();
}
-   else if (strcmp(argv[i], -pogo) == 0)
+   else if (strcmp(argv[i], -shutdown) == 0)
{
dispatchException = DE_TERMINATE;
}
-- 
1.7.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


[PATCH 06/15] os: remove superfluous +xinerama option

2010-10-28 Thread Tiago Vignatti
Worth to note that -xinerama changed behaviour now, thus enabling such
extension.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 hw/dmx/Xdmx.man  |   18 +-
 hw/dmx/config/test-k.in  |2 +-
 hw/dmx/config/test-k.out |2 +-
 os/utils.c   |   10 +++---
 4 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/hw/dmx/Xdmx.man b/hw/dmx/Xdmx.man
index 9c8bdea..3364e31 100644
--- a/hw/dmx/Xdmx.man
+++ b/hw/dmx/Xdmx.man
@@ -41,7 +41,7 @@ back-end X servers.  Clients connect to the
 .I Xdmx
 front-end, and everything appears as it would in a regular multi-head
 configuration.  If Xinerama is enabled (e.g., with
-.B +xinerama
+.B -xinerama
 on the command line), the clients see a single large screen.
 .PP
 .I Xdmx
@@ -544,7 +544,7 @@ command line option described above.
 .PP
 For example, if you specify a font path with the following command line:
 .RS
-Xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/ -fontpath /usr/fonts/Type1/ 
+xinerama
+Xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/ -fontpath /usr/fonts/Type1/ 
-xinerama
 .RE
 Then, /usr/fonts/75dpi/ and /usr/fonts/Type1/ must be valid font paths
 on the
@@ -556,7 +556,7 @@ Font servers can also be specified with the
 option.  For example, let's assume that a properly configured font
 server is running on host d0.  Then, the following command line
 .RS
-Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100 +xinerama
+Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100 -xinerama
 .RE
 will initialize the front-end
 .I Xdmx
@@ -595,23 +595,23 @@ option can also be added to the configuration file as 
described above.
 The back-end machines are d0 and d1, core input is from the pointer and
 keyboard attached to d0, clients will refer to :1 when opening windows:
 .RS
-Xdmx :1 -display d0:0 -display d1:0 +xinerama
+Xdmx :1 -display d0:0 -display d1:0 -xinerama
 .RE
 .PP
 As above, except with core input from d1:
 .RS
-Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama
+Xdmx :1 -display d0:0 -display d1:0 -input d1:0 -xinerama
 .RE
 .PP
 As above, except with core input from a console window on the local
 display:
 .RS
-Xdmx :1 -display d0:0 -display d1:0 -input :0 +xinerama
+Xdmx :1 -display d0:0 -display d1:0 -input :0 -xinerama
 .RE
 .PP
 As above, except with core input from the local keyboard and mouse:
 .RS
-Xdmx :1 -display d0:0 -display d1:0 -input local,kbd,ps2 +xinerama
+Xdmx :1 -display d0:0 -display d1:0 -input local,kbd,ps2 -xinerama
 .RE
 Note that local input can be used under Linux while another X session is
 running on :0 (assuming the user can access the Linux console tty and
@@ -623,11 +623,11 @@ Xdmx session and return to the original VC.
 .PP
 This example uses the configuration file shown in the previous section:
 .RS
-Xdmx :1 -input :0 +xinerama -configfile filename -config example2
+Xdmx :1 -input :0 -xinerama -configfile filename -config example2
 .RE
 With this configuration file line:
 .RS
-option -input :0 +xinerama;
+option -input :0 -xinerama;
 .RE
 the command line can be shortened to:
 .RS
diff --git a/hw/dmx/config/test-k.in b/hw/dmx/config/test-k.in
index 2218d26..823f2c5 100644
--- a/hw/dmx/config/test-k.in
+++ b/hw/dmx/config/test-k.in
@@ -1,3 +1,3 @@
 virtual a {
-option +xinerama -syncbatch 0;
+option -xinerama -syncbatch 0;
 }
diff --git a/hw/dmx/config/test-k.out b/hw/dmx/config/test-k.out
index ebd7439..f6ed97b 100644
--- a/hw/dmx/config/test-k.out
+++ b/hw/dmx/config/test-k.out
@@ -1,3 +1,3 @@
 virtual a {
-option +xinerama -syncbatch 0;
+option -xinerama -syncbatch 0;
 }
diff --git a/os/utils.c b/os/utils.c
index 98aabce..8ed0c7c 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -172,7 +172,7 @@ Bool noXFree86VidModeExtension = FALSE;
 Bool noXFixesExtension = FALSE;
 #endif
 #ifdef PANORAMIX
-/* Xinerama is disabled by default unless enabled via +xinerama */
+/* Xinerama is disabled by default unless enabled via -xinerama option */
 Bool noPanoramiXExtension = TRUE;
 #endif
 #ifdef XSELINUX
@@ -520,8 +520,7 @@ void UseMsg(void)
 ErrorF(-wrcreate root window with white 
background\n);
 ErrorF(-maxbigreqsize set maximal bigrequest size \n);
 #ifdef PANORAMIX
-ErrorF(+xinerama  Enable XINERAMA extension\n);
-ErrorF(-xinerama  Disable XINERAMA extension\n);
+ErrorF(-xinerama  Enable XINERAMA extension\n);
 #endif
 ErrorF(-dumbSched Disable smart scheduling, enable old 
behavior\n);
 ErrorF(-schedInterval int Set scheduler interval in msec\n);
@@ -856,11 +855,8 @@ ProcessCommandLine(int argc, char *argv[])
  }
  }
 #ifdef PANORAMIX
-   else if ( strcmp( argv[i], +xinerama) == 0){
-   noPanoramiXExtension = FALSE;
-   }
else if ( strcmp( argv[i], -xinerama) == 0){
-   noPanoramiXExtension = TRUE;
+   noPanoramiXExtension = FALSE;
}
else if ( strcmp( 

[PATCH 08/15] os: remove superfluous c option

2010-10-28 Thread Tiago Vignatti
key-click volume is set using -c, in which has changed the behaviour, not
turning off key-click anymore now. To turn it off now just use -c 0 instead.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 os/utils.c |9 ++---
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/os/utils.c b/os/utils.c
index 3a747ad..3a8e9cf 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -464,8 +464,7 @@ void UseMsg(void)
 ErrorF(-audit int set audit trail level\n);  
 ErrorF(-auth file select authorization file\n);  
 ErrorF(-bsenable any backing store support\n);
-ErrorF(-c turns off key-click\n);
-ErrorF(c #key-click volume (0-100)\n);
+ErrorF(-c #   key-click volume (0-100)\n);
 ErrorF(-cc intdefault color visual class\n);
 ErrorF(-nocursor  disable the cursor\n);
 ErrorF(-core  generate core dump on fatal error\n);
@@ -611,17 +610,13 @@ ProcessCommandLine(int argc, char *argv[])
}
else if ( strcmp( argv[i], -bs) == 0)
BackingStore = TRUE;
-   else if ( strcmp( argv[i], c) == 0)
+   else if ( strcmp( argv[i], -c) == 0)
{
if(++i  argc)
defaultKeyboardControl.click = atoi(argv[i]);
else
UseMsg();
}
-   else if ( strcmp( argv[i], -c) == 0)
-   {
-   defaultKeyboardControl.click = 0;
-   }
else if ( strcmp( argv[i], -cc) == 0)
{
if(++i  argc)
-- 
1.7.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


[PATCH 10/15] os: remove superfluous r option

2010-10-28 Thread Tiago Vignatti
kbd auto-repeat is on by default already.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 os/utils.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/os/utils.c b/os/utils.c
index e9280bb..7cee9c1 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -499,7 +499,6 @@ void UseMsg(void)
 ErrorF(-pnaccept failure to listen on all ports\n);
 ErrorF(-nopn  reject failure to listen on all ports\n);
 ErrorF(-r turns off auto-repeat\n);
-ErrorF(r  turns on auto-repeat \n);
 ErrorF(-render [default|mono|gray|color] set render color alloc 
policy\n);
 ErrorF(-retro start with classic stipple and cursor\n);
 ErrorF(-s #   screen-saver timeout (minutes)\n);
@@ -782,8 +781,6 @@ ProcessCommandLine(int argc, char *argv[])
PartialNetwork = TRUE;
else if ( strcmp( argv[i], -nopn) == 0)
PartialNetwork = FALSE;
-   else if ( strcmp( argv[i], r) == 0)
-   defaultKeyboardControl.autoRepeat = TRUE;
else if ( strcmp( argv[i], -r) == 0)
defaultKeyboardControl.autoRepeat = FALSE;
else if ( strcmp( argv[i], -retro) == 0)
-- 
1.7.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


[PATCH 01/15] os: remove superfluous -br option

2010-10-28 Thread Tiago Vignatti
There is no effect on using or not such option. Deprecate it.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 doc/Xserver.man.pre |4 
 os/utils.c  |2 --
 2 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/doc/Xserver.man.pre b/doc/Xserver.man.pre
index ce3b3a1..439e417 100644
--- a/doc/Xserver.man.pre
+++ b/doc/Xserver.man.pre
@@ -100,10 +100,6 @@ specifies a file which contains a collection of 
authorization records used
 to authenticate access.  See also the \fIxdm\fP(1) and 
 \fIXsecurity\fP(__miscmansuffix__) manual pages.
 .TP 8
-.B \-br
-sets the default root window to solid black instead of the standard root weave
-pattern.   This is the default unless -retro or -wr is specified.
-.TP 8
 .B \-bs
 disables backing store support on all screens.
 .TP 8
diff --git a/os/utils.c b/os/utils.c
index 8921d7c..760f2f9 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -467,7 +467,6 @@ void UseMsg(void)
 ErrorF(-acdisable access control restrictions\n);
 ErrorF(-audit int set audit trail level\n);  
 ErrorF(-auth file select authorization file\n);  
-ErrorF(-brcreate root window with black 
background\n);
 ErrorF(+bsenable any backing store support\n);
 ErrorF(-bsdisable any backing store support\n);
 ErrorF(-c turns off key-click\n);
@@ -616,7 +615,6 @@ ProcessCommandLine(int argc, char *argv[])
else
UseMsg();
}
-   else if ( strcmp( argv[i], -br) == 0) ; /* default */
else if ( strcmp( argv[i], +bs) == 0)
enableBackingStore = TRUE;
else if ( strcmp( argv[i], -bs) == 0)
-- 
1.7.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


[PATCH 11/15] os: standardize tty option to -tty instead

2010-10-28 Thread Tiago Vignatti
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 os/utils.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/os/utils.c b/os/utils.c
index 7cee9c1..2482ca1 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -506,7 +506,7 @@ void UseMsg(void)
 ErrorF(-terminate terminate at server reset\n);
 ErrorF(-to #  connection time out\n);
 ErrorF(-tst   disable testing extensions\n);
-ErrorF(ttyxx  server started from init on /dev/ttyxx\n);
+ErrorF(-ttyxx server started from init on /dev/ttyxx\n);
 ErrorF(v  video blanking for screen-saver\n);
 ErrorF(-v screen-saver without video blanking\n);
 ErrorF(-wmWhenMapped default backing-store\n);
@@ -846,7 +846,7 @@ ProcessCommandLine(int argc, char *argv[])
noPanoramiXExtension = FALSE;
}
 #endif
-   else if (strncmp (argv[i], tty, 3) == 0)
+   else if (strncmp (argv[i], -tty, 3) == 0)
{
 /* init supplies us with this useless information */
}
-- 
1.7.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


[PATCH 05/15] dix: xfree86: remove superfluous +br simplifying backing store support options

2010-10-28 Thread Tiago Vignatti
Worth to note that behaviour is changed: different from before, -bs now
enables backing store support on windows. By default it's disabled though as
it always been.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 dix/window.c|9 -
 hw/xfree86/common/xf86Globals.c |3 +--
 hw/xfree86/common/xf86Helper.c  |   10 +-
 hw/xfree86/common/xf86Init.c|8 +---
 hw/xfree86/common/xf86Priv.h|3 +--
 include/opaque.h|3 +--
 os/utils.c  |7 ++-
 7 files changed, 15 insertions(+), 28 deletions(-)

diff --git a/dix/window.c b/dix/window.c
index 1913030..8b90974 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -258,8 +258,7 @@ WalkTree(ScreenPtr pScreen, VisitWindowProcPtr func, 
pointer data)
 /* hack for forcing backing store on all windows */
 intdefaultBackingStore = NotUseful;
 /* hack to force no backing store */
-Bool   disableBackingStore = FALSE;
-Bool   enableBackingStore = FALSE;
+Bool   BackingStore = FALSE;
 
 static void
 SetWindowToDefaults(WindowPtr pWin)
@@ -435,10 +434,10 @@ CreateRootWindow(ScreenPtr pScreen)
 if (!AddResource(pWin-drawable.id, RT_WINDOW, (pointer)pWin))
return FALSE;
 
-if (disableBackingStore)
-   pScreen-backingStoreSupport = NotUseful;
-if (enableBackingStore)
+if (BackingStore)
pScreen-backingStoreSupport = Always;
+else
+   pScreen-backingStoreSupport = NotUseful;
 
 pScreen-saveUnderSupport = NotUseful;
 
diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index 3ec35a3..0194424 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -170,8 +170,7 @@ const char *xf86VisualNames[] = {
 /* Parameters set only from the command line */
 char *xf86ServerName = no-name;
 Bool xf86fpFlag = FALSE;
-Bool xf86bsEnableFlag = FALSE;
-Bool xf86bsDisableFlag = FALSE;
+Bool xf86bsFlag = FALSE;
 Bool xf86silkenMouseDisableFlag = FALSE;
 Bool xf86xkbdirFlag = FALSE;
 #ifdef HAVE_ACPI
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index 67be200..0960c44 100644
--- a/hw/xfree86/common/xf86Helper.c
+++ b/hw/xfree86/common/xf86Helper.c
@@ -1831,16 +1831,16 @@ xf86SetBackingStore(ScreenPtr pScreen)
 xf86ProcessOptions(pScrn-scrnIndex, pScrn-options, options);
 
 /* check for commandline option here */
-if (xf86bsEnableFlag) {
+if (xf86bsFlag) {
from = X_CMDLINE;
useBS = TRUE;
-} else if (xf86bsDisableFlag) {
+} else {
from = X_CMDLINE;
useBS = FALSE;
-} else {
-   if (xf86GetOptValBool(options, OPTION_BACKING_STORE, useBS))
-   from = X_CONFIG;
 }
+if (xf86GetOptValBool(options, OPTION_BACKING_STORE, useBS))
+   from = X_CONFIG;
+
 free(options);
 pScreen-backingStoreSupport = useBS ? Always : NotUseful;
 if (serverGeneration == 1)
diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index 533bbd7..987a1be 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -1185,13 +1185,7 @@ ddxProcessArgument(int argc, char **argv, int i)
   /* Notice the -bs flag, but allow it to pass to the dix layer */
   if (!strcmp(argv[i], -bs))
   {
-xf86bsDisableFlag = TRUE;
-return 0;
-  }
-  /* Notice the +bs flag, but allow it to pass to the dix layer */
-  if (!strcmp(argv[i], +bs))
-  {
-xf86bsEnableFlag = TRUE;
+xf86bsFlag = TRUE;
 return 0;
   }
   if (!strcmp(argv[i], -pixmap24))
diff --git a/hw/xfree86/common/xf86Priv.h b/hw/xfree86/common/xf86Priv.h
index 0d8506b..2e406bc 100644
--- a/hw/xfree86/common/xf86Priv.h
+++ b/hw/xfree86/common/xf86Priv.h
@@ -51,8 +51,7 @@ extern _X_EXPORT  Bool xf86VidModeDisabled;
 extern _X_EXPORT  Bool xf86VidModeAllowNonLocal;
 #endif 
 extern _X_EXPORT  Bool xf86fpFlag;
-extern _X_EXPORT  Bool xf86bsEnableFlag;
-extern _X_EXPORT  Bool xf86bsDisableFlag;
+extern _X_EXPORT  Bool xf86bsFlag;
 extern _X_EXPORT  Bool xf86silkenMouseDisableFlag;
 extern _X_EXPORT  Bool xf86xkbdirFlag;
 #ifdef HAVE_ACPI
diff --git a/include/opaque.h b/include/opaque.h
index dfe440c..7919e4a 100644
--- a/include/opaque.h
+++ b/include/opaque.h
@@ -52,8 +52,7 @@ extern _X_EXPORT int defaultScreenSaverAllowExposures;
 extern _X_EXPORT char *display;
 
 extern _X_EXPORT int defaultBackingStore;
-extern _X_EXPORT Bool disableBackingStore;
-extern _X_EXPORT Bool enableBackingStore;
+extern _X_EXPORT Bool BackingStore;
 extern _X_EXPORT Bool PartialNetwork;
 extern _X_EXPORT Bool RunFromSigStopParent;
 #ifndef NOLOGOHACK
diff --git a/os/utils.c b/os/utils.c
index 760f2f9..98aabce 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -467,8 +467,7 @@ void UseMsg(void)
 ErrorF(-acdisable access control restrictions\n);
 ErrorF(-audit int set audit trail level\n);  
 ErrorF(-auth file select authorization file\n);  
-ErrorF(+bs

[PATCH 03/15] xfree86: remove unused -s option

2010-10-28 Thread Tiago Vignatti
Such option sets xf86sFlag, which is unused.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
 hw/xfree86/common/xf86Globals.c |1 -
 hw/xfree86/common/xf86Init.c|6 --
 hw/xfree86/common/xf86Priv.h|1 -
 3 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index 781ee49..3ec35a3 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -170,7 +170,6 @@ const char *xf86VisualNames[] = {
 /* Parameters set only from the command line */
 char *xf86ServerName = no-name;
 Bool xf86fpFlag = FALSE;
-Bool xf86sFlag = FALSE;
 Bool xf86bsEnableFlag = FALSE;
 Bool xf86bsDisableFlag = FALSE;
 Bool xf86silkenMouseDisableFlag = FALSE;
diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index 65afa0a..1ea8322 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -1194,12 +1194,6 @@ ddxProcessArgument(int argc, char **argv, int i)
 xf86bsEnableFlag = TRUE;
 return 0;
   }
-  /* Notice the -s flag, but allow it to pass to the dix layer */
-  if (!strcmp(argv[i], -s))
-  {
-xf86sFlag = TRUE;
-return 0;
-  }
   if (!strcmp(argv[i], -pixmap24))
   {
 xf86Pix24 = Pix24Use24;
diff --git a/hw/xfree86/common/xf86Priv.h b/hw/xfree86/common/xf86Priv.h
index 08c0fa9..0d8506b 100644
--- a/hw/xfree86/common/xf86Priv.h
+++ b/hw/xfree86/common/xf86Priv.h
@@ -51,7 +51,6 @@ extern _X_EXPORT  Bool xf86VidModeDisabled;
 extern _X_EXPORT  Bool xf86VidModeAllowNonLocal;
 #endif 
 extern _X_EXPORT  Bool xf86fpFlag;
-extern _X_EXPORT  Bool xf86sFlag;
 extern _X_EXPORT  Bool xf86bsEnableFlag;
 extern _X_EXPORT  Bool xf86bsDisableFlag;
 extern _X_EXPORT  Bool xf86silkenMouseDisableFlag;
-- 
1.7.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


[PATCH 15/15] dix: delete logo hack screen saver

2010-10-28 Thread Tiago Vignatti
Protocol doesn't mention about screen saver with logo being required and
people are already using more intelligent ways to draw screen saver themes. So
consider -logo as deprecated option, deleting its code.

Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
Reviewed-by: Mikhail Gusarov dotted...@dottedmag.net
Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com
Reviewed-by: Daniel Stone dan...@fooishbar.org
---
 dix/globals.c   |4 -
 dix/window.c|  200 ---
 doc/Xserver.man.pre |8 --
 include/opaque.h|3 -
 include/site.h  |3 -
 os/utils.c  |   14 
 6 files changed, 0 insertions(+), 232 deletions(-)

diff --git a/dix/globals.c b/dix/globals.c
index b128569..0a6b170 100644
--- a/dix/globals.c
+++ b/dix/globals.c
@@ -106,10 +106,6 @@ CARD32 defaultScreenSaverTime = DEFAULT_SCREEN_SAVER_TIME;
 CARD32 defaultScreenSaverInterval = DEFAULT_SCREEN_SAVER_INTERVAL;
 int  defaultScreenSaverBlanking = DEFAULT_SCREEN_SAVER_BLANKING;
 int  defaultScreenSaverAllowExposures = DEFAULT_SCREEN_SAVER_EXPOSURES;
-#ifndef NOLOGOHACK
-int  logoScreenSaver = DEFAULT_LOGO_SCREEN_SAVER;
-#endif
-
 #ifdef SCREENSAVER
 Bool screenSaverSuspended = FALSE;
 #endif
diff --git a/dix/window.c b/dix/window.c
index 8b90974..6c3d62b 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -3086,13 +3086,6 @@ SendVisibilityNotify(WindowPtr pWin)
 }
 
 #define RANDOM_WIDTH 32
-
-#ifndef NOLOGOHACK
-static void DrawLogo(
-WindowPtr pWin
-);
-#endif
-
 int
 dixSaveScreens(ClientPtr client, int on, int mode)
 {
@@ -3154,18 +3147,10 @@ dixSaveScreens(ClientPtr client, int on, int mode)
 * for the root window, so miPaintWindow works
 */
screenIsSaved = SCREEN_SAVER_OFF;
-#ifndef NOLOGOHACK
-   if (logoScreenSaver)
-   (*pWin-drawable.pScreen-ClearToBackground)(pWin, 0, 0, 0, 
0, FALSE);
-#endif
(*pWin-drawable.pScreen-MoveWindow)(pWin,
   (short)(-(rand() % RANDOM_WIDTH)),
   (short)(-(rand() % RANDOM_WIDTH)),
   pWin-nextSib, VTMove);
-#ifndef NOLOGOHACK
-   if (logoScreenSaver)
-   DrawLogo(pWin);
-#endif
screenIsSaved = SCREEN_SAVER_ON;
}
/*
@@ -3323,10 +3308,6 @@ TileScreenSaver(ScreenPtr pScreen, int kind)
(*pWin-drawable.pScreen-ChangeWindowAttributes)(pWin, CWBackPixmap);
 }
 MapWindow(pWin, serverClient);
-#ifndef NOLOGOHACK
-if (kind == SCREEN_IS_TILED  logoScreenSaver)
-   DrawLogo(pWin);
-#endif
 return TRUE;
 }
 
@@ -3672,184 +3653,3 @@ WindowParentHasDeviceCursor(WindowPtr pWin,
 }
 return FALSE;
 }
-
-#ifndef NOLOGOHACK
-static void
-DrawLogo(WindowPtr pWin)
-{
-DrawablePtr pDraw;
-ScreenPtr pScreen;
-int x, y;
-unsigned int width, height, size;
-GC *pGC;
-int rc, thin, gap, d31;
-DDXPointRec poly[4];
-ChangeGCVal fore[2], back[2];
-xrgb rgb[2];
-BITS32 fmask, bmask;
-ColormapPtr cmap;
-
-pDraw = (DrawablePtr)pWin;
-pScreen = pDraw-pScreen;
-x = -pWin-origin.x;
-y = -pWin-origin.y;
-width = pScreen-width;
-height = pScreen-height;
-pGC = GetScratchGC(pScreen-rootDepth, pScreen);
-if (!pGC)
-   return;
-
-if ((rand() % 100) = 17) /* make the probability for white fairly low */
-   fore[0].val = pScreen-whitePixel;
-else
-   fore[0].val = pScreen-blackPixel;
-if (pWin-backgroundState == BackgroundPixel) {
-   rc = dixLookupResourceByType((pointer *)cmap, wColormap(pWin),
-RT_COLORMAP, serverClient, DixReadAccess);
-   if (rc == Success) {
-   Pixel querypixels[2];
-
-   querypixels[0] = fore[0].val;
-   querypixels[1] = pWin-background.pixel;
-   QueryColors(cmap, 2, querypixels, rgb, serverClient);
-   if ((rgb[0].red == rgb[1].red) 
-   (rgb[0].green == rgb[1].green) 
-   (rgb[0].blue == rgb[1].blue)) {
-   if (fore[0].val == pScreen-blackPixel)
-   fore[0].val = pScreen-whitePixel;
-   else
-   fore[0].val = pScreen-blackPixel;
-   }
-   }
-}
-fore[1].val = FillSolid;
-fmask = GCForeground|GCFillStyle;
-if (pWin-backgroundState == BackgroundPixel) {
-   back[0].val = pWin-background.pixel;
-   back[1].val = FillSolid;
-   bmask = GCForeground|GCFillStyle;
-} else {
-   back[0].val = 0;
-   back[1].val = 0;
-   ChangeGC(NullClient, pGC, GCTileStipXOrigin|GCTileStipYOrigin, back);
-   back[0].val = FillTiled;
-   back[1].ptr = pWin-background.pixmap;
-   bmask = GCFillStyle|GCTile;
-}
-
-/* should be the same as the reference function XmuDrawLogo() */
-
-size = width;
-if (height  width)
-size = height;
-size = 

Re: [PATCH] [RFC] xinerama: attempt to unify the two protocol implementations.

2010-10-28 Thread Adam Jackson
On Tue, 2010-10-26 at 14:46 +1000, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 randr and panoramiX have had two separate copies of this code for long enough,
 
 this patch sets up a separate xinerama protocol that both randr and panoramix
 call into to configure what is sent on the wire.
 
 this needs a lot more testing and fair bit of review, but this is a first
 cut to see if people agree with the idea.

Looks like a good start, but.

 +struct XineramaProtoRec {
 +int num_screens;
 +int ids[MAXSCREENS];
 +xXineramaScreenInfo info[MAXSCREENS];
 +Bool primary[MAXSCREENS];
 +};

I'm not a huge fan of this, on an Evergreen this means you don't even
scale to three cards.

 +int XineramaProtoInit(void (*reset_proc)(ExtensionEntry *extEntry))
 +{
 +ExtensionEntry   *extEntry;
 +
 +extEntry = AddExtension(PANORAMIX_PROTOCOL_NAME, 0, 0,
 + ProcXineramaProtoDispatch,
 + SProcXineramaProtoDispatch,
 + reset_proc,
 + StandardMinorOpcode);
 +
 +if (!extEntry)
 + return -1;
 +xineramaProtoEnabled = TRUE;
 +return 0;
 +}

This is broken if both Xinerama and RANDR are active, AddExtension isn't
prepared to be called multiple times for the same protocol name.  More
like:

static ExtensionEntry *extEntry;

if (!extEntry)
extEntry = AddExtension();
if (!extEntry)
return -1;
/* ... */

 +int XineramaProtoRegisterScreen(int id, xXineramaScreenInfo *info, Bool 
 primary)

Nitpicking: This should probably come with documentation that 'id'
should be an XID so as to be unique across backends (assuming we want
TwinView and RANDR drivers to have consistent Xinerama geometry, which,
we might as well).  Also, no need for it to return int if it's never
going to fail.

Design: I'm pretty sure this approach is broken.  Imagine having
PanoramiXExtensionInit called, and then RANDR active (on one or more of
the backend ScreenRecs). You'll have panoramix-level boxes for each
ScreenRec, and then randr-level boxes for each CRTC on each randrful
ScreenRec.  That ain't right.

The way I'd tried this before was by adding a GetScreenBoxes hook to the
ScreenRec and then having the Xin protocol pull information out of that
(with an mi version that just returns the dumb screen geometry).  Which
is irritating for a couple of reasons, you have to loop over all
ScreenRecs to build them all up, and then loop over them all again
looking for the primary (and then again for the boring ones).  It's also
not terribly efficient, but queries are rare so maybe it doesn't matter.

I think I still have the code for that, I'll try to dig it up.

- ajax


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: Fixing screen savers

2010-10-28 Thread Adam Jackson
On Mon, 2010-10-25 at 12:02 -0700, Keith Packard wrote:

 However, looking at the code, I think there's a simpler mechanism already
 available to us:
 
  * Register a screen saver window with XScreenSaverSetAttributes. This
ensures that automatic screen saving will not turn off the screen.
I can't figure out how this window could be useful to us as it gets
automatically destroyed when the screen is unsaved, and so cannot
be used for a transition or lock screen dialog.
 
  * Monitor screen saver timeouts using the existing XScreenSaver events.
 
  * Disable the DPMS extension by setting the DPMS timeouts to all zeros.
The DPMS code doesn't respect the X screen saver extension's external
screen saver mode. (note A*)
 
  * Control DPMS on the monitors by using DPMSForceLevel. This will
generate another screen saver event, but that will have the 'force'
value set to TRUE.

This sounds like it's ignoring per-output DPMS.

I kind of want to drop the DPMS extension entirely if we can.  It's
really quite awful to implement since it's per-display state not
per-screen.  I'm not sure how much existing code relies on it though.

- ajax


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 1/4] dix: Provide means to report exact sizes of resources.

2010-10-28 Thread Alan Coopersmith

 +/**
 + * Get the function used to calculate resource size. Extensions and
 + * drivers need to be able to determine the current size calculation
 + * function if they want to wrap or override it.
 + *
 + * @param[in] type Resource type used in size calculations.
 + *
 + * @return Function to calculate the size of a single
 + * resource.
 + */
 +SizeType
 +GetResourceTypeSizeFunc(RESTYPE type)
 +{
 +return resourceTypes[type  TypeMask].sizeFunc;
 +}

Should this add dixPrivatesSize(type) to the result or should the callers
like Xresource be doing that?

-- 
-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 00/15] xserver: cleanup and standardize startup options

2010-10-28 Thread Alan Coopersmith
Tiago Vignatti wrote:
 Hi fellows,
 
 Our culture is turning -option the default syntax for arguments to be passed
 to the server. This patch set tries to standardize the rest of arguments that
 are not on such shape yet, removing some superfluous ones and also doing some
 other janitor work around.
 
 I tried to be very conservative in this patchset, avoiding to do major
 changes on behaviour. 

Very conservative is not changing any existing working configs into
things that generate errors and fail to start the X server because
their options are now invalid.   This series doesn't seem to qualify
as very conservative.

-- 
-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 13/15] os: standardize option to enabling/disabling extensions

2010-10-28 Thread Alan Coopersmith
You really hate our users don't you?   Not just breaking their configurations,
but leaving the man pages full of the old option names so they have no idea how
to fix them.

-alan-

Tiago Vignatti wrote:
 +extension - -enableext
 -extension - -disableext
 
 Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
 ---
  os/utils.c |8 
  1 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/os/utils.c b/os/utils.c
 index 0a4fca4..2f6eb0c 100644
 --- a/os/utils.c
 +++ b/os/utils.c
 @@ -517,8 +517,8 @@ void UseMsg(void)
  ErrorF(-dumbSched Disable smart scheduling, enable old 
 behavior\n);
  ErrorF(-schedInterval int Set scheduler interval in msec\n);
  ErrorF(-sigstop   Enable SIGSTOP based startup\n);
 -ErrorF(+extension nameEnable extension\n);
 -ErrorF(-extension nameDisable extension\n);
 +ErrorF(-enableext nameEnable extension\n);
 +ErrorF(-disableext name   Disable extension\n);
  #ifdef XDMCP
  XdmcpUseMsg();
  #endif
 @@ -894,7 +894,7 @@ ProcessCommandLine(int argc, char *argv[])
   {
   RunFromSigStopParent = TRUE;
   }
 - else if ( strcmp( argv[i], +extension) == 0)
 + else if ( strcmp( argv[i], -enableext) == 0)
   {
   if (++i  argc)
   {
 @@ -904,7 +904,7 @@ ProcessCommandLine(int argc, char *argv[])
   else
   UseMsg();
   }
 - else if ( strcmp( argv[i], -extension) == 0)
 + else if ( strcmp( argv[i], -disableext) == 0)
   {
   if (++i  argc)
   {


-- 
-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 11/15] os: standardize tty option to -tty instead

2010-10-28 Thread Alan Coopersmith
That's an argument, not an option - it shouldn't start with a -,
just as the vtxx doesn't.

-alan-

Tiago Vignatti wrote:
 Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
 ---
  os/utils.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/os/utils.c b/os/utils.c
 index 7cee9c1..2482ca1 100644
 --- a/os/utils.c
 +++ b/os/utils.c
 @@ -506,7 +506,7 @@ void UseMsg(void)
  ErrorF(-terminate terminate at server reset\n);
  ErrorF(-to #  connection time out\n);
  ErrorF(-tst   disable testing extensions\n);
 -ErrorF(ttyxx  server started from init on 
 /dev/ttyxx\n);
 +ErrorF(-ttyxx server started from init on 
 /dev/ttyxx\n);
  ErrorF(v  video blanking for screen-saver\n);
  ErrorF(-v screen-saver without video blanking\n);
  ErrorF(-wmWhenMapped default backing-store\n);
 @@ -846,7 +846,7 @@ ProcessCommandLine(int argc, char *argv[])
   noPanoramiXExtension = FALSE;
   }
  #endif
 - else if (strncmp (argv[i], tty, 3) == 0)
 + else if (strncmp (argv[i], -tty, 3) == 0)
   {
  /* init supplies us with this useless information */
   }


-- 
-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 05/15] dix: xfree86: remove superfluous +br simplifying backing store support options

2010-10-28 Thread Alan Coopersmith
Tiago Vignatti wrote:
 -ErrorF(+bsenable any backing store support\n);

Your subject says +br, your code says +bs

-- 
-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 00/15] xserver: cleanup and standardize startup options

2010-10-28 Thread Kristian Høgsberg
On Thu, Oct 28, 2010 at 10:08 AM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
 Tiago Vignatti wrote:
 Hi fellows,

 Our culture is turning -option the default syntax for arguments to be 
 passed
 to the server. This patch set tries to standardize the rest of arguments that
 are not on such shape yet, removing some superfluous ones and also doing some
 other janitor work around.

 I tried to be very conservative in this patchset, avoiding to do major
 changes on behaviour.

 Very conservative is not changing any existing working configs into
 things that generate errors and fail to start the X server because
 their options are now invalid.   This series doesn't seem to qualify
 as very conservative.

I agree, this is not something we can change.

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

Re: [PATCH 1/4] dix: Provide means to report exact sizes of resources.

2010-10-28 Thread Rami Ylimäki

 On 10/28/2010 04:48 PM, Alan Coopersmith wrote:

+/**
+ * Get the function used to calculate resource size. Extensions and
+ * drivers need to be able to determine the current size calculation
+ * function if they want to wrap or override it.
+ *
+ * @param[in] type Resource type used in size calculations.
+ *
+ * @return Function to calculate the size of a single
+ * resource.
+ */
+SizeType
+GetResourceTypeSizeFunc(RESTYPE type)
+{
+return resourceTypes[type  TypeMask].sizeFunc;
+}

Should this add dixPrivatesSize(type) to the result or should the callers
like Xresource be doing that?



The original intention was that Xresource wouldn't do that automatically 
and the functions returned by that getter would calculate the size as 
well as they can. The resourceSize field of ResourceSizeRec should be 
filled with the amount of memory that is freed when the resource doesn't 
exist anymore.


It's probably best to add sizeof(PixmapRec) and 
dixPrivatesSize(PIXMAP_PRIVATE) to the result in GetPixmapBytes to get 
better estimate for the size and also to make GetPixmapBytes an example 
for other size calculation functions. I can do that in v2 of the patch 
if this change seems sensible to you.


-- Rami

___
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 01/15] os: remove superfluous -br option

2010-10-28 Thread Alan Coopersmith
Tiago Vignatti wrote:
 There is no effect on using or not such option. Deprecate it.

Deprecate can mean stop listing it in the options list or issue a
warning - not completely remove.

NAK to this one since it was widely used in display manager configs
to enable this feature before we turned it on by default, allows them
to keep those configs independent of the Xorg version, and protects
them against us changing our mind about what the default should be.

The cost of removal is simply far far higher than the cost of keeping
it - all removal buys us is removing 2 lines of code out of a million,
and a couple strcmp() calls on startup that no one will ever be able
to measure the performance impact of.


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


[OT] Server size (Was: Re: [PATCH 01/15] os: remove superfluous -br option)

2010-10-28 Thread Mikhail Gusarov

Twas brillig at 08:37:38 28.10.2010 UTC-07 when
alan.coopersm...@oracle.com did gyre and gimble:

 AC The cost of removal is simply far far higher than the cost of keeping
 AC it - all removal buys us is removing 2 lines of code out of a million,

~500 kLOC actually already (It was ~1MLOC in 1.1 -- nice shrinkage, I
think).

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


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

Re: [PATCH 2/2] DRI2: Add error message when working around driver bug

2010-10-28 Thread Pauli Nieminen
On 27/10/10 17:57 +0200, ext Jesse Barnes wrote:
 On Wed, 27 Oct 2010 17:15:28 +0200
 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
 
  On Oct 26, 2010, at 7:08 PM, Jesse Barnes wrote:
  
   On Tue, 26 Oct 2010 19:19:11 +0300
   Pauli Nieminen ext-pauli.niemi...@nokia.com wrote:
   SGI_video_sync:
   The kernel maintains a video sync counter for
   each physical hardware pipe in a system; the counter is incremented
   upon the completion of the display of each full frame of video  
   data. An
   OpenGL context always corresponds to a pipe.
  
   Right, this is the rule we break; we don't have a 1:1 correspondence
   between gfx pipes and display pipes.
  
   The single video sync counter is shared by all GLXContexts.
  
   Yes. You have to extent both OML_sync_control and SGI_video_sync  
   to expose
   separate MSC for different CRTCs.
  
   I can see race condition even with events.
  
   * Client checks for event (none yet in queue)
   * Client prepares to call some blocking msc call
   * Window manager decides to move the window
   * xserver send MSC change event
   * Client calls blocking MSC call
  
   But maybe there is solution. All blocking calls could fail if MSC  
   base
   changes. Client would have to query for new base and rate before  
   trying to
   issue same request again.
  
   Yeah, that might work; I agree there's a race even with events that
   we'll need to handle.  But even with that race handled I'd like the
   server to fail gracefully rather than hanging the app if an old MSC
   value is passed in (though in that case we could print an error  
   message
   since we could assume an app error as long as the app was using the
   extended version of the spec).
  
   For swap interval it would be enough if DDX would notify DRI2  
   about crtc
   changes with offset (msc_for_new_crtc - msc_for_old_crtc) that can  
   be applied
   to swaptarget.
  
   Yeah, just jumping to the new value might be ok in general.  Hardcore
   libraries like Mario's can do something fancier with the extensions
   above to avoid unintended behavior.
  
  
  I agree. Pauli's offset fix would fix the common glXSwapBuffers()  
  case for now and make most apps happy. We should do that. My current  
  hack works fine (due to the underlying vsync'ing of the ddx's) as  
  long as an app uses glXSwapBuffers and has swap_interval left at its  
  default of 1. I'd expect most apps to do that, as it was the only  
  supported setting (except for 0) for a long time, and all other  
  operating systems i know of (Linux + proprietary drivers, all  
  Windows, all OS/X) only obey a swap_interval = 0 or 1, but this fix  
  would fix it for all swap_interval settings.
  
  For the oml_sync_control case i see these options, and each of them  
  makes me dizzy and uneasy in a different way, probably because i  
  didn't think it through clearly:
  
  a) As Michel Daenzer proposed earlier, give each drawable its own  
  virtualized msc. Initialize it at drawable creation time to the true  
  msc of the initial crtc. Then just use the current msc and info about  
  crtc transitions to update the virtualized msc. This way we'd be  
  probably closest to the spirit of the current spec, all msc's would  
  always increase monotonically instead of jumping back and forth and  
  crtc transitions would be handled properly without the app even  
  noticing or needing to care. If multiple drawable's are created on  
  the same crtc and stay there, they'll have the same msc's,  so  
  bufferswaps, waits and other events can be synchronized across  
  drawables and timestamps and counts compared meaningfully between  
  them. That would be nice to have.
  
  Downside: As soon as a drawable moves away to another crtc with  
  different count, this beauty breaks down and the app would have large  
  problems finding out what just happened to it and how to relate the  
  msc's of different drawables to each other again. Possibly impossible  
  to recover with all those virtualized counts.
  
  Also it's tricky to implement. We would need to translate forward and  
  backward between hardware msc's and virtualized msc each time we get  
  any event from the kernel or schedule one and keep track of which  
  crtc was assigned when all the time, also in all queued vblank events  
  and all returned vblank and swap events.
  
  The fact that we currently have 64 bit msc counters in userspace and  
  spec, but only  32 bit counters in kernel space and all the  
  wraparound issues doesn't make it simpler to get right and race-free.
  
  b) Extend the spec:  If a crtc transition is detected, make all calls  
  that rely on the msc (glXSwapBuffersMsc(), glXWaitForMsc()) fail with  
  some error code until the app has called glXGetSyncValuesOML() again  
  to fetch the new, updated msc for the new crtc.
  
  I like this because i think it is simpler to implement correctly and  
  because the apps still see what is really going on. 

Re: [PATCH 00/15] xserver: cleanup and standardize startup options

2010-10-28 Thread Alan Coopersmith
Kristian Høgsberg wrote:
 On Thu, Oct 28, 2010 at 10:08 AM, Alan Coopersmith
 alan.coopersm...@oracle.com wrote:
 Tiago Vignatti wrote:
 Hi fellows,

 Our culture is turning -option the default syntax for arguments to be 
 passed
 to the server. This patch set tries to standardize the rest of arguments 
 that
 are not on such shape yet, removing some superfluous ones and also doing 
 some
 other janitor work around.

 I tried to be very conservative in this patchset, avoiding to do major
 changes on behaviour.
 Very conservative is not changing any existing working configs into
 things that generate errors and fail to start the X server because
 their options are now invalid.   This series doesn't seem to qualify
 as very conservative.
 
 I agree, this is not something we can change.

I'm not sure I'd say none of them can change, some of the proposed patches are
for options I'd expect few people use - unfortunately we have no way of knowing
the real world usage of these and how widespread or unused they are.

Certainly for the ones we know people use, a sudden flag day approach where
one day the old option works and the next day the new one does, with no
transition in the middle where both work, is not a very friendly way to do it.

A developer friendly approach would leave enough of a transition that you're
not likely to get broken every time you git bisect or switch from master to
the 1.9 branch to check your backports.

A distro friendly approach widens that so that distros don't have to have
complex constraints on their packaging, enforcing that if you install Xorg =
1.9.x you get an old version of their display manager config package and if you
install Xorg = 1.10 you get the new version and the two must be kept strictly
in sync.

A user friendly approach doesn't just take your existing config and return
Fatal error: invalid option, but Warning: +extension is deprecated, change
your config to -extenable in one version, and Error: +extension has been
replaced by -extenable in a later release.

I am as disgusted by the X server command line syntax as everyone else, but I
also actually answer questions from users on #xorg  x...@lists.fd.o as well
as our distro-specific lists, plus have to deal with the bug reports and
coordination with our gnome team to fix the gdm config in our distro - changes
like this have a large impact and can be painful if done harshly and without
consideration for the actual users.   #xorg and the mailing lists are still
filled regularly with users very confused about how to configure their mouse
and keyboard now - the xorg.conf.d system is clearly better, and several distros
have written nice web pages we can point to with explanations, but we are still
paying the price of our HAL mistake and the churn and confusion caused.

-- 
-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: Fixing screen savers

2010-10-28 Thread Keith Packard
On Thu, 28 Oct 2010 09:03:00 -0400, Adam Jackson a...@nwnk.net wrote:

 This sounds like it's ignoring per-output DPMS.

We don't have per-output DPMS in RandR yet.

 I kind of want to drop the DPMS extension entirely if we can.  It's
 really quite awful to implement since it's per-display state not
 per-screen.  I'm not sure how much existing code relies on it though.

I'd be up for that. Not having it at all would simplify the code
tremendously. My main concern is whether the ability to control all
three DPMS intervals is required by any standard or legislation. What I
don't want to see is some additional external configuration for DPMS
intervals.

-- 
keith.pack...@intel.com


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

Re: [OT] Server size (Was: Re: [PATCH 01/15] os: remove superfluous -br option)

2010-10-28 Thread Tiago Vignatti
On Thu, Oct 28, 2010 at 07:41:22PM +0400, ext Mikhail Gusarov wrote:
 
 Twas brillig at 08:37:38 28.10.2010 UTC-07 when
 alan.coopersm...@oracle.com did gyre and gimble:
 
  AC The cost of removal is simply far far higher than the cost of keeping
  AC it - all removal buys us is removing 2 lines of code out of a million,
 
 ~500 kLOC actually already (It was ~1MLOC in 1.1 -- nice shrinkage, I
 think).

you should count also protocol headers and some libraries involved. Then it's
very likely that would be close from 1MLOC.

 Tiago
___
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] DRI2: Add error message when working around driver bug

2010-10-28 Thread Jesse Barnes
On Thu, 28 Oct 2010 18:47:09 +0300
Pauli Nieminen ext-pauli.niemi...@nokia.com wrote:
  Most of what you have in (b) is pretty straightfoward; even the shared
  drawable case shouldn't be too bad, since each X connection could have
  bits indicating whether the counter has been picked up after a CRTC
  move.
 
 One option would be adding crct id parameter to calls.
 
 glXGetMscBaseRateOML would return rate, base msc and pipe id where this msc
 value is valid. Now all MSC calls would take the returned pipe id as
 parameter. If pipe id doesn't match current crtc any more then call would
 fail.
 
 This would allow complex applications to pass same pipe id to different
 context.
 
 Negative side is that API would have to be changed to include extra
 parameter.

Yeah that would be a good extension though; we may as well expose the
fact that different display pipes exist on the system, and have
corresponding MSCs.  Old applications using SGI_video_sync or existing
OML behavior would work like they do today (with an MSC value that may
jump, which we could fix with the virtualize count), and new ones would
be pipe aware.

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


Re: [PATCH] DRI2: Expose API to set drawable swap limit.

2010-10-28 Thread Pauli Nieminen
On 27/10/10 17:38 +0200, ext Mario Kleiner wrote:
 On Oct 26, 2010, at 10:35 AM, Pauli Nieminen wrote:
 
  On 26/10/10 02:54 +0200, ext Mario Kleiner wrote:
  On Oct 25, 2010, at 6:59 PM, Jesse Barnes wrote:
  On Mon, 25 Oct 2010 17:13:55 +0300
  Pauli Nieminen ext-pauli.niemi...@nokia.com wrote:
 
  This allows ddx to set swap_limit if there is more than one back
  buffer for drawable. Setting swap_limit has to also check if change
  affects a client that is blocked.
 
 
 ...
  +Bool
  +DRI2SwapLimit(DrawablePtr pDraw, int swap_limit)
  +{
  +DRI2DrawablePtr pPriv = DRI2GetDrawable(pDraw);
  +if (!pPriv)
  +return FALSE;
  +
  +pPriv-swap_limit = swap_limit;
  +
  +/* Check throttling */
  +if (pPriv-swapsPending = pPriv-swap_limit)
  +return TRUE;
  +
  +if (pPriv-target_sbc == -1  !pPriv-blockedOnMsc) {
  +if (pPriv-blockedClient) {
  +AttendClient(pPriv-blockedClient);
  +pPriv-blockedClient = NULL;
  +}
  +}
  +
  +return TRUE;
  +}
 
  Ja, i think the patch is ok for doing what it does. But i think it
  isn't sufficient to implement n-buffering reliably. We'd need more
  clever scheduling of swaps and vblank events if multiple swaps are
  pending.
 
 
 ... snip ...
 
  IMO, That is driver side problem. There is 2 thing missing in Intel  
  driver
  for this case.
 
  - Fair scheduling/GPU preemption.
 
  Preemption would give you better latency when there is multiple  
  clients with
  only one having expensive rendering operations.
 
  - Intel driver should have logic to synchronize flips with rendering.
 
  It is drivers job to know what goes on in HW side. That why Intel  
  driver
  should know when rendering completes and only after that assume  
  flip happens.
  If it doesn't do that then it is driver bug that has nothing to do  
  with DRI2
  swap limit.
 
 
 Yes, but it is a limitation that i think all drivers are sharing at  
 the moment.
 
 
  This patch doesn't change anything unless driver is ready to change
  swaplimit. Driver should change swaplimit only when it is good  
  enough to
  handle it.
 
 
 I'm not against merging your patch for changing the swap limit. I was  
 just summarizing for everybody the problems that current drivers (at  
 least intel and radeon and the kernel drm part of dri2) will have/ 
 cause for a swap_limit  1. However, currently your patch allows  
 changing the swap limit without approval from the ddx, which can't  
 handle swap_limit  1 reliably at the moment and that's not a bug of  
 the ddx but a valid limitation of the current ddx implementations.

 I think we should have some way for the drivers to back out of this  
 gracefully or at least cover their tails. E.g., allow the ddx to set  
 a hard upper limit for the swap_limit, in a new field max_swap_limit.  
 Your patch could make sure that swap_limit is never set to a value  
 higher than that. Then the intel and radeon ddx could set  
 max_swap_limit = 1 unless users somehow (xorg.conf option? dri.conf?)  
 opt into risky higher max_swap_limits.

True.

I intended DRI2SwapLimit to be called from DDX only. DDX only entry wouldn't
need any checks for limit changes.

If we assume that all calls to DRI2SwapLimit are anyway driver initiated then
max_swap_limits would only guard driver against it self.

I can add the max_swap_limit if there is real need for it.

 
 Or some part of the implementation (your patch? the ddx itself?)  
 should output some warning in the x log if a value is selected that  
 it can't reliably handle, so app developers aren't confused to death  
 about weird behaviour.
 

DDX would have to implement the option and warning.

 
  My idea was to solve it as follows for n-buffering. If somebody feels
  like implementing that or something better now, instead of me in a
  couple of weeks or months, go for it:
 
  1. We maintain a little fifo queue / list of pending swap requests
  for each drawable.
  2. The DRI2ScheduleSwap() function just converts the incoming
  swapbuffers request into a little struct with all the parameters
  (target_msc, divisor, remainder, ...) and inserts it at the tail of
  that queue, after checking that swaps_pending  current swaplimit.
  If  (++swaps_pending) == 1, it kicks off a little
  DRI2ReallyScheduleOneSwap() function which dequeues this first
  request from the queue and calls into the ddx-ScheduleSwap()
  routine. At the end of the DRI2SwapComplete() function, when a swap
  really got completed, that DRI2ReallyScheduleOneSwap() function gets
  called and checks if more swap requests are pending in the queue and
  dequeues and processes the oldest request. If the queue is empty, it
  is a no op and the whole thing goes idle again. Maybe
  DRI2ReallyScheduleOneSwap() would also take care of msc jumps due to
  drawables being moved between crtc's etc.
 
  This can't perfectly solve delays in one swapbuffer request due to
  traffic jams in the command stream, but 

Re: [PATCH 2/2] DRI2: Add error message when working around driver bug

2010-10-28 Thread Pauli Nieminen
On 28/10/10 18:06 +0200, Ville Syrjälä wrote:
 On Thu, Oct 28, 2010 at 05:47:09PM +0200, ext Pauli Nieminen wrote:
  One option would be adding crct id parameter to calls.
  
  glXGetMscBaseRateOML would return rate, base msc and pipe id where this msc
  value is valid. Now all MSC calls would take the returned pipe id as
  parameter. If pipe id doesn't match current crtc any more then call would
  fail.
  
  This would allow complex applications to pass same pipe id to different
  context.
  
  Negative side is that API would have to be changed to include extra
  parameter.
 
 And what about cases involving multiple CRTCs? Would the user just
 choose one? And what about the other CRTCs then, could some suffer from
 tearing or should more buffers be added to the mix to allow the CRTCs
 to scan out of different buffers and flip at their own rate?
 

But for common case it should be enough to use N-buffering for good
performance and fairly good timing. Driver can do fairly good decision when
flip should happen for each CRTCs.

Some clients might want to be aware of mirrored or extended rendering target.
But that can be exposed in separate extension.

Pauli

___
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] DRI2: Add error message when working around driver bug

2010-10-28 Thread Ville Syrjälä
On Thu, Oct 28, 2010 at 05:47:09PM +0200, ext Pauli Nieminen wrote:
 One option would be adding crct id parameter to calls.
 
 glXGetMscBaseRateOML would return rate, base msc and pipe id where this msc
 value is valid. Now all MSC calls would take the returned pipe id as
 parameter. If pipe id doesn't match current crtc any more then call would
 fail.
 
 This would allow complex applications to pass same pipe id to different
 context.
 
 Negative side is that API would have to be changed to include extra
 parameter.

And what about cases involving multiple CRTCs? Would the user just
choose one? And what about the other CRTCs then, could some suffer from
tearing or should more buffers be added to the mix to allow the CRTCs
to scan out of different buffers and flip at their own rate?

-- 
Ville Syrjälä
___
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: [ANNOUNCE] libXcomposite 0.4.3

2010-10-28 Thread Gaetan Nadon
On Wed, 2010-10-27 at 23:27 -0700, Jeremy Huddleston wrote:

 It looks like libXcomposite doesn't have a --disable-docs,
 --disable-specs, nor --disable-docs-devel, but it does have
 --without-fop ... 

I don't see a --without-fop configuration option. It goes from XML to
man, no html, pdf, ps or txt format.

 
 Is there a reason why the docs/specs/docs-devel option is missing even
 though fop is there?  I was under the impression that the tool options
 were extra knobs to turn that only mattered if docs/specs/docs-devel
 were enabled.
 


libXcomposite does not have any general documentation, functional specs
or developer's documentation. It has man pages where the input format is
DocBook XML and therefore uses xmlto. One can use --without-xmlto to
disable the generation of man pages.

The are 3 modules in that situation as described in
http://www.x.org/wiki/Development/Documentation/WritingDocumentation.
The classification of DOCS/SPECS/DEVEL-DOCS applies irrespective of the
tooling used. This allows a builder to turn off, for example, the specs
without having to chase down which tool generates them, as there could
be many. In contrast, without-xmlto will turn off xmlto, regardless of
which type of documentation it is building. This is useful for a builder
who knows there are issues with the installed version of that tool, for
example.

The one classification that is missing is MANPAGES, as there were never
a way to not build them. If there is a requirement to not build all the
man pages, it can be done. If the issue is simply related to a tool,
then the option for the specific tool should be used.

In libXcomposite, the only available option is without-xmlto to turn off
the generation of man pages from DocBook XML.

Slightly off-topic, this generation step from DocBook XML is really not
worth the pain for such small man pages, considering  all the complexity
to be added in the makefile to stuff generated man pages in the tarball
for platforms who don't have xmnlto. I had to say it :-) 



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] DRI2: Expose API to set drawable swap limit.

2010-10-28 Thread Mario Kleiner

On Oct 28, 2010, at 6:10 PM, Pauli Nieminen wrote:


I think we should have some way for the drivers to back out of this
gracefully or at least cover their tails. E.g., allow the ddx to set
a hard upper limit for the swap_limit, in a new field max_swap_limit.
Your patch could make sure that swap_limit is never set to a value
higher than that. Then the intel and radeon ddx could set
max_swap_limit = 1 unless users somehow (xorg.conf option? dri.conf?)
opt into risky higher max_swap_limits.


True.

I intended DRI2SwapLimit to be called from DDX only. DDX only entry  
wouldn't

need any checks for limit changes.

If we assume that all calls to DRI2SwapLimit are anyway driver  
initiated then

max_swap_limits would only guard driver against it self.

I can add the max_swap_limit if there is real need for it.



Or some part of the implementation (your patch? the ddx itself?)
should output some warning in the x log if a value is selected that
it can't reliably handle, so app developers aren't confused to death
about weird behaviour.



DDX would have to implement the option and warning.



Ok, sounds good. As long as the ddx has control over the settable  
swap_limit, i'm perfectly fine with it.




Good point. I wasn't aware of that. So something like sketched above
should/could be implemented inside the ddx instead of the common
server code. But there, where it can already exchange to the new
front, it should work, right?



yes. It would work.



Good. So that's one way to do it in the ddx.

Thanks,
-mario

___
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: [ANNOUNCE] libXcomposite 0.4.3

2010-10-28 Thread Alan Coopersmith
Gaetan Nadon wrote:
 Slightly off-topic, this generation step from DocBook XML is really not
 worth the pain for such small man pages, considering  all the complexity
 to be added in the makefile to stuff generated man pages in the tarball
 for platforms who don't have xmnlto. I had to say it :-)

Some things we only learn by trying the experiment and seeing what works
or doesn't.   If the cost of xml man pages is too high, then I can live
with permanently converting them for things like this, but when we can
end up sharing the text between specs  man pages, then I'd prefer that,
even at the slight tools cost, vs. having to maintain two copies.

For instance, since the libSM spec has chapters that are basically
man page style synopis/parameter list/description of each function,
those could be put into .xml files that are used to generate man pages
(which libSM currently doesn't have) and included into the generation
of the spec.

-- 
-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: [ANNOUNCE] libXcomposite 0.4.3

2010-10-28 Thread Jeremy Huddleston

On Oct 28, 2010, at 10:23, Gaetan Nadon wrote:

 On Wed, 2010-10-27 at 23:27 -0700, Jeremy Huddleston wrote:
 
 It looks like libXcomposite doesn't have a --disable-docs,
 --disable-specs, nor --disable-docs-devel, but it does have
 --without-fop ... 
 
 I don't see a --without-fop configuration option. It goes from XML to
 man, no html, pdf, ps or txt format.

Sorry... I meant --without-xmlto (not fop)

 The one classification that is missing is MANPAGES, as there were never
 a way to not build them. If there is a requirement to not build all the
 man pages, it can be done. If the issue is simply related to a tool,
 then the option for the specific tool should be used.

The problem is that we have cyclic dependencies between xmlto and the X11 
libraries in MacPorts, so I decided to push all the documentation into a 
variant.  By default, we --disable-{docs,devel-docs,specs} 
--without-{doxygen,xmlto,fop,groff,...} and we only enable them when the user 
requests it.

It sounds like this scheme would result in man pages not being built by 
default, but they still are because it looks like we fallback on using the .man 
generated by the packager's 'make dist'

 In libXcomposite, the only available option is without-xmlto to turn off
 the generation of man pages from DocBook XML.

___
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] DRI2: Add error message when working around driver bug

2010-10-28 Thread Mario Kleiner

On Oct 28, 2010, at 6:02 PM, Jesse Barnes wrote:


On Thu, 28 Oct 2010 18:47:09 +0300
Pauli Nieminen ext-pauli.niemi...@nokia.com wrote:
Most of what you have in (b) is pretty straightfoward; even the  
shared
drawable case shouldn't be too bad, since each X connection could  
have

bits indicating whether the counter has been picked up after a CRTC
move.


One option would be adding crct id parameter to calls.

glXGetMscBaseRateOML would return rate, base msc and pipe id where  
this msc

value is valid. Now all MSC calls would take the returned pipe id as
parameter. If pipe id doesn't match current crtc any more then  
call would

fail.

This would allow complex applications to pass same pipe id to  
different

context.

Negative side is that API would have to be changed to include extra
parameter.


Yeah that would be a good extension though; we may as well expose the
fact that different display pipes exist on the system, and have
corresponding MSCs.  Old applications using SGI_video_sync or existing
OML behavior would work like they do today (with an MSC value that may
jump, which we could fix with the virtualize count), and new ones  
would

be pipe aware.



I also like option b) the most, define new spec and api instead of  
working around the old specs limitations.


Another way of doing it, in the same spirit, would be some generation  
counter. Starts with 1, increments each time that something changes  
in the configuration which could influence the display timing and  
mess with the schedule the app had in mind. If the drawable changes  
crtc's. If the crtc changes its video mode (esp. refresh rate) or  
configuration (mirrored/extended desktop, synchronized to other  
crtc's etc.), dpms change etc.


A get call could return the current count, other calls could return  
the count that was valid at time of their processing. E.g.,  
intel_swap_events could code more info like generation count, crtcid.


Apps could pass in the count to the msc related functions and those  
would fail on mismatch to the current count. One could also have one  
special don't care value (e.g., 0) that says I don't care about an  
isolated glitch, because i'm not prepared to handle this anyway. Just  
do something to make sure i don't hang, e.g., fall through a blocking  
glXWaitMscOml() call or swap the buffers immediately on  
glXSwapBuffersMscOML().


I'm also for exposing rather more than less information, like pipe  
configuration, or the ability for the app to decide what it wants, e.g.,


* If the drawable covers multiple crtc's, or is in mirror display  
mode, should one of them define when to swap and the other should  
show tearing, or should each of them sync its swap separately, which  
looks nice, but can throttle redraw rates or possibly exhaust  
resources if the crtc's run and largely different rates.


Windows has the concept of a primary display which defines the swap  
timing on extended desktops. The non-primary display just shows  
tearing. Mac OS behaves similar, except that you don't have control  
over which is the primary display, and some (sometimes buggy)  
heuristic decides for you and gives you the fun of working around it  
by replugging monitors and other fun things. I like control.


The current intel and radeon ddx in page flipped mode will swap each  
crtc separately. Tear free, but with throttled framerate, as swap  
completion == swap completion of the last involved crtc. This btw. is  
a problem for the returned timestamps and timing if the crtc's run at  
different refresh rates, as the app doesn't know to which crtc the  
swap completion timestamp belongs. And it changes over time. For  
blitted copy-swaps you get tearfree on the assigned crtc for a  
drawable and tearing on the other one.


Another approach would be to define swap times in system (gettimeofday 
() time). Specify a swap deadline tWhen and the system tries to swap  
at the earliest vblank with a time tNow = tWhen. Then one doesn't  
have to care too much about changes in msc rates. The  
NV_present_video http://www.opengl.org/registry/specs/NV/ 
present_video.txt extension does something similar for presentatio  
of video buffers. My own toolkit does this as well and for user code  
it's a natural way to specify presentation times, especially if it  
has to synchronize presentation with other modalities like sound,  
digital i/o, eye tracking etc. My code just uses the  
glXGetSyncValuesOML() call to translate a user-provided system time  
tWhen into a corresponding target_msc for glXSwapBuffersMscOML().


When we're at defining new api (christmas time is coming, i got lots  
of wishes), a new swapbuffers call could also define what to do if a  
presentation deadline can't be met. E.g., instead of a delayed swap  
it could drop the swap and completely skip a bufferswap request to  
get presentation timing back on schedule, so skipped frame errors  
can't accumulate. Something like that could be interesting for 

Re: [ANNOUNCE] libXcomposite 0.4.3

2010-10-28 Thread Gaetan Nadon
On Thu, 2010-10-28 at 11:08 -0700, Jeremy Huddleston wrote:

 It sounds like this scheme would result in man pages not being built
 by default, but they still are because it looks like we fallback on
 using the .man generated by the packager's 'make dist'
 

Yes, the tarball contains the .man files which will be sed into .3
files. The makefile is designed to abort if one tries to generate a
tarball without running xmlto, so as not to distribute a tarball without
the man pages.

One side-effect for developers who work without xmlto is that they
cannot run distcheck on a regular basis as a quality assurance measure
as the makefile is designed to abort to prevent the creation of
man-pageless tarballs.


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 2/2] DRI2: Add error message when working around driver bug

2010-10-28 Thread Alex Deucher
On Thu, Oct 28, 2010 at 2:20 PM, Mario Kleiner
mario.klei...@tuebingen.mpg.de wrote:
 On Oct 28, 2010, at 6:02 PM, Jesse Barnes wrote:

 On Thu, 28 Oct 2010 18:47:09 +0300
 Pauli Nieminen ext-pauli.niemi...@nokia.com wrote:

 Most of what you have in (b) is pretty straightfoward; even the shared
 drawable case shouldn't be too bad, since each X connection could have
 bits indicating whether the counter has been picked up after a CRTC
 move.

 One option would be adding crct id parameter to calls.

 glXGetMscBaseRateOML would return rate, base msc and pipe id where this
 msc
 value is valid. Now all MSC calls would take the returned pipe id as
 parameter. If pipe id doesn't match current crtc any more then call would
 fail.

 This would allow complex applications to pass same pipe id to different
 context.

 Negative side is that API would have to be changed to include extra
 parameter.

 Yeah that would be a good extension though; we may as well expose the
 fact that different display pipes exist on the system, and have
 corresponding MSCs.  Old applications using SGI_video_sync or existing
 OML behavior would work like they do today (with an MSC value that may
 jump, which we could fix with the virtualize count), and new ones would
 be pipe aware.


 I also like option b) the most, define new spec and api instead of working
 around the old specs limitations.

 Another way of doing it, in the same spirit, would be some generation
 counter. Starts with 1, increments each time that something changes in the
 configuration which could influence the display timing and mess with the
 schedule the app had in mind. If the drawable changes crtc's. If the crtc
 changes its video mode (esp. refresh rate) or configuration
 (mirrored/extended desktop, synchronized to other crtc's etc.), dpms change
 etc.

 A get call could return the current count, other calls could return the
 count that was valid at time of their processing. E.g., intel_swap_events
 could code more info like generation count, crtcid.

 Apps could pass in the count to the msc related functions and those would
 fail on mismatch to the current count. One could also have one special
 don't care value (e.g., 0) that says I don't care about an isolated
 glitch, because i'm not prepared to handle this anyway. Just do something to
 make sure i don't hang, e.g., fall through a blocking glXWaitMscOml() call
 or swap the buffers immediately on glXSwapBuffersMscOML().

 I'm also for exposing rather more than less information, like pipe
 configuration, or the ability for the app to decide what it wants, e.g.,

 * If the drawable covers multiple crtc's, or is in mirror display mode,
 should one of them define when to swap and the other should show tearing, or
 should each of them sync its swap separately, which looks nice, but can
 throttle redraw rates or possibly exhaust resources if the crtc's run and
 largely different rates.

 Windows has the concept of a primary display which defines the swap timing
 on extended desktops. The non-primary display just shows tearing. Mac OS
 behaves similar, except that you don't have control over which is the
 primary display, and some (sometimes buggy) heuristic decides for you and
 gives you the fun of working around it by replugging monitors and other fun
 things. I like control.

 The current intel and radeon ddx in page flipped mode will swap each crtc
 separately. Tear free, but with throttled framerate, as swap completion ==
 swap completion of the last involved crtc. This btw. is a problem for the
 returned timestamps and timing if the crtc's run at different refresh rates,
 as the app doesn't know to which crtc the swap completion timestamp belongs.
 And it changes over time. For blitted copy-swaps you get tearfree on the
 assigned crtc for a drawable and tearing on the other one.

 Another approach would be to define swap times in system (gettimeofday()
 time). Specify a swap deadline tWhen and the system tries to swap at the
 earliest vblank with a time tNow = tWhen. Then one doesn't have to care too
 much about changes in msc rates. The NV_present_video
 http://www.opengl.org/registry/specs/NV/present_video.txt extension does
 something similar for presentatio of video buffers. My own toolkit does this
 as well and for user code it's a natural way to specify presentation times,
 especially if it has to synchronize presentation with other modalities like
 sound, digital i/o, eye tracking etc. My code just uses the
 glXGetSyncValuesOML() call to translate a user-provided system time tWhen
 into a corresponding target_msc for glXSwapBuffersMscOML().

 When we're at defining new api (christmas time is coming, i got lots of
 wishes), a new swapbuffers call could also define what to do if a
 presentation deadline can't be met. E.g., instead of a delayed swap it could
 drop the swap and completely skip a bufferswap request to get presentation
 timing back on schedule, so skipped frame errors can't accumulate. Something
 

Tweakability of fop documentation

2010-10-28 Thread Cyril Brulebois
Gaetan Nadon mems...@videotron.ca (11/10/2010):
 I don't mind giving more flexibility, but it will generate a
 defaults war.

Talking about flexibility, I've got two remarks about fop:
 - It uses format autodetection by default, using papersize and
   locales settings. People building packages for distributions may
   like the concept of build reproducibility and may want to build
   stuff independently of the environment. It'd be nice to be able to
   pass --noautosize without having to patch all specs/Makefile.am
   files in Xorg packages.
 - Fop is very chatty, and may clutter the build log with messages
   which aren't going to be read except by a few developers (I'm not
   even sure?). It'd be nice to be able to tell it to be less
   chatty. Since no option seems to exist for that matter, I guess
   it'll still be nice to be able to redirect its std{out,err} to
   /dev/null…

What do you think?

(I've been playing around with libXaw for now, but I guess the same
applies to all Xorg packages with reworked documentation handling.)

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: Tweakability of fop documentation

2010-10-28 Thread Gaetan Nadon
On Thu, 2010-10-28 at 21:55 +0200, Cyril Brulebois wrote:

 Gaetan Nadon mems...@videotron.ca (11/10/2010):
  I don't mind giving more flexibility, but it will generate a
  defaults war.
 
 Talking about flexibility, I've got two remarks about fop:
  - It uses format autodetection by default, using papersize and
locales settings. People building packages for distributions may
like the concept of build reproducibility and may want to build
stuff independently of the environment. It'd be nice to be able to
pass --noautosize without having to patch all specs/Makefile.am
files in Xorg packages.

One solution comes to mind. An Autoconf aware variable, say XMLTO_OPTS

The usage option would look like:

Some influential environment variables:
  CC  C compiler command
  CFLAGS  C compiler flags
  LDFLAGS linker flags, e.g. -Llib dir if you have libraries in a
  nonstandard directory lib dir
  LIBSlibraries to pass to the linker, e.g. -llibrary
  CPPFLAGSC/C++/Objective C preprocessor flags, e.g. -Iinclude 
dir if
  you have headers in a nonstandard directory include dir
  CPP C preprocessor
  PKG_CONFIG  path to pkg-config utility
  XMLTO   Path to xmlto command
  XMLTO_OPTS  Options for xmlto command
  FOP Path to fop command
  [...]

The makefile would be changed to:


XMLTO_FLAGS = -m $(XSL_STYLESHEET) $(XMLTO_OPTS)


The command line invocation would be:

./configure XMLTO_OPTS=--noautosize



  - Fop is very chatty, and may clutter the build log with messages
which aren't going to be read except by a few developers (I'm not
even sure?). It'd be nice to be able to tell it to be less
chatty. Since no option seems to exist for that matter, I guess
it'll still be nice to be able to redirect its std{out,err} to
/dev/null…

A bit more tricky. Using Automake 1.11, you can the silent rules for
free.
All you see is:

   GEN  libXaw.txt

for the text conversion. For the pdf version, you see a bunch of
warnings.
The perfect solutions would be to fix the code so no warning is emitted.
Suppressing the output means the build log will not show errors either.
You can always pass /dev/null 21 in XMLTO_OPTS


 
 What do you think?
 
 (I've been playing around with libXaw for now, but I guess the same
 applies to all Xorg packages with reworked documentation handling.)

Now that the are distributed with the package they document, it make
sense that
it creates new requirements.


 
 Mraw,
 KiBi.


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: [ANNOUNCE] libXcomposite 0.4.3

2010-10-28 Thread Matt Dew
On Thu, Oct 28, 2010 at 11:58 AM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
 Gaetan Nadon wrote:
 Slightly off-topic, this generation step from DocBook XML is really not
 worth the pain for such small man pages, considering  all the complexity
 to be added in the makefile to stuff generated man pages in the tarball
 for platforms who don't have xmnlto. I had to say it :-)

 Some things we only learn by trying the experiment and seeing what works
 or doesn't.   If the cost of xml man pages is too high, then I can live
 with permanently converting them for things like this, but when we can
 end up sharing the text between specs  man pages, then I'd prefer that,
 even at the slight tools cost, vs. having to maintain two copies.

 For instance, since the libSM spec has chapters that are basically
 man page style synopis/parameter list/description of each function,
 those could be put into .xml files that are used to generate man pages
 (which libSM currently doesn't have) and included into the generation
 of the spec.


One glitch in this is that it may be ugly trying to generate man pages
and regular documentation from the same .xml file.
man pages require a 'DOCTYPE man'  vs regular documents which are
either 'DOCTYPE book' or 'DOCTYPE article'.

I haven't played with this much yet so it may not be that difficult.
Just saying...

Matt
___
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


[PULL] misc input fixes

2010-10-28 Thread Peter Hutterer
Keith,

I've updated my pull request with two more patches. Tiago's patch prevents
an infinite loop in device-specific cursor handling. The fix for 29046 fixes
a few issues with some mice that are both keyboards and mice.

Chase' and Paulius' patches remain the same.

Cheers,
  Peter

The following changes since commit 1a0d9324b3d9fd93e685066e0e5cea0611878c0d:

  Revert Set DamageSetReportAfterOp to true for the damage extension (#30260) 
(2010-10-20 16:49:14 -0700)

are available in the git repository at:
  git://people.freedesktop.org/~whot/xserver.git for-keith

Chase Douglas (1):
  test: input - set valuators mask for event to core conversion

Paulius Zaleckas (1):
  KDrive: Fix error handlig in tslib driver

Peter Hutterer (1):
  Xi: reshuffle conditions for labeling a device as IsXExtensionKeyboard 
(#29046)

Tiago Vignatti (1):
  dix: advance parent window pointer when no node is found

 Xi/listdev.c|4 ++--
 dix/window.c|6 +++---
 hw/kdrive/linux/tslib.c |   15 +++
 test/input.c|2 ++
 4 files changed, 18 insertions(+), 9 deletions(-)
___
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] shadow: Optimize shadowUpdatePacked(). (#26973)

2010-10-28 Thread Matt Turner
On Tue, Sep 21, 2010 at 10:29 AM, Matt Turner matts...@gmail.com wrote:
 On Sat, Sep 11, 2010 at 5:55 PM, Matt Turner matts...@gmail.com wrote:
 From: Adam Jackson a...@redhat.com

 Signed-off-by: Matt Turner matts...@gmail.com
 ---
 I was bug triaging and came across 26973 and remembered seeing it on the
 ml at some point recently. Here's a patch, as suggested by ajax [1].

 Corbin: are there any patches from your bug triage branch that need to
 go into the xserver?

 [1] http://lists.freedesktop.org/archives/xorg-devel/2010-March/00.html

  miext/shadow/shpacked.c |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/miext/shadow/shpacked.c b/miext/shadow/shpacked.c
 index 20d2ea1..06606bc 100644
 --- a/miext/shadow/shpacked.c
 +++ b/miext/shadow/shpacked.c
 @@ -102,8 +102,8 @@ shadowUpdatePacked (ScreenPtr           pScreen,
                width -= i;
                scr += i;
  #define PickBit(a,i)   (((a)  (i))  1)
 -               while (i--)
 -                   *win++ = *sha++;
 +               memcpy(win, sha, i * sizeof(FbBits));
 +               sha += i;
            }
            shaLine += shaStride;
            y++;
 --
 1.7.1

 So, do we want this patch?

 It seems like it does deobfuscate the code a bit, and memcpy is going
 to be more efficient than byte-by-byte copies.

 Matt

Can I get some Reviewed-bys or Acked-bys?
___
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] Set DamageSetReportAfterOp to true for the damage extension

2010-10-28 Thread Eric Anholt
From: Kristian Høgsberg k...@bitplanet.net

Change the damage extension reporter to queue up events after we chain
to the wrapped functions.  Damage events are typically sent out after
the rendering happens anyway, since we submit batch buffers from the
flush callback chain and then flush client io buffers.  Compositing
managers relie on this order, and there is no way we could reliably
provide damage events to clients before the rendering happens anyway.

By queueing up the damage events before the rendering happens, there's
a risk that the client io buffer may overflow and send the damage
events to the client before the driver has even seen the rendering
request.  Reporting damage events after the rendering fixes this
corner case and better corresponds with how we expect this to work.

Signed-off-by: Kristian Høgsberg k...@bitplanet.net
Reviewed-by: Keith Packard kei...@keithp.com
(cherry picked from commit 8d7b7a0d71e0b89321b3341b781bc8845386def6)
[anholt: re-applied to revert the revert, now that the cause of the
revert is fixed]
---
 damageext/damageext.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/damageext/damageext.c b/damageext/damageext.c
index 4aa0ff3..754383d 100644
--- a/damageext/damageext.c
+++ b/damageext/damageext.c
@@ -217,6 +217,7 @@ ProcDamageCreate (ClientPtr client)
 if (!AddResource (stuff-damage, DamageExtType, (pointer) pDamageExt))
return BadAlloc;
 
+DamageSetReportAfterOp (pDamageExt-pDamage, TRUE);
 DamageRegister (pDamageExt-pDrawable, pDamageExt-pDamage);
 
 if (pDrawable-type == DRAWABLE_WINDOW)
-- 
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] Replace usage of DamageRegionAppend with DamageDamageRegion to fix reportAfter.

2010-10-28 Thread Eric Anholt
In all these cases, any rendering implied by this damage has already
occurred, and we want to get the damage out to the client.  Some of
the DamageRegionAppend calls were explicitly telling damage to flush
the reportAfter damage out, but not all.

Bug #30260. Fixes the compiz wallpaper plugin with client damage
changed to reportAfter.

Signed-off-by: Eric Anholt e...@anholt.net
---
 composite/compalloc.c |2 +-
 composite/compwindow.c|4 ++--
 damageext/damageext.c |4 ++--
 exa/exa.c |3 +--
 glx/glxdri.c  |4 +---
 hw/xfree86/modes/xf86Rotate.c |2 +-
 6 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/composite/compalloc.c b/composite/compalloc.c
index 47d5c0a..c86eb9b 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -238,7 +238,7 @@ compFreeClientWindow (WindowPtr pWin, XID id)
DamageRegister (pWin-drawable, cw-damage);
cw-damageRegistered = TRUE;
pWin-redirectDraw = RedirectDrawAutomatic;
-   DamageRegionAppend(pWin-drawable, pWin-borderSize);
+   DamageDamageRegion(pWin-drawable, pWin-borderSize);
 }
 if (wasMapped  !pWin-mapped)
 {
diff --git a/composite/compwindow.c b/composite/compwindow.c
index 8849dc3..d17ff77 100644
--- a/composite/compwindow.c
+++ b/composite/compwindow.c
@@ -519,7 +519,7 @@ compCopyWindow (WindowPtr pWin, DDXPointRec ptOldOrg, 
RegionPtr prgnSrc)
RegionTranslate(prgnSrc,
  pWin-drawable.x - ptOldOrg.x,
  pWin-drawable.y - ptOldOrg.y);
-   DamageRegionAppend(pWin-drawable, prgnSrc);
+   DamageDamageRegion(pWin-drawable, prgnSrc);
 }
 cs-CopyWindow = pScreen-CopyWindow;
 pScreen-CopyWindow = compCopyWindow;
@@ -598,7 +598,7 @@ compSetRedirectBorderClip (WindowPtr pWin, RegionPtr 
pRegion)
 /*
  * Report that as damaged so it will be redrawn
  */
-DamageRegionAppend(pWin-drawable, damage);
+DamageDamageRegion(pWin-drawable, damage);
 RegionUninit(damage);
 /*
  * Save the new border clip region
diff --git a/damageext/damageext.c b/damageext/damageext.c
index f5265dd..4aa0ff3 100644
--- a/damageext/damageext.c
+++ b/damageext/damageext.c
@@ -222,7 +222,7 @@ ProcDamageCreate (ClientPtr client)
 if (pDrawable-type == DRAWABLE_WINDOW)
 {
pRegion = ((WindowPtr) pDrawable)-borderClip;
-   DamageRegionAppend(pDrawable, pRegion);
+   DamageDamageRegion(pDrawable, pRegion);
 }
 
 return Success;
@@ -292,7 +292,7 @@ ProcDamageAdd (ClientPtr client)
  * screen coordinates like damage expects.
  */
 RegionTranslate(pRegion, pDrawable-x, pDrawable-y);
-DamageRegionAppend(pDrawable, pRegion);
+DamageDamageRegion(pDrawable, pRegion);
 RegionTranslate(pRegion, -pDrawable-x, -pDrawable-y);
 
 return Success;
diff --git a/exa/exa.c b/exa/exa.c
index fc15c24..8adf847 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -159,8 +159,7 @@ exaPixmapDirty (PixmapPtr pPix, int x1, int y1, int x2, int 
y2)
return;
 
 RegionInit(region, box, 1);
-DamageRegionAppend(pPix-drawable, region);
-DamageRegionProcessPending(pPix-drawable);
+DamageDamageRegion(pPix-drawable, region);
 RegionUninit(region);
 }
 
diff --git a/glx/glxdri.c b/glx/glxdri.c
index 41482c9..6458ef9 100644
--- a/glx/glxdri.c
+++ b/glx/glxdri.c
@@ -834,9 +834,7 @@ static void __glXReportDamage(__DRIdrawable *driDraw,
 
 RegionInit(region, (BoxPtr) rects, num_rects);
 RegionTranslate(region, pDraw-x, pDraw-y);
-DamageRegionAppend(pDraw, region);
-/* This is wrong, this needs a seperate function. */
-DamageRegionProcessPending(pDraw);
+DamageDamageRegion(pDraw, region);
 RegionUninit(region);
 
 __glXleaveServer(GL_FALSE);
diff --git a/hw/xfree86/modes/xf86Rotate.c b/hw/xfree86/modes/xf86Rotate.c
index fdc38c5..57c3499 100644
--- a/hw/xfree86/modes/xf86Rotate.c
+++ b/hw/xfree86/modes/xf86Rotate.c
@@ -168,7 +168,7 @@ xf86CrtcDamageShadow (xf86CrtcPtr crtc)
 if (damage_box.x2  pScreen-width) damage_box.x2 = pScreen-width;
 if (damage_box.y2  pScreen-height) damage_box.y2 = pScreen-height;
 RegionInit(damage_region, damage_box, 1);
-DamageRegionAppend ((*pScreen-GetScreenPixmap)(pScreen)-drawable,
+DamageDamageRegion ((*pScreen-GetScreenPixmap)(pScreen)-drawable,
damage_region);
 RegionUninit(damage_region);
 crtc-shadowClear = TRUE;
-- 
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 1/2] Replace usage of DamageRegionAppend with DamageDamageRegion to fix reportAfter.

2010-10-28 Thread Keith Packard
On Thu, 28 Oct 2010 20:46:22 -0700, Eric Anholt e...@anholt.net wrote:
 In all these cases, any rendering implied by this damage has already
 occurred, and we want to get the damage out to the client.  Some of
 the DamageRegionAppend calls were explicitly telling damage to flush
 the reportAfter damage out, but not all.
 
 Bug #30260. Fixes the compiz wallpaper plugin with client damage
 changed to reportAfter.
 
 Signed-off-by: Eric Anholt e...@anholt.net

Reviewed-by: Keith Packard kei...@keithp.com

(testers on other graphics chips are encouraged to give this a try so we
don't have to revert the revert of the revert)

-- 
keith.pack...@intel.com


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

Re: [PATCH 2/2] Set DamageSetReportAfterOp to true for the damage extension

2010-10-28 Thread Keith Packard
On Thu, 28 Oct 2010 20:46:23 -0700, Eric Anholt e...@anholt.net wrote:

 Signed-off-by: Kristian Høgsberg k...@bitplanet.net
 Reviewed-by: Keith Packard kei...@keithp.com

Do I need to re-review this patch?

Reviewed-by: Keith Packard kei...@keithp.com

(I still think the way post-op damage is reported could be made cleaner,
but meh).

-- 
keith.pack...@intel.com


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

Re: [PATCH evdev] evdev: added property Evdev Axes Rotation. #27688

2010-10-28 Thread Peter Hutterer
On Sun, Oct 24, 2010 at 01:45:03PM +0200, Paolo D'Apice wrote:
 The evdev driver does not allow to set a custom axes rotation
 as the mousedrv driver does with the option AngleOffset.
 This option is necessary for some trackballs, for example the
 Logitech Cordless Optical TrackMan which has the optical
 sensor off-axes (in MS Windows, the Logitech proprietary driver
 adjusts the offset).
 
 X.Org Bug 27688 http://bugs.freedesktop.org/show_bug.cgi?id=27688
 
 Signed-off-by: Paolo D'Apice dapices...@gmail.com

this patch seems simple enough that we could add it to the server as a
standard property for pointer devices, isn't it?  I'd much prefer that so we
don't have to re-implement it for the various drivers.

 ---
  include/evdev-properties.h |4 
  man/evdev.man  |   12 
  src/evdev.c|   25 +
  src/evdev.h|1 +
  4 files changed, 42 insertions(+), 0 deletions(-)
 
 diff --git a/include/evdev-properties.h b/include/evdev-properties.h
 index 7df2876..a658e2b 100644
 --- a/include/evdev-properties.h
 +++ b/include/evdev-properties.h
 @@ -66,4 +66,8 @@
  /* BOOL */
  #define EVDEV_PROP_SWAP_AXES Evdev Axes Swap
  
 +/* Axes Rotation */
 +/* CARD16 */
 +#define EVDEV_PROP_AXES_ROTATION Evdev Axes Rotation
 +

note that CARD16 is unsigned, this should probably read INT16?

  #endif
 diff --git a/man/evdev.man b/man/evdev.man
 index adb3f8d..f7c5e9f 100644
 --- a/man/evdev.man
 +++ b/man/evdev.man
 @@ -177,6 +177,15 @@ This option has no effect on devices without absolute 
 axes.
  .BI Option \*qSwapAxes\*q \*q Bool \*q
  Swap x/y axes. Default: off. Property: Evdev Axes Swap.
  .TP 7
 +.BI Option \*qAxesRotation\*q \*q integer \*q
 +Clockwise axes rotation (in degrees) to apply to the pointer motion. 
 +This transformation is applied before the 
 +.BR SwapAxes , 
 +.BR InvertX 
 +and
 +.B InvertY 
 +transformations. Default: 0. Property: Evdev Axes Rotation.
 +.TP 7
  .BI Option \*qXAxisMapping\*q \*q N1 N2 \*q
  Specifies which buttons are mapped to motion in the X direction in wheel
  emulation mode.  Button number
 @@ -210,6 +219,9 @@ in-driver axis calibration.
  .BI Evdev Axes Swap
  1 boolean value (8 bit, 0 or 1). 1 swaps x/y axes.
  .TP 7
 +.BI Evdev Axes Rotation
 +1 16-bit positive and negative value. 0 disable rotation.

How about 1 16-bit signed value. hard to have a non-zero positive _and_
negative value anyway :)

 +.TP 7
  .BI Evdev Drag Lock Buttons
  8-bit. Either 1 value or pairs of values. Value range 0-32, 0 disables a
  value.
 diff --git a/src/evdev.c b/src/evdev.c
 index 9e1fb10..fc8918e 100644
 --- a/src/evdev.c
 +++ b/src/evdev.c
 @@ -47,6 +47,7 @@
  #include exevents.h
  #include xorgVersion.h
  #include xkbsrv.h
 +#include math.h
  
  #ifdef HAVE_PROPERTIES
  #include X11/Xatom.h
 @@ -114,6 +115,7 @@ static Atom prop_calibration = 0;
  static Atom prop_swap = 0;
  static Atom prop_axis_label = 0;
  static Atom prop_btn_label = 0;
 +static Atom prop_axes_rotation = 0;
  #endif
  
  /* All devices the evdev driver has allocated and knows about.
 @@ -383,6 +385,15 @@ EvdevProcessValuators(InputInfoPtr pInfo, int 
 v[MAX_VALUATORS], int *num_v,
  int first = REL_CNT, last = 0;
  int i;
  
 +if (pEvdev-axes_rotation) {
 +float rotation = (pEvdev-axes_rotation % 360) * M_PI / 180.0; 
 // degrees to radians 

see comment below about storing the radians.

 +float rot_cos = cos(rotation), rot_sin = sin(rotation);

please split this line up, I read over it the first time and then got
confused.

 +   
 +tmp = pEvdev-delta[REL_X];
 +pEvdev-delta[REL_X] = (int)(pEvdev-delta[REL_X] * rot_cos - 
 pEvdev-delta[REL_Y] * rot_sin);
 +pEvdev-delta[REL_Y] = (int)(pEvdev-delta[REL_Y] * rot_cos + 
 tmp * rot_sin);
 +}
 +
  if (pEvdev-swap_axes) {
  tmp = pEvdev-delta[REL_X];
  pEvdev-delta[REL_X] = pEvdev-delta[REL_Y];
 @@ -2516,6 +2527,13 @@ EvdevInitProperty(DeviceIntPtr dev)
  
  XISetDevicePropertyDeletable(dev, prop_swap, FALSE);
  
 +prop_axes_rotation = MakeAtom(EVDEV_PROP_AXES_ROTATION,
 +strlen(EVDEV_PROP_AXES_ROTATION), TRUE);
 +rc = XIChangeDeviceProperty(dev, prop_axes_rotation, XA_INTEGER, 16,
 +PropModeReplace, 1, pEvdev-axes_rotation, FALSE);
 +if (rc != Success) 
 +return;
 +
  #ifdef HAVE_LABELS
  /* Axis labelling */
  if ((pEvdev-num_vals  0)  (prop_axis_label = 
 XIGetKnownProperty(AXIS_LABEL_PROP)))
 @@ -2575,6 +2593,13 @@ EvdevSetProperty(DeviceIntPtr dev, Atom atom, 
 XIPropertyValuePtr val,
  
  if (!checkonly)
  pEvdev-swap_axes = *((BOOL*)val-data);
 +} else if (atom == prop_axes_rotation)
 +{
 +if (val-format != 16 || val-type != XA_INTEGER || val-size != 1)
 +return BadMatch;
 +
 +   if (!checkonly)
 +