Re: [PATCH] Fix XNextRequest() after direct usage of XCB
Uli Schlachter wrote:
> > unsigned long XNextRequest(Display *dpy)
> > {
> > +unsigned long next_request;
> > +LockDisplay(dpy);
> > +next_request = _XNextRequest(dpy);
> > +UnlockDisplay(dpy);
> > +
> > return (NextRequest(dpy));
>
> Unused variable "next_request". Did you really mean to write the function
> like this instead of also changing the return statement?
Oops - it does actually work, because the _XNextRequest() updates
display->request
as a side effect, so I wasn't dreaming that my testing worked, but still
embarrassing ;-) Sent a newversion.
- Owen
___
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] Fix XNextRequest() after direct usage of XCB
From: "Owen W. Taylor"
When XCB owns the X socket, dpy->request is not updated, so
NextRequest() and XNextRequest() return the wrong value. There's
nothing we can do to fix NextRequest() while retaining ABI compat,
but change XNextRequest() to grab the socket back from XCB,
updating dpy->request.
Signed-off-by: Owen W. Taylor
---
src/Macros.c | 14 +-
src/Xxcbint.h | 2 ++
src/xcb_io.c | 11 +++
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/src/Macros.c b/src/Macros.c
index cfc083a..394a764 100644
--- a/src/Macros.c
+++ b/src/Macros.c
@@ -30,6 +30,7 @@ in this Software without prior written authorization from The
Open Group.
#include "Xlibint.h"
#define XUTIL_DEFINE_FUNCTIONS
#include "Xutil.h"
+#include "Xxcbint.h"
/*
* This file makes full definitions of routines for each macro.
@@ -135,9 +136,20 @@ int XBitmapPad(Display *dpy) { return (BitmapPad(dpy)); }
int XImageByteOrder(Display *dpy) { return (ImageByteOrder(dpy)); }
+/* XNextRequest() differs from the rest of the functions here because it is
+ * no longer a macro wrapper - when libX11 is being used mixed together
+ * with direct use of xcb, the next request field of the Display structure will
+ * not be updated. We can't fix the NextRequest() macro in any easy way,
+ * but we can at least make XNextRequest() do the right thing.
+ */
unsigned long XNextRequest(Display *dpy)
{
-return (NextRequest(dpy));
+unsigned long next_request;
+LockDisplay(dpy);
+next_request = _XNextRequest(dpy);
+UnlockDisplay(dpy);
+
+return next_request;
}
unsigned long XLastKnownRequestProcessed(Display *dpy)
diff --git a/src/Xxcbint.h b/src/Xxcbint.h
index a8c9a67..bf41c23 100644
--- a/src/Xxcbint.h
+++ b/src/Xxcbint.h
@@ -46,4 +46,6 @@ typedef struct _X11XCBPrivate {
int _XConnectXCB(Display *dpy, _Xconst char *display, int *screenp);
void _XFreeX11XCBStructure(Display *dpy);
+unsigned long _XNextRequest(Display *dpy);
+
#endif /* XXCBINT_H */
diff --git a/src/xcb_io.c b/src/xcb_io.c
index 727c6c7..5987329 100644
--- a/src/xcb_io.c
+++ b/src/xcb_io.c
@@ -774,3 +774,14 @@ void _XEatDataWords(Display *dpy, unsigned long n)
dpy->xcb->reply_consumed = dpy->xcb->reply_length;
_XFreeReplyData(dpy, False);
}
+
+unsigned long
+_XNextRequest(Display *dpy)
+{
+/* This will update dpy->request. The assumption is that the next thing
+ * that the application will do is make a request so there's little
+ * overhead.
+ */
+require_socket(dpy);
+return NextRequest(dpy);
+}
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Fix XNextRequest() after direct usage of XCB
On 09.05.2014 22:33, otay...@redhat.com wrote:
> From: "Owen W. Taylor"
>
> When XCB owns the X socket, dpy->request is not updated, so
> NextRequest() and XNextRequest() return the wrong value. There's
> nothing we can do to fix NextRequest() while retaining ABI compat,
> but change XNextRequest() to grab the socket back from XCB,
> updating dpy->request.
Nice idea! We already had/have a problem due to this in cairo. However, one
comment below.
> ---
> src/Macros.c | 12
> src/Xxcbint.h | 2 ++
> src/xcb_io.c | 11 +++
> 3 files changed, 25 insertions(+)
>
> diff --git a/src/Macros.c b/src/Macros.c
> index cfc083a..b57f577 100644
> --- a/src/Macros.c
> +++ b/src/Macros.c
> @@ -30,6 +30,7 @@ in this Software without prior written authorization from
> The Open Group.
> #include "Xlibint.h"
> #define XUTIL_DEFINE_FUNCTIONS
> #include "Xutil.h"
> +#include "Xxcbint.h"
>
> /*
> * This file makes full definitions of routines for each macro.
> @@ -135,8 +136,19 @@ int XBitmapPad(Display *dpy) { return (BitmapPad(dpy)); }
>
> int XImageByteOrder(Display *dpy) { return (ImageByteOrder(dpy)); }
>
> +/* XNextRequest() differs from the rest of the functions here because it is
> + * no longer a Macro wrapper - when libX11 is being used mixed together
> + * with direct use of xcb, the next request field of the Display structure
> will
> + * not be updated; we can't fix the NextRequest() macro in any easy way,
> + * but we can at least make XNextRequest() do the right thing.
> + */
> unsigned long XNextRequest(Display *dpy)
> {
> +unsigned long next_request;
> +LockDisplay(dpy);
> +next_request = _XNextRequest(dpy);
> +UnlockDisplay(dpy);
> +
> return (NextRequest(dpy));
Unused variable "next_request". Did you really mean to write the function like
this instead of also changing the return statement?
> }
>
> diff --git a/src/Xxcbint.h b/src/Xxcbint.h
> index a8c9a67..bf41c23 100644
> --- a/src/Xxcbint.h
> +++ b/src/Xxcbint.h
> @@ -46,4 +46,6 @@ typedef struct _X11XCBPrivate {
> int _XConnectXCB(Display *dpy, _Xconst char *display, int *screenp);
> void _XFreeX11XCBStructure(Display *dpy);
>
> +unsigned long _XNextRequest(Display *dpy);
> +
> #endif /* XXCBINT_H */
> diff --git a/src/xcb_io.c b/src/xcb_io.c
> index 727c6c7..5987329 100644
> --- a/src/xcb_io.c
> +++ b/src/xcb_io.c
> @@ -774,3 +774,14 @@ void _XEatDataWords(Display *dpy, unsigned long n)
> dpy->xcb->reply_consumed = dpy->xcb->reply_length;
> _XFreeReplyData(dpy, False);
> }
> +
> +unsigned long
> +_XNextRequest(Display *dpy)
> +{
> +/* This will update dpy->request. The assumption is that the next thing
> + * that the application will do is make a request so there's little
> + * overhead.
> + */
> +require_socket(dpy);
> +return NextRequest(dpy);
> +}
>
--
"Are you preparing for another war, Plutarch?" I ask.
"Oh, not now. Now we're in that sweet period where everyone agrees that our
recent horrors should never be repeated," he says. "But collective thinking is
usually short-lived. We're fickle, stupid beings with poor memories and a great
gift for self-destruction.
___
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] Fix XNextRequest() after direct usage of XCB
From: "Owen W. Taylor"
When XCB owns the X socket, dpy->request is not updated, so
NextRequest() and XNextRequest() return the wrong value. There's
nothing we can do to fix NextRequest() while retaining ABI compat,
but change XNextRequest() to grab the socket back from XCB,
updating dpy->request.
Signed-off-by: Owen W. Taylor
---
src/Macros.c | 12
src/Xxcbint.h | 2 ++
src/xcb_io.c | 11 +++
3 files changed, 25 insertions(+)
diff --git a/src/Macros.c b/src/Macros.c
index cfc083a..b57f577 100644
--- a/src/Macros.c
+++ b/src/Macros.c
@@ -30,6 +30,7 @@ in this Software without prior written authorization from The
Open Group.
#include "Xlibint.h"
#define XUTIL_DEFINE_FUNCTIONS
#include "Xutil.h"
+#include "Xxcbint.h"
/*
* This file makes full definitions of routines for each macro.
@@ -135,8 +136,19 @@ int XBitmapPad(Display *dpy) { return (BitmapPad(dpy)); }
int XImageByteOrder(Display *dpy) { return (ImageByteOrder(dpy)); }
+/* XNextRequest() differs from the rest of the functions here because it is
+ * no longer a Macro wrapper - when libX11 is being used mixed together
+ * with direct use of xcb, the next request field of the Display structure will
+ * not be updated; we can't fix the NextRequest() macro in any easy way,
+ * but we can at least make XNextRequest() do the right thing.
+ */
unsigned long XNextRequest(Display *dpy)
{
+unsigned long next_request;
+LockDisplay(dpy);
+next_request = _XNextRequest(dpy);
+UnlockDisplay(dpy);
+
return (NextRequest(dpy));
}
diff --git a/src/Xxcbint.h b/src/Xxcbint.h
index a8c9a67..bf41c23 100644
--- a/src/Xxcbint.h
+++ b/src/Xxcbint.h
@@ -46,4 +46,6 @@ typedef struct _X11XCBPrivate {
int _XConnectXCB(Display *dpy, _Xconst char *display, int *screenp);
void _XFreeX11XCBStructure(Display *dpy);
+unsigned long _XNextRequest(Display *dpy);
+
#endif /* XXCBINT_H */
diff --git a/src/xcb_io.c b/src/xcb_io.c
index 727c6c7..5987329 100644
--- a/src/xcb_io.c
+++ b/src/xcb_io.c
@@ -774,3 +774,14 @@ void _XEatDataWords(Display *dpy, unsigned long n)
dpy->xcb->reply_consumed = dpy->xcb->reply_length;
_XFreeReplyData(dpy, False);
}
+
+unsigned long
+_XNextRequest(Display *dpy)
+{
+/* This will update dpy->request. The assumption is that the next thing
+ * that the application will do is make a request so there's little
+ * overhead.
+ */
+require_socket(dpy);
+return NextRequest(dpy);
+}
--
1.9.0
___
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 xf86-video-nouveau v2] Fix building on older servers without xf86platformBus.h
Le 09/05/2014 15:02, Hans de Goede a écrit : Hi, On 05/09/2014 02:46 PM, Martin Peres wrote: Le 11/04/2014 16:57, Hans de Goede a écrit : Signed-off-by: Hans de Goede Hi Hans, I never received this patch although I was the main recipient :s That concerns me greatly because it means I have no email address immune to dropping emails... Yes that is a problem, I specifically send it to you with the hope it would get picked up quickly. I'm very sorry about this... Never hesitate to ping me on IRC (mupuf). I try to do good but my memory often fails (when the emails do work). It should get better after my PhD ;) Anyway, I heard about it yesterday from a user and had to google the patch's name to find out it was posted on xorg-devel (which I very rarely read). If you have any patches for nouveau, please send them to the nouveau ML. I've no other patches pending. Good :) I hope my slow response didn't feel like I was ignoring you! Again, never hesitate to ping me. Pending patches are the worst! Martin ___ 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 xf86-video-nouveau v2] Fix building on older servers without xf86platformBus.h
Hi, On 05/09/2014 02:46 PM, Martin Peres wrote: > Le 11/04/2014 16:57, Hans de Goede a écrit : >> Signed-off-by: Hans de Goede > > Hi Hans, > > I never received this patch although I was the main recipient :s That > concerns me greatly because it means I have no email address immune to > dropping emails... Yes that is a problem, I specifically send it to you with the hope it would get picked up quickly. > Anyway, I heard about it yesterday from a user and had to google the patch's > name to find out it was posted on xorg-devel (which I very rarely read). If > you have any patches for nouveau, please send them to the nouveau ML. I've no other patches pending. Regards, Hans ___ 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 xf86-video-nouveau v2] Fix building on older servers without xf86platformBus.h
Le 09/05/2014 14:46, Martin Peres a écrit : Le 11/04/2014 16:57, Hans de Goede a écrit : Signed-off-by: Hans de Goede Hi Hans, I never received this patch although I was the main recipient :s That concerns me greatly because it means I have no email address immune to dropping emails... Anyway, I heard about it yesterday from a user and had to google the patch's name to find out it was posted on xorg-devel (which I very rarely read). If you have any patches for nouveau, please send them to the nouveau ML. I'm very sorry for the very large delay and will push the patch ASAP. If you have other patches pending for Nouveau, feel free to resend them as I am not aware about any of them. I'll deal with them this week end! Cheers, Martin I tested and pushed this patch. ___ 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 xf86-video-nouveau v2] Fix building on older servers without xf86platformBus.h
Le 11/04/2014 16:57, Hans de Goede a écrit : Signed-off-by: Hans de Goede Hi Hans, I never received this patch although I was the main recipient :s That concerns me greatly because it means I have no email address immune to dropping emails... Anyway, I heard about it yesterday from a user and had to google the patch's name to find out it was posted on xorg-devel (which I very rarely read). If you have any patches for nouveau, please send them to the nouveau ML. I'm very sorry for the very large delay and will push the patch ASAP. If you have other patches pending for Nouveau, feel free to resend them as I am not aware about any of them. I'll deal with them this week end! Cheers, Martin ___ 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 09/10] dri3: Add dri3 extension framework
On Thu, Oct 31, 2013 at 03:43:41PM -0700, Keith Packard wrote:
> +static void
> +miSyncShmFenceSetTriggered(SyncFence * pFence)
> +{
> +SyncShmFencePrivatePtr pPriv = SYNC_FENCE_PRIV(pFence);
> +
> +if (pPriv->fence)
> +xshmfence_trigger(pPriv->fence);
> +miSyncFenceSetTriggered(pFence);
This is racy as the clients are woken up before the server has had a
chance to do the required work.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
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] MatchSeat, logind patch, two invalid memory access
Patch sent: http://lists.x.org/archives/xorg-devel/2014-May/042386.html CANTATE DOMINO CANTICUM NOVUM QUIA MIRABILIA FECIT Laércio 2014-05-09 0:31 GMT-03:00 Keith Packard : > Laércio de Sousa writes: > > > These warnings are all related to a malformed FIND_SUITABLE macro > > expansion. I can fix it tomorrow. > > Thanks. > > -- > keith.pack...@intel.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
[PATCH v2] xfree86: fix warnings after MatchSeat patch
This patch fixes some compile warnings that arise after
commit 7070ebeebaca1b51f8a2801989120784a1c374ae
(xfree86: add new key MatchSeat to xorg.conf sections "Device", "Screen", and
"ServerLayout")
available at git repository
git://people.freedesktop.org/~whot/xserver for-keith
---
hw/xfree86/common/xf86Config.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 5d17567..2adef44 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -232,16 +232,17 @@ xf86ValidateFontPath(char *path)
return tmp_path;
}
-#define FIND_SUITABLE(pointertype, listhead, ptr)
\
-{
\
-pointertype l, p;
\
-
\
-for (l = listhead, p = NULL; !p && l; l = (pointertype) l->list.next)
{ \
-if (! l->match_seat || SeatId && xf86nameCompare(l->match_seat,
SeatId) == 0) \
-p = l;
\
-}
\
-ptr = p;
\
-}
+#define FIND_SUITABLE(pointertype, listhead, ptr)
\
+do {
\
+pointertype _l, _p;
\
+
\
+for (_l = (listhead), _p = NULL; !_p && _l; _l =
(pointertype)_l->list.next) { \
+if (!_l->match_seat || (SeatId && xf86nameCompare(_l->match_seat,
SeatId) == 0)) \
+_p = _l;
\
+}
\
+
\
+(ptr) = _p;
\
+} while(0)
/*
* use the datastructure that the parser provides and pick out the parts
@@ -2368,6 +2369,7 @@ xf86HandleConfigFile(Bool autoconfig)
const char *scanptr;
Bool singlecard = 0;
Bool implicit_layout = FALSE;
+XF86ConfLayoutPtr layout;
if (!autoconfig) {
char *filename, *dirname, *sysdirname;
@@ -2443,8 +2445,6 @@ xf86HandleConfigFile(Bool autoconfig)
*/
/* First check if a layout section is present, and if it is valid. */
-XF86ConfLayoutPtr layout;
-
FIND_SUITABLE(XF86ConfLayoutPtr, xf86configptr->conf_layout_lst, layout);
if (layout == NULL || xf86ScreenName != NULL) {
XF86ConfScreenPtr screen;
--
1.8.4.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
Re: [PATCH v2] ARC: Add support for ARC architecture
On Thu, 2014-05-01 at 15:39 +0300, Alexey Brodkin wrote: > Xorg server could be built for and run on Synopsys DesignWare ARC cores. > These changes are required for successful building and execution of the > server. > > Both little-endian and big-endian flavors of ARC cores are supported. > > Signed-off-by: Alexey Brodkin > > Cc: Vineet Gupta > Cc: Andreas Schwab > Cc: Mark Kettenis > Cc: Adam Jackson > Cc: Egbert Eich > Cc: Aaron Watry > Cc: Keith Packard > --- > Compared to v1 only fixed pre-processor string (added "&") to fix compilation. > Thanks for Aaron Watry. > > This v2 was tested with actual building and execution on a target. > > hw/xfree86/common/compiler.h| 4 ++-- > hw/xfree86/os-support/linux/lnx_video.c | 3 ++- > include/servermd.h | 13 + > 3 files changed, 17 insertions(+), 3 deletions(-) > > diff --git a/hw/xfree86/common/compiler.h b/hw/xfree86/common/compiler.h > index fb95f58..0319de0 100644 > --- a/hw/xfree86/common/compiler.h > +++ b/hw/xfree86/common/compiler.h > @@ -1352,7 +1352,7 @@ stl_u(unsigned long val, unsigned int *p) > #else /* ix86 */ > > #if !defined(__SUNPRO_C) > -#if !defined(FAKEIT) && !defined(__mc68000__) && !defined(__arm__) && > !defined(__sh__) && !defined(__hppa__) && !defined(__s390__) && > !defined(__m32r__) && !defined(__aarch64__) > +#if !defined(FAKEIT) && !defined(__mc68000__) && !defined(__arm__) && > !defined(__sh__) && !defined(__hppa__) && !defined(__s390__) && > !defined(__m32r__) && !defined(__aarch64__) && !defined(__arc__) > #ifdef GCCUSESGAS > > /* > @@ -1454,7 +1454,7 @@ inl(unsigned short port) > > #endif /* GCCUSESGAS */ > > -#else /* !defined(FAKEIT) && !defined(__mc68000__) > && !defined(__arm__) && !defined(__sh__) && !defined(__hppa__) && > !defined(__m32r__) */ > +#else /* !defined(FAKEIT) && !defined(__mc68000__) > && !defined(__arm__) && !defined(__sh__) && !defined(__hppa__) && > !defined(__m32r__) && !defined(__arc__) */ > > static __inline__ void > outb(unsigned short port, unsigned char val) > diff --git a/hw/xfree86/os-support/linux/lnx_video.c > b/hw/xfree86/os-support/linux/lnx_video.c > index 47f5abc..40765fc 100644 > --- a/hw/xfree86/os-support/linux/lnx_video.c > +++ b/hw/xfree86/os-support/linux/lnx_video.c > @@ -59,7 +59,8 @@ static Bool ExtendedEnabled = FALSE; >!defined(__mips__) && \ >!defined(__nds32__) && \ >!defined(__arm__) && \ > - !defined(__aarch64__) > + !defined(__aarch64__) && \ > + !defined(__arc__) > > /* > * Due to conflicts with "compiler.h", don't rely on to declare > diff --git a/include/servermd.h b/include/servermd.h > index 11f6c10..2d1ccb1 100644 > --- a/include/servermd.h > +++ b/include/servermd.h > @@ -300,6 +300,19 @@ SOFTWARE. > > #endif /* __aarch64__ */ > > +#if defined(__arc__) > + > +#if defined(__BIG_ENDIAN__) > +#define IMAGE_BYTE_ORDER MSBFirst > +#define BITMAP_BIT_ORDER MSBFirst > +#else > +#define IMAGE_BYTE_ORDER LSBFirst > +#define BITMAP_BIT_ORDER LSBFirst > +#endif > +#define GLYPHPADBYTES4 > + > +#endif /* ARC */ > + > /* size of buffer to use with GetImage, measured in bytes. There's obviously > * a trade-off between the amount of heap used and the number of times the > * ddx routine has to be called. Any chance to get this one reviewed/applied? Regards, Alexey ___ 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
