Re: Spinning in _XReply
On 02/22/2011 11:26 PM, xm...@karlt.net wrote: Although wrong, our code has been working well enough for us to get useful information. If someone is able to point out a reason why this now works less successfully than previously, then that would bump up the priority at our end. By superficially looking at the Xlib code, the behavior in older Xlib version (1.3.3) is different depending on whether Xlib is configured --with-xcb or --without-xcb. When Xcb is disabled, error handler is called with display unlocked and _XReply seems to be prepared to handle requests from error handler. With Xcb, which is the default now with Xlib 1.4, the display remains locked during error handling and nested requests aren't allowed. Even the older _XReply contains a comment indicating that doing requests from an error handler wasn't considered good behavior even though it happened to work previously: /* Pull out the serial number now, so that (currently illegal) requests * generated by an error handler don't confuse us. */ The information we want is already on display-ext_procs-codes but This structure is private to the library. I'm not aware of a public API to get this information from Xlib. I guess we could use a separate connection to query the extension codes. Is it reasonable to assume that all connections to the same display would use the same codes? X server seems to preserve the extension codes until the server is regenerated and therefore all connections should use the same codes. -- 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: Current tinderbox regression (xserver, randr)
Hi, I think Keith was waiting for someone to review this patch... http://lists.x.org/archives/xorg-devel/2011-February/019390.html and RandR 1.4 fixes... http://lists.x.org/archives/xorg-devel/2011-February/019389.html The patch makes the code compile for me (MinGW for Windows)..but I haven't got suitable tests to say Rand 1.4 is OK. Thanks, Colin Harrison ___ 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] Unbreak the .m.c rule
Great! Now I can build xts on newer distros =) Tested-by: Paulo Zanoni pzan...@mandriva.com 2011/2/23 Peter Hutterer peter.hutte...@who-t.net: On Tue, Feb 22, 2011 at 05:57:26PM -0500, Adam Jackson wrote: Some builds of gnu make apparently know how to go straight from .m to .o. That's great if your .m file is Objective C source, but for us, it's not. Signed-off-by: Adam Jackson a...@redhat.com --- xts5/common.mk | 4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/xts5/common.mk b/xts5/common.mk index 52d0fd6..d36c25e 100644 --- a/xts5/common.mk +++ b/xts5/common.mk @@ -10,6 +10,10 @@ MC = $(top_builddir)/xts5/src/bin/mc/mc AM_V_MC = $(am__v_MC_$(V)) am__v_MC_ = $(am__v_MC_$(AM_DEFAULT_VERBOSITY)) am__v_MC_0 = @echo MC $@; + +# empty rules to turn off objc magic. grr. +%.o : %.m + .m.c: $(AM_V_MC)TET_ROOT='$(abs_top_srcdir)' $(MC) -o $@ $ .m_m.c: -- 1.7.4.1 Acked-by: Peter Hutterer peter.hutte...@who-t.net Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel -- Paulo Zanoni ___ 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] Unbreak the .m.c rule
On Tue, Feb 22, 2011 at 9:04 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Tue, Feb 22, 2011 at 05:57:26PM -0500, Adam Jackson wrote: Some builds of gnu make apparently know how to go straight from .m to .o. That's great if your .m file is Objective C source, but for us, it's not. Signed-off-by: Adam Jackson a...@redhat.com --- xts5/common.mk | 4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/xts5/common.mk b/xts5/common.mk index 52d0fd6..d36c25e 100644 --- a/xts5/common.mk +++ b/xts5/common.mk @@ -10,6 +10,10 @@ MC = $(top_builddir)/xts5/src/bin/mc/mc AM_V_MC = $(am__v_MC_$(V)) am__v_MC_ = $(am__v_MC_$(AM_DEFAULT_VERBOSITY)) am__v_MC_0 = @echo MC $@; + +# empty rules to turn off objc magic. grr. +%.o : %.m + .m.c: $(AM_V_MC)TET_ROOT='$(abs_top_srcdir)' $(MC) -o $@ $ .m_m.c: -- 1.7.4.1 Acked-by: Peter Hutterer peter.hutte...@who-t.net Peter, did we discuss some other way to fix this? Either way, this looks like the right thing to do. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Spinning in _XReply
On 23 February 2011 11:15, Rami Ylimäki rami.ylim...@vincit.fi wrote: On 02/22/2011 11:26 PM, xm...@karlt.net wrote: Although wrong, our code has been working well enough for us to get useful information. If someone is able to point out a reason why this now works less successfully than previously, then that would bump up the priority at our end. By superficially looking at the Xlib code, the behavior in older Xlib version (1.3.3) is different depending on whether Xlib is configured --with-xcb or --without-xcb. When Xcb is disabled, error handler is called with display unlocked and _XReply seems to be prepared to handle requests from error handler. With Xcb, which is the default now with Xlib 1.4, the display remains locked during error handling and nested requests aren't allowed. Even the older _XReply contains a comment indicating that doing requests from an error handler wasn't considered good behavior even though it happened to work previously: /* Pull out the serial number now, so that (currently illegal) requests * generated by an error handler don't confuse us. */ The information we want is already on display-ext_procs-codes but This structure is private to the library. I'm not aware of a public API to get this information from Xlib. I guess we could use a separate connection to query the extension codes. Is it reasonable to assume that all connections to the same display would use the same codes? X server seems to preserve the extension codes until the server is regenerated and therefore all connections should use the same codes. Is that guaranteed by some protocol or does it just happen to work as the requests in error handler did? Thanks Michal ___ 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] libXfixes v5: Pointer barriers
Signed-off-by: Adam Jackson a...@redhat.com
---
configure.ac|2 +-
include/X11/extensions/Xfixes.h | 15 ++
src/Cursor.c| 58 +++
3 files changed, 74 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index cf9a8d4..fc8c1e1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -32,7 +32,7 @@ AC_PREREQ([2.60])
# that 'revision' number appears in Xfixes.h and has to be manually
# synchronized.
#
-AC_INIT(libXfixes, [4.0.5],
+AC_INIT(libXfixes, [5.0],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [libXfixes])
AC_CONFIG_SRCDIR([Makefile.am])
AC_CONFIG_HEADERS([config.h])
diff --git a/include/X11/extensions/Xfixes.h b/include/X11/extensions/Xfixes.h
index 0c00310..481531c 100644
--- a/include/X11/extensions/Xfixes.h
+++ b/include/X11/extensions/Xfixes.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2006, Oracle and/or its affiliates. All rights reserved.
+ * Copyright 2010 Red Hat, Inc.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the Software),
@@ -249,6 +250,20 @@ XFixesShowCursor (Display *dpy, Window win);
#endif /* XFIXES_MAJOR = 4 */
+#if XFIXES_MAJOR = 5
+
+typedef XID PointerBarrier;
+
+PointerBarrier
+XFixesCreatePointerBarrier(Display *dpy, Window w, int x1, int y1,
+ int x2, int y2, int directions,
+ int num_devices, short *devices);
+
+void
+XFixesDestroyPointerBarrier(Display *dpy, PointerBarrier b);
+
+#endif /* XFIXES_MAJOR = 5 */
+
_XFUNCPROTOEND
#endif /* _XFIXES_H_ */
diff --git a/src/Cursor.c b/src/Cursor.c
index edd179d..e9e6aa0 100644
--- a/src/Cursor.c
+++ b/src/Cursor.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2006, Oracle and/or its affiliates. All rights reserved.
+ * Copyright 2010 Red Hat, Inc.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the Software),
@@ -274,3 +275,60 @@ XFixesShowCursor (Display *dpy, Window win)
UnlockDisplay (dpy);
SyncHandle ();
}
+
+PointerBarrier
+XFixesCreatePointerBarrier(Display *dpy, Window w, int x1, int y1,
+ int x2, int y2, int directions,
+ int num_devices, short *devices)
+{
+XFixesExtDisplayInfo *info = XFixesFindDisplay (dpy);
+xXFixesCreatePointerBarrierReq *req;
+PointerBarrier barrier;
+int extra = 0;
+
+XFixesCheckExtension (dpy, info, 0);
+if (info-major_version 5)
+ return 0;
+
+if (num_devices)
+ extra = (((2 * num_devices) + 3) / 4) * 4;
+
+LockDisplay (dpy);
+GetReqExtra (XFixesCreatePointerBarrier, extra, req);
+req-reqType = info-codes-major_opcode;
+req-xfixesReqType = X_XFixesCreatePointerBarrier;
+barrier = req-barrier = XAllocID (dpy);
+req-window = w;
+req-x1 = x1;
+req-y1 = y1;
+req-x2 = x2;
+req-y2 = y2;
+req-directions = directions;
+if ((req-num_devices = num_devices)) {
+ CARD16 *devs = (CARD16 *)(req + 1);
+ memcpy(devs, devices, num_devices * sizeof(CARD16));
+}
+
+UnlockDisplay (dpy);
+SyncHandle();
+return barrier;
+}
+
+void
+XFixesDestroyPointerBarrier(Display *dpy, PointerBarrier b)
+{
+XFixesExtDisplayInfo *info = XFixesFindDisplay (dpy);
+xXFixesDestroyPointerBarrierReq *req;
+
+XFixesSimpleCheckExtension (dpy, info);
+if (info-major_version 5)
+ return;
+
+LockDisplay (dpy);
+GetReq (XFixesDestroyPointerBarrier, req);
+req-reqType = info-codes-major_opcode;
+req-xfixesReqType = X_XFixesDestroyPointerBarrier;
+req-barrier = b;
+UnlockDisplay (dpy);
+SyncHandle();
+}
--
1.7.3.5
___
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] dri2: Initialize padding in DRI2GetBuffers reply
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
This fixes following valgrind reported error about padding being uninitialised.
==== Syscall param writev(vector[...]) points to uninitialised byte(s)
====at 0x4AB7054: writev (writev.c:51)
====by 0x5E237: _XSERVTransWritev (Xtrans.c:912)
====by 0x6154B: FlushClient (io.c:937)
====by 0x61CDF: WriteToClient (io.c:859)
====by 0x4938B: WriteEventsToClient (events.c:5702)
====by 0x4BF43: TryClientEvents (events.c:1953)
====by 0x4F983: DeliverGrabbedEvent (events.c:3857)
====by 0xEA527: ProcessOtherEvent (exevents.c:1102)
====by 0x115313: ProcessPointerEvent (xkbAccessX.c:729)
====by 0xB16BF: mieqProcessDeviceEvent (mieq.c:423)
====by 0xB174B: mieqProcessInputEvents (mieq.c:481)
====by 0x653B3: ProcessInputEvents (xf86Events.c:165)
==== Uninitialised value was created by a stack allocation
====at 0x503FAA0: send_buffers_reply (dri2ext.c:210)
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/dri2/dri2ext.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
index 4e48e65..725823e 100644
--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -227,11 +227,15 @@ send_buffers_reply(ClientPtr client, DrawablePtr
pDrawable,
}
rep.type = X_Reply;
+rep.pad1 = 0;
rep.length = (count - skip) * sizeof(xDRI2Buffer) / 4;
rep.sequenceNumber = client-sequence;
rep.width = width;
rep.height = height;
rep.count = count - skip;
+rep.pad2 = 0;
+rep.pad3 = 0;
+rep.pad4 = 0;
WriteToClient(client, sizeof(xDRI2GetBuffersReply), rep);
for (i = 0; i count; 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: [PATCH] Unbreak the .m.c rule
On 2/23/11 8:53 AM, Dan Nicholson wrote: Peter, did we discuss some other way to fix this? Either way, this looks like the right thing to do. Reviewed-by: Dan Nicholsondbn.li...@gmail.com Pushed, thanks all. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Patch 0/8] Pointer barriers
On 2/21/11 10:51 PM, Peter Hutterer wrote: Notes on the PB support in general: - having a pointer barrier specify which direction it doesn't work is very confusing. Both from the client-side and whithin the server it was counter-intuitive. I'd prefer an interface like this barrier = XFixesCreatePointerBarrier(dpy, DefaultRootWindow(dpy), 100, 0, 100, 200, PointerBarrierPositiveX); to block movement from left to right. The above call would currently block all directions but let left-to-right movement through. I don't have any objection to this, I'll need to edit the fixesproto docs before releasing 5.0 but that's trivial. - The barrier itself is an elevated barrier, i.e. you cannot get onto the pixel the barrier represents (from the blocking directions). This is necessary to avoid trapped cursors when the barrier blocks both directions. This needs to be either added to the protocol or I need to spend the time to implement the exact protocol spec (top/left edge of the pixel). The latter would result in x = barrier or x = barrier + 1, depending on where you're coming from. The barrier is intended to be on the edges between the pixels. I'll try to hammer this bit out. For the series through #6, where applicable: Reviewed-by: Adam Jackson a...@redhat.com The RANDR CRTC confine bit is very much worth landing on its own even if barriers miss 1.10.0. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] [xserver] record: avoid crash when calling RecordFlushReplyBuffer recursively
On Mon, 14 Feb 2011 19:59:13 +0200, Oliver McFadden oliver.mcfad...@nokia.com wrote: I don't think this has been merged into master yet (and we should apply it to the 1.9.xxx branches too), so I've added my Reviewed-by below. Good catch! I'll merge this to master for 1.10. -- keith.pack...@intel.com pgpxExnIoEOPg.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] randr: Add 'set' fields to SetCrtcConfigs request
On Wed, Feb 16, 2011 at 10:59:22PM -0800, Keith Packard wrote:
This permits clients to perform incremental configuration changes
instead of requiring a complete new configuration to be written.
Signed-off-by: Keith Packard kei...@keithp.com
---
randr/rrcrtc.c | 332
++--
1 files changed, 202 insertions(+), 130 deletions(-)
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index 5fe6900..07e9019 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -1483,63 +1483,82 @@ RRConvertCrtcConfig(ClientPtr client, ScreenPtr
screen,
PixmapPtr pixmap;
intrc, i, j;
Rotation rotation;
+intnumOutputs;
VERIFY_RR_CRTC(x-crtc, crtc, DixSetAttrAccess);
-if (x-mode == None)
-{
- mode = NULL;
- if (x-nOutput 0)
- return BadMatch;
+mode = crtc-mode;
+numOutputs = crtc-numOutputs;
+
+if (x-set RR_SetCrtcOutputs)
+ numOutputs = x-nOutput;
+
+if (x-set RR_SetCrtcMode) {
+ if (x-mode == None)
+ mode = NULL;
+ else
+ {
+ VERIFY_RR_MODE(x-mode, mode, DixSetAttrAccess);
+ if (x-nOutput == 0)
+ return BadMatch;
+ }
randrproto.txt says nothing about SetCrtcMode.
}
-else
+
+if (numOutputs)
{
- VERIFY_RR_MODE(x-mode, mode, DixSetAttrAccess);
- if (x-nOutput == 0)
+ if (mode == NULL)
return BadMatch;
-}
-if (x-nOutput)
-{
- outputs = malloc(x-nOutput * sizeof (RROutputPtr));
+ outputs = malloc(numOutputs * sizeof (RROutputPtr));
if (!outputs)
return BadAlloc;
}
-else
+else {
+ if (mode != NULL)
+ return BadMatch;
randrproto.txt says nothing about SetCrtcOutputs. The interplay encoded
here probably ought to be described in the protocol doc.
outputs = NULL;
-
-if (x-pixmap == None)
- pixmap = NULL;
-else if (x-pixmap == RR_CurrentScanoutPixmap)
- pixmap = crtc-scanoutPixmap;
-else
-{
- rc = dixLookupResourceByType((pointer *) pixmap, x-pixmap,
-RT_PIXMAP, client, DixWriteAccess);
- if (rc != Success) {
- free(outputs);
- return rc;
- }
- /* XXX check to make sure this is a scanout pixmap */
}
-for (i = 0; i x-nOutput; i++)
-{
- rc = dixLookupResourceByType((pointer *)(outputs + i), outputIds[i],
-RROutputType, client, DixSetAttrAccess);
- if (rc != Success)
+if (x-set RR_SetCrtcPixmap) {
+ if (x-pixmap == None)
+ pixmap = NULL;
+ else
{
- free(outputs);
- return rc;
+ rc = dixLookupResourceByType((pointer *) pixmap, x-pixmap,
+RT_PIXMAP, client, DixWriteAccess);
+ if (rc != Success) {
+ free(outputs);
+ return rc;
+ }
+ /* XXX check to make sure this is a scanout pixmap */
}
- /* validate crtc for this output */
- for (j = 0; j outputs[i]-numCrtcs; j++)
- if (outputs[i]-crtcs[j] == crtc)
- break;
- if (j == outputs[i]-numCrtcs)
+} else
+ pixmap = crtc-scanoutPixmap;
+
+if (x-set RR_SetCrtcOutputs) {
+ for (i = 0; i numOutputs; i++)
{
- free(outputs);
- return BadMatch;
+ rc = dixLookupResourceByType((pointer *)(outputs + i),
outputIds[i],
+RROutputType, client,
DixSetAttrAccess);
+ if (rc != Success)
+ {
+ free(outputs);
+ return rc;
+ }
+ /* validate crtc for this output */
+ for (j = 0; j outputs[i]-numCrtcs; j++)
+ if (outputs[i]-crtcs[j] == crtc)
+ break;
+ if (j == outputs[i]-numCrtcs)
+ {
+ free(outputs);
+ return BadMatch;
+ }
}
+} else
+ memcpy(outputs, crtc-outputs, numOutputs * sizeof (RROutputPtr));
+
+for (i = 0; i numOutputs; i++)
+{
/* validate mode for this output */
for (j = 0; j outputs[i]-numModes + outputs[i]-numUserModes; j++)
{
@@ -1555,10 +1574,11 @@ RRConvertCrtcConfig(ClientPtr client, ScreenPtr
screen,
return BadMatch;
}
}
+
/* validate clones */
-for (i = 0; i x-nOutput; i++)
+for (i = 0; i numOutputs; i++)
{
- for (j = 0; j x-nOutput; j++)
+ for (j = 0; j numOutputs; j++)
{
int k;
if (i == j)
@@ -1579,46 +1599,68 @@ RRConvertCrtcConfig(ClientPtr client, ScreenPtr
screen,
if
[PULL] 1.10: warning fixes, ABI fix, and minor Fedora merge
The following changes since commit 93a73993708b1345c86ec3ec06b02ed236595673: test: write some event → XI1 conversion tests. (2011-02-22 08:08:55 +1000) are available in the git repository at: ssh://people.freedesktop.org/~ajax/xserver ..BRANCH.NOT.VERIFIED.. Adam Jackson (13): glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix xfree86: If the driver found modes on an output, don't add more xfree86: Fix the sdk headers to be multilib-safe Peter Hutterer (1): Add mode field to ConstrainCursorHarder hw/dmx/glxProxy/glxcmds.c | 80 +--- hw/dmx/glxProxy/glxsingle.c |7 ++-- hw/dmx/glxProxy/glxvendor.c |6 ++-- hw/dmx/glxProxy/render2swap.c | 54 --- hw/xfree86/modes/xf86Crtc.c | 10 +- include/colormapst.h |4 +- include/scrnintstr.h |2 +- include/xorg-server.h.in |7 ++-- 8 files changed, 57 insertions(+), 113 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
[PULL] 1.10: warning fixes, ABI fix, and minor Fedora merge
The following changes since commit 93a73993708b1345c86ec3ec06b02ed236595673: test: write some event → XI1 conversion tests. (2011-02-22 08:08:55 +1000) are available in the git repository at: ssh://people.freedesktop.org/~ajax/xserver for-keithp Adam Jackson (13): glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix xfree86: If the driver found modes on an output, don't add more xfree86: Fix the sdk headers to be multilib-safe Peter Hutterer (1): Add mode field to ConstrainCursorHarder hw/dmx/glxProxy/glxcmds.c | 80 +--- hw/dmx/glxProxy/glxsingle.c |7 ++-- hw/dmx/glxProxy/glxvendor.c |6 ++-- hw/dmx/glxProxy/render2swap.c | 54 --- hw/xfree86/modes/xf86Crtc.c | 10 +- include/colormapst.h |4 +- include/scrnintstr.h |2 +- include/xorg-server.h.in |7 ++-- 8 files changed, 57 insertions(+), 113 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] Unbreak the .m.c rule
On Wed, Feb 23, 2011 at 05:53:57AM -0800, Dan Nicholson wrote: On Tue, Feb 22, 2011 at 9:04 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Tue, Feb 22, 2011 at 05:57:26PM -0500, Adam Jackson wrote: Some builds of gnu make apparently know how to go straight from .m to .o. That's great if your .m file is Objective C source, but for us, it's not. Signed-off-by: Adam Jackson a...@redhat.com --- xts5/common.mk | 4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/xts5/common.mk b/xts5/common.mk index 52d0fd6..d36c25e 100644 --- a/xts5/common.mk +++ b/xts5/common.mk @@ -10,6 +10,10 @@ MC = $(top_builddir)/xts5/src/bin/mc/mc AM_V_MC = $(am__v_MC_$(V)) am__v_MC_ = $(am__v_MC_$(AM_DEFAULT_VERBOSITY)) am__v_MC_0 = @echo MC $@; + +# empty rules to turn off objc magic. grr. +%.o : %.m + .m.c: $(AM_V_MC)TET_ROOT='$(abs_top_srcdir)' $(MC) -o $@ $ .m_m.c: -- 1.7.4.1 Acked-by: Peter Hutterer peter.hutte...@who-t.net Peter, did we discuss some other way to fix this? Either way, this looks like the right thing to do. yeah, we did. I just renamed all of them to .mc :) patch has been sitting in my tree for ages, together with about 20 other onces. Need to dig them up again but at least for the renaming one, there's no reason now. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] randr: Add 'set' fields to SetCrtcConfigs request
On Wed, Feb 23, 2011 at 10:16:46AM -0800, Aaron Plattner wrote: On Wed, Feb 16, 2011 at 10:59:22PM -0800, Keith Packard wrote: Other than the protocol doc comments and the existing bug noted above, Reviewed-by: Aaron Plattner aplatt...@nvidia.com However, I do need to object strongly to such a major protocol change being made after RC2 of a release cycle. We're supposed to be making only critical bug fixes at this point! Planning fail. -- Aaron I believe this all got commited a while ago. There was even a day or so when the proto and xserver were out of sync, and there was a tinderbox complaint and at least one bug. Only a single SOB was present. Luc Verhaegen. ___ 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] libXfixes v5: Pointer barriers
On Wed, Feb 23, 2011 at 11:52:02 -0500, Adam Jackson wrote: diff --git a/include/X11/extensions/Xfixes.h b/include/X11/extensions/Xfixes.h index 0c00310..481531c 100644 --- a/include/X11/extensions/Xfixes.h +++ b/include/X11/extensions/Xfixes.h @@ -1,5 +1,6 @@ /* * Copyright (c) 2006, Oracle and/or its affiliates. All rights reserved. + * Copyright 2010 Red Hat, Inc. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the Software), @@ -249,6 +250,20 @@ XFixesShowCursor (Display *dpy, Window win); #endif /* XFIXES_MAJOR = 4 */ +#if XFIXES_MAJOR = 5 + +typedef XID PointerBarrier; + +PointerBarrier +XFixesCreatePointerBarrier(Display *dpy, Window w, int x1, int y1, +int x2, int y2, int directions, +int num_devices, short *devices); + the libXi API uses int for deviceid, so short here looks a bit inconsistent (I know it's CARD16 on the wire so this doesn't really matter). +void +XFixesDestroyPointerBarrier(Display *dpy, PointerBarrier b); + +#endif /* XFIXES_MAJOR = 5 */ + _XFUNCPROTOEND #endif /* _XFIXES_H_ */ Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Spinning in _XReply
Rami Ylimäki writes: On 02/22/2011 11:26 PM, xm...@karlt.net wrote: Although wrong, our code has been working well enough for us to get useful information. If someone is able to point out a reason why this now works less successfully than previously, then that would bump up the priority at our end. By superficially looking at the Xlib code, the behavior in older Xlib version (1.3.3) is different depending on whether Xlib is configured --with-xcb or --without-xcb. When Xcb is disabled, error handler is called with display unlocked and _XReply seems to be prepared to handle requests from error handler. With Xcb, which is the default now with Xlib 1.4, the display remains locked during error handling and nested requests aren't allowed. Thanks for looking into that. It looks like the display locks are no-ops unless XInitThreads is called or when built with --enable-checked-locks. http://lists.x.org/archives/xorg-devel/2011-February/019533.html does seem to indicate another potential issue (breaking from the loop only when req == current). I guess that hasn't bitten us because we don't return to the first _XReply. ___ 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] randr: Add 'set' fields to SetCrtcConfigs request
On Wed, 23 Feb 2011 10:16:46 -0800, Aaron Plattner aplatt...@nvidia.com wrote:
randrproto.txt says nothing about SetCrtcMode.
...
randrproto.txt says nothing about SetCrtcOutputs. The interplay encoded
here probably ought to be described in the protocol doc.
Yeah, randrproto.txt is missing some text there...
-screen_config.screen_pixmap_width = stuff-screenPixmapWidth;
-screen_config.screen_pixmap_height = stuff-screenPixmapHeight;
-screen_config.screen_width = stuff-screenWidth;
-screen_config.screen_height = stuff-screenHeight;
-screen_config.mm_width = stuff-widthInMillimeters;
-screen_config.mm_height = stuff-heightInMillimeters;
+if (num_configs 0) {
Existing bug, but it's not clear from randrproto.txt that RRSetCrtcConfigs
doesn't do anything if 'set' doesn't contain SetScreenCrtcs. From the
wording of the protocol doc, I would expect set = RR_SetScreenPixmapSize |
RR_SetScreenSizeInMillimeters | RR_SetScreenSize to change those three
things.
Agreed, this is a bug.
Other than the protocol doc comments and the existing bug noted above,
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
However, I do need to object strongly to such a major protocol change being
made after RC2 of a release cycle. We're supposed to be making only
critical bug fixes at this point! Planning fail.
So, I think I can resolve these issues, and I thank you for your
review. I clearly need to be more careful about getting protocol changes
and client API reviews made before committing code into the X server.
As an alternative plan, I've got a server branch with all of RandR 1.4
removed so that we can properly review the protocol, client library
interfaces and driver interfaces.
git://people.freedesktop.org/~keithp/xserver.git backout-randr
I'd love to hear opinions on which option people would be happiest with.
--
keith.pack...@intel.com
pgpgGjf0kVsV4.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] randr: Add 'set' fields to SetCrtcConfigs request
On Wed, 23 Feb 2011 23:12:15 +0100, Luc Verhaegen l...@skynet.be wrote: I believe this all got commited a while ago. There was even a day or so when the proto and xserver were out of sync, and there was a tinderbox complaint and at least one bug. Only a single SOB was present. I just uncovered this application interface bug a bit over a week ago, and made the RandR protocol changes so that I could get the server code ready for 1.10. Very sub-optimal from a process perspective, but I'm not willing to ship the RandR 1.4 bits as they were when merged -- the application interface needs to change. -- keith.pack...@intel.com pgp27nMPA1nUi.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] randr: Add 'set' fields to SetCrtcConfigs request
On Wed, Feb 23, 2011 at 03:49:58PM -0800, Keith Packard wrote: On Wed, 23 Feb 2011 23:12:15 +0100, Luc Verhaegen l...@skynet.be wrote: I believe this all got commited a while ago. There was even a day or so when the proto and xserver were out of sync, and there was a tinderbox complaint and at least one bug. Only a single SOB was present. I just uncovered this application interface bug a bit over a week ago, and made the RandR protocol changes so that I could get the server code ready for 1.10. Very sub-optimal from a process perspective, but I'm not willing to ship the RandR 1.4 bits as they were when merged -- the application interface needs to change. Ah, ok, at no point this was clear, or i missed it. Luc Verhaegen. ___ 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: [PULL] 1.10: warning fixes, ABI fix, and minor Fedora merge
On Wed, Feb 23, 2011 at 01:48:23PM -0500, a...@redhat.com wrote: The following changes since commit 93a73993708b1345c86ec3ec06b02ed236595673: test: write some event → XI1 conversion tests. (2011-02-22 08:08:55 +1000) are available in the git repository at: ssh://people.freedesktop.org/~ajax/xserver for-keithp Adam Jackson (13): glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix glxproxy: warning fix xfree86: If the driver found modes on an output, don't add more xfree86: Fix the sdk headers to be multilib-safe Peter Hutterer (1): Add mode field to ConstrainCursorHarder just in case that wasn't clear to all, this breaks the ABI. But we don't have any users for it yet anyway, so... 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: [PULL] 1.10: warning fixes, ABI fix, and minor Fedora merge
On 2/23/11 6:57 PM, Peter Hutterer wrote: On Wed, Feb 23, 2011 at 01:48:23PM -0500, a...@redhat.com wrote: Peter Hutterer (1): Add mode field to ConstrainCursorHarder just in case that wasn't clear to all, this breaks the ABI. But we don't have any users for it yet anyway, so... Or callers, for that matter. Technically ABI break, yes, but. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] 1.10: warning fixes, ABI fix, and minor Fedora merge
On Wed, 23 Feb 2011 13:43:54 -0500, a...@redhat.com wrote: are available in the git repository at: ssh://people.freedesktop.org/~ajax/xserver ..BRANCH.NOT.VERIFIED.. BRANCH.NOT.VERIFIED? -- keith.pack...@intel.com pgpE1vzCzY7zp.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] include: document list interface.
On Tue, Feb 22, 2011 at 12:56:41PM -0800, Alan Coopersmith wrote:
+ * Looping through the list requires a 'struct foo' as iterator and the
+ * name of the field the subnodes use.
Looks like this should this say:
a 'struct foo' as iterator, the head of the list, and the
name of the field the subnodes use.
to parallel the three arguments shown:
technically yes, but that's not always the case. AFAICT think this loop
works on any node, though in this example the list head is used.
+ * struct foo *iterator;
+ * list_for_each_entry(iterator, bar.foos, entry) {
+ * if (iterator-something == ...)
+ * ...
+ * }
+ *
+ * Note: You must not call list_del() on the iterator if you continue the
+ * loop. You need to run the safe for-each loop instead:
+ *
+ * struct foo *iterator, *next;
+ * list_for_each_entry(iterator, next, bar.foos, entry) {
+ * if (...)
+ * list_del(iterator-entry);
+ * }
Shouldn't that be list_for_each_entry_safe ?
oops
@@ -61,6 +166,20 @@ __list_del(struct list *prev, struct list *next)
prev-next = next;
}
+/**
+ * Remove the element from the list it is in. Using this function will
reset
+ * the pointers to-fro this element so it is removed from the list. It does
fro - from ?
a, you're destroying my efforts in being all class :)
http://dictionary.reference.com/browse/fro
patch coming in a tick
Cheers,
Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH v2] include: document list interface.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Changes since v1:
typos pointed out by Alan
- initilise - initialize
- Seems like the word in should be deleted from that sentence.
successfully found the sentence to deleted the work in from and executed
said task. it shall not be missed.
- to-fro → to/from
- list_for_each_entry_safe example fixed to actually use
list_for_each_entry_safe
- throught he - through the
include/list.h | 182 +++-
1 files changed, 180 insertions(+), 2 deletions(-)
diff --git a/include/list.h b/include/list.h
index 4ce20a8..5933b97 100644
--- a/include/list.h
+++ b/include/list.h
@@ -26,11 +26,102 @@
#ifndef _LIST_H_
#define _LIST_H_
-/* classic doubly-link circular list */
+/**
+ * @file Classic doubly-link circular list implementation.
+ *
+ * Example:
+ * We need to keep a list of struct foo in the parent struct bar, i.e. what
+ * we want is something like this.
+ *
+ * struct bar {
+ * ...
+ * struct foo *foos; - struct foo {}, struct foo {}, struct foo{}
+ * ...
+ * }
+ *
+ * We need one list head in bar and a list element in all foos (both are of
+ * data type 'struct list').
+ *
+ * struct bar {
+ * ...
+ * struct list foos;
+ * ...
+ * }
+ *
+ * struct foo {
+ * ...
+ * struct list entry;
+ * ...
+ * }
+ *
+ * Now we initialize the list head:
+ *
+ * struct bar bar;
+ * ...
+ * list_init(bar.foos);
+ *
+ * Then we create the first element and add it to this list:
+ *
+ * struct foo *foo = malloc(...);
+ *
+ * list_add(foo-entry, bar.foos);
+ *
+ * Repeat the above for each element you want to add to the list. Deleting
+ * works with the element itself.
+ * list_del(foo-entry);
+ * free(foo);
+ *
+ * Note: calling list_del(bar.foos) will set bar.foos to an empty
+ * list again.
+ *
+ * Looping through the list requires a 'struct foo' as iterator and the
+ * name of the field the subnodes use.
+ *
+ * struct foo *iterator;
+ * list_for_each_entry(iterator, bar.foos, entry) {
+ * if (iterator-something == ...)
+ * ...
+ * }
+ *
+ * Note: You must not call list_del() on the iterator if you continue the
+ * loop. You need to run the safe for-each loop instead:
+ *
+ * struct foo *iterator, *next;
+ * list_for_each_entry_safe(iterator, next, bar.foos, entry) {
+ * if (...)
+ * list_del(iterator-entry);
+ * }
+ *
+ */
+
+/**
+ * The linkage struct for list nodes. This struct must be part of your
+ * to-be-linked struct.
+ *
+ * Example:
+ * struct foo {
+ * int a;
+ * void *b;
+ * struct list *mylist;
+ * }
+ *
+ * Position and name of the struct list field is irrelevant.
+ * There are no requirements that elements of a list are of the same type.
+ * There are no requirements for a list head, any struct list can be a list
+ * head.
+ */
struct list {
struct list *next, *prev;
};
+/**
+ * Initialize the list as an empty list.
+ *
+ * Example:
+ * list_init(foo-mylist);
+ *
+ * @param The list to initialized.
+ */
static void
list_init(struct list *list)
{
@@ -48,6 +139,20 @@ __list_add(struct list *entry,
prev-next = entry;
}
+/**
+ * Insert a new element after the given list head.
+ * The list changes from:
+ * head → some element → ...
+ * to
+ * head → new element → older element → ...
+ *
+ * Example:
+ * struct foo *newfoo = malloc(...);
+ * list_add(newfoo-mylist, foo-mylist);
+ *
+ * @param entry The new element to prepend to the list.
+ * @param head The existing list.
+ */
static inline void
list_add(struct list *entry, struct list *head)
{
@@ -61,6 +166,20 @@ __list_del(struct list *prev, struct list *next)
prev-next = next;
}
+/**
+ * Remove the element from the list it is in. Using this function will reset
+ * the pointers to/from this element so it is removed from the list. It does
+ * NOT free the element itself or manipulate it otherwise.
+ *
+ * Using list_del on a pure list head (like in the example at the top of
+ * this file) will NOT remove the first element from
+ * the list but rather reset the list as empty list.
+ *
+ * Example:
+ * list_del(newfoo-mylist);
+ *
+ * @param entry The element to remove.
+ */
static inline void
list_del(struct list *entry)
{
@@ -68,32 +187,91 @@ list_del(struct list *entry)
list_init(entry);
}
+/**
+ * Check if the list is empty.
+ *
+ * Example:
+ * list_is_empty(foo-mylist);
+ *
+ * @return True if the list contains one or more elements or False otherwise.
+ */
static inline Bool
list_is_empty(struct list *head)
{
return head-next == head;
}
+/**
+ * Returns a pointer to the container of this list element.
+ *
+ * Example:
+ * struct foo* f;
+ * f = container_of(foo-mylist, struct foo, mylist);
+ * assert(f == foo);
+ *
+ * @param ptr Pointer to the struct list.
+ * @param type Data type of
