Re: Patch to fix wireless keyboard/mouse detection in libXi (xinput1)
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
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?
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.
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.
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.
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.
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
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.
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
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?
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
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.
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
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
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
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
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
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
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.
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
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.
+/** + * 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
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
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
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
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
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.
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
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)
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
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
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
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)
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
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.
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
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
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
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.
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
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
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
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
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
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
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
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
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
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)
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
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.
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.
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
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
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) +