Porting NX: 64bit problems

[Ulrich Sibiller]

Hello,

I am currently trying to port the (old) code of NoMachine NX to
modular X. The code as released by NoMachine and maintained t the x2go
project [1]  is mostly based on the Xorg 6.9 tree. My first goal is to
port that code to Xorg 7.0 as 6.9 and 7.0 share the same code (after
that updating step by step to the current Xorg is planned).

While I have succeeded in doing this for a 32bit environment I am
struggling on the 64bit version.

The problem is that the xserver (nxagent) has a different size than
libX11 for some data types. This can been seen especially in the xkb
area. The code calls libX11's XKBGetKeyboard() [2] to receive an
XkbDescPtr. XkbDescRec points to an XkbNamesRec, structure which
consists of several Atoms and Atom is 64bit in libX11 but 32bit in
nxagent. Accessing that data leads to wrong values at best and crashes
at worse. The reason for this is the _XSERVER64 define which is set
within the xserver but not within libX11.

I can work around this to some degree by undefining _XSERVER64 in the
server code (but I see crashes when freeing stuff later in the xkb
parts of the server because there the datatype size also differs from
the one in libX11).

The 6.9 based NX code solves this by always compiling _everything_
including libX11 with _XSERVER64 defined. I do not want to do this
because I want to keep as close as possible to the upstream Xorg code
which defines _XSERVER64 only for the server code.

So I am looking for some advice how to solve this in a clean fashion.
Is there a document describing how to cleanly use libX11 calls from a
server? Is there some kind of best practice? Code examples? Does
anybody have some
glue code that takes care of datatype conversion for that purpose?

Thank you,

Uli



[1] http://code.x2go.org/gitweb?p=nx-libs.git;a=summary
[2] 
http://code.x2go.org/gitweb?p=nx-libs.git;a=blob;f=nx-X11/programs/Xserver/hw/nxagent/Keyboard.c;h=e3b58b6c72e03a1143b6294cb5812ebcc40fce4b;hb=HEAD#l954
___
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: Porting NX: 64bit problems

[Ulrich Sibiller]

On Thu, Sep 17, 2015 at 4:30 PM, Adam Jackson <a...@nwnk.net> wrote:
> On Tue, 2015-09-01 at 00:09 +0200, Ulrich Sibiller wrote:
>> So I am looking for some advice how to solve this in a clean fashion.
>> Is there a document describing how to cleanly use libX11 calls from a
>> server? Is there some kind of best practice? Code examples? Does
>> anybody have some glue code that takes care of datatype conversion for that 
>> purpose?
>
> It's not easy or pretty, but it can be done.  Xnest is probably the
> simplest example, hw/xnest/Xnest.h has some boilerplate for renaming
> types appropriately.  DMX has a more complicated version of the same
> thing.

Thank you. There's something similar to Xnest.h called Agent.h in the
NX sources but it does not seem to solve the problem completely. The
problem is that XKB exists in the server and in the lib. Still
investigating.

> The other option is to strictly segregate the code the way pre-xcb-port
> Xephyr did, where all the xlib calls are in one file and the server
> interface in another, and you define your own types to pass stuff back
> and forth.

This looks promising. However, it means touch a lot of places so I'll
try to solve it with the other suggestion for now.

Thank you,

Uli
___
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 libX11 3/4] Fixes: warning: variable 'req' set but not, used

[Ulrich Sibiller]

On Sat, Jun 4, 2016 at 5:19 PM, walter harms  wrote:
> Fixes: warning: variable 'req' set but not used [-Wunused-but-set-variable]
>by marking req _X_UNUSED
> Solution was discussed on xorg-devel ML
>Peter Hutter, Alan Coopersmith
> Re: [PATCH libX11 3/5] fix: warning: pointer targets in passing 
> argument 2 of '_XSend' differ in signedness [-Wpointer-sign]

Hello,

I see a lot unapplied stuff on patchwork, so is there any plan to
clear the backlog?

I am specially interested in the patch series by Walter Harms mentioned above.

Thanks,

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

Re: xorg-xserver/Xext/shm.c - missing swapped case?

[Ulrich Sibiller]

On Mon, May 6, 2019 at 6:28 PM Alan Coopersmith
 wrote:
>
> On 5/6/19 9:20 AM, Ulrich Sibiller wrote:
> > Since that code is really old (the PANORAMIX stuff came in with
> > XFree86 4.3.0.1 in November 2003) I am wondering if this really a bug
> > or if am missing something crucial here?
>
> I don't think X has ever truly supported a platform on which clients
> of different endianess can share memory - shared memory is typically
> local only, while endian swapping is typically remote only.

I agree. So the current situation is that the code is
a) incomplete
b) never used

IMHO consequently all the swapping code should be dropped from shm.c.
Swapped requests (wherever they come from) should simply return an
error then.

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

xorg-xserver/Xext/shm.c - missing swapped case?

[Ulrich Sibiller]

Hello,

it seems to me that the shm code in the xserver's Xext code is
incomplte for the swapped case. In ProcShmDispatch() we have:

case X_ShmPutImage:
#ifdef PANORAMIX
if (!noPanoramiXExtension)
return ProcPanoramiXShmPutImage(client);
#endif
return ProcShmPutImage(client);
case X_ShmGetImage:
#ifdef PANORAMIX
if (!noPanoramiXExtension)
return ProcPanoramiXShmGetImage(client);
#endif
return ProcShmGetImage(client);
case X_ShmCreatePixmap:
#ifdef PANORAMIX
if (!noPanoramiXExtension)
return ProcPanoramiXShmCreatePixmap(client);
#endif
return ProcShmCreatePixmap(client);

while in SProcShmDispatch() the PANORAMIX ifdefs are completely
missing (along with the relevant functions SProcPanoramiXShm...()).

Since that code is really old (the PANORAMIX stuff came in with
XFree86 4.3.0.1 in November 2003) I am wondering if this really a bug
or if am missing something crucial here?

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

libXfont2 - how to prevent memory leak?

[Ulrich Sibiller]

Hello,

I have some Xserver fork that uses a slightly adapted version of
dix/dixfonts.c:doListFontsAndAliases() for xorg-xserver.

Generally both the original and my version are working like this:
- init using FontFileStartListFonts(...,)
- loop until FontFileListNextFontOrAlias(...,private) returns BadFontName

The private data is malloc'ed by FontFileStartListFonts() and freed
only by FontFileListNextFontOrAlias() at some point. Only in that case
it will return BadFontName. In other words: If it returns BadFontName
that also means the private data has been freed.
FontFileListNextFontOrAlias() is the only place were the private data
is freed within libXfont2.

Now, the main difference in my case is that the loop is exited
prematurely if some condition is true. In that case the private data
will not have been freed. Valgrind find that and complains:

==15332== 2,500 (96 direct, 2,404 indirect) bytes in 6 blocks are
definitely lost in loss record 324 of 342
==15332==at 0x4C2DB8F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15332==by 0x5748B9E: FontFileStartListFonts (in
/usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1)
==15332==by 0x5748C4A: FontFileStartListFontsAndAliases (in
/usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1)
==15332==by 0x42859A: nxdoListFontsAndAliases (NXdixfonts.c:1163)
==15332==by 0x42C0E0: nxOpenFont (NXdixfonts.c:1541)
==15332==by 0x43392E: ProcOpenFont (NXdispatch.c:902)
==15332==by 0x434585: Dispatch (NXdispatch.c:482)
==15332==by 0x40EF77: main (main.c:355)

The private data format contains some more allocated data so just
calling free(private) is not freeing everything.

AFAICS there's no function call in libXfont that can be used for
freeing that private data. Internally libXfont uses a LFWIDataRec
structure for the private data but that structure is not public.

I can certainly clone the LFWIDataRec structure definition into my
code and free the data myself this way but this could break anytime if
libXfont changes the structure.

So I am looking for a better way to free that data without having to
run the loop to the end.

Shouldn't libXfont offer some additional FontFileEndListFonts() function?

Uli

PS:
- Source of FontFileListNextFontOrAlias
https://gitlab.freedesktop.org/xorg/lib/libxfont/-/blob/master/src/fontfile/fontfile.c#L1079
- Source of the code breaking the loop prematurely:
https://github.com/ArcticaProject/nx-libs/blob/3.6.x/nx-X11/programs/Xserver/hw/nxagent/NXdixfonts.c#L1204
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: libXfont2 - how to prevent memory leak?

[Ulrich Sibiller]

ping

On Sat, Oct 17, 2020 at 11:14 PM Ulrich Sibiller
 wrote:
>
> Hello,
>
> I have some Xserver fork that uses a slightly adapted version of
> dix/dixfonts.c:doListFontsAndAliases() for xorg-xserver.
>
> Generally both the original and my version are working like this:
> - init using FontFileStartListFonts(...,)
> - loop until FontFileListNextFontOrAlias(...,private) returns BadFontName
>
> The private data is malloc'ed by FontFileStartListFonts() and freed
> only by FontFileListNextFontOrAlias() at some point. Only in that case
> it will return BadFontName. In other words: If it returns BadFontName
> that also means the private data has been freed.
> FontFileListNextFontOrAlias() is the only place were the private data
> is freed within libXfont2.
>
> Now, the main difference in my case is that the loop is exited
> prematurely if some condition is true. In that case the private data
> will not have been freed. Valgrind find that and complains:
>
> ==15332== 2,500 (96 direct, 2,404 indirect) bytes in 6 blocks are
> definitely lost in loss record 324 of 342
> ==15332==at 0x4C2DB8F: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==15332==by 0x5748B9E: FontFileStartListFonts (in
> /usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1)
> ==15332==by 0x5748C4A: FontFileStartListFontsAndAliases (in
> /usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1)
> ==15332==by 0x42859A: nxdoListFontsAndAliases (NXdixfonts.c:1163)
> ==15332==by 0x42C0E0: nxOpenFont (NXdixfonts.c:1541)
> ==15332==by 0x43392E: ProcOpenFont (NXdispatch.c:902)
> ==15332==by 0x434585: Dispatch (NXdispatch.c:482)
> ==15332==by 0x40EF77: main (main.c:355)
>
> The private data format contains some more allocated data so just
> calling free(private) is not freeing everything.
>
> AFAICS there's no function call in libXfont that can be used for
> freeing that private data. Internally libXfont uses a LFWIDataRec
> structure for the private data but that structure is not public.
>
> I can certainly clone the LFWIDataRec structure definition into my
> code and free the data myself this way but this could break anytime if
> libXfont changes the structure.
>
> So I am looking for a better way to free that data without having to
> run the loop to the end.
>
> Shouldn't libXfont offer some additional FontFileEndListFonts() function?
>
> Uli
>
> PS:
> - Source of FontFileListNextFontOrAlias
> https://gitlab.freedesktop.org/xorg/lib/libxfont/-/blob/master/src/fontfile/fontfile.c#L1079
> - Source of the code breaking the loop prematurely:
> https://github.com/ArcticaProject/nx-libs/blob/3.6.x/nx-X11/programs/Xserver/hw/nxagent/NXdixfonts.c#L1204
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libX11 1/2] Indention fixes around recent dpy->in_ifevent changes

[Ulrich Sibiller]

>From 35072d172d0bfecb24fdd8437ecdcd0e391e1f14 Mon Sep 17 00:00:00 2001
From: Ulrich Sibiller 
Date: Wed, 30 Nov 2022 22:18:42 +0100
Subject: [PATCH libX11 1/2] Indention fixes around recent
dpy->in_ifevent changes

Use the same indention as the surrounding code.

Signed-off-by: Ulrich Sibiller 
---
 src/ChkIfEv.c  |  6 +++---
 src/IfEvent.c  |  6 +++---
 src/OpenDis.c  |  2 +-
 src/PeekIfEv.c |  4 ++--
 src/locking.c  | 16 
 5 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/src/ChkIfEv.c b/src/ChkIfEv.c
index 1bbcba5b..eba36941 100644
--- a/src/ChkIfEv.c
+++ b/src/ChkIfEv.c
@@ -49,8 +49,8 @@ Bool XCheckIfEvent (
  unsigned long qe_serial = 0;
  int n; /* time through count */

-dpy->in_ifevent++;
-LockDisplay(dpy);
+ dpy->in_ifevent++;
+ LockDisplay(dpy);
  prev = NULL;
  for (n = 3; --n >= 0;) {
 for (qelt = prev ? prev->next : dpy->head;
@@ -80,7 +80,7 @@ Bool XCheckIfEvent (
  /* another thread has snatched this event */
  prev = NULL;
  }
-dpy->in_ifevent--;
+ dpy->in_ifevent--;
  UnlockDisplay(dpy);
  return False;
 }
diff --git a/src/IfEvent.c b/src/IfEvent.c
index 593e7acf..54c37f00 100644
--- a/src/IfEvent.c
+++ b/src/IfEvent.c
@@ -48,8 +48,8 @@ XIfEvent (
  register _XQEvent *qelt, *prev;
  unsigned long qe_serial = 0;

-dpy->in_ifevent++;
-LockDisplay(dpy);
+ dpy->in_ifevent++;
+ LockDisplay(dpy);
  prev = NULL;
  while (1) {
 for (qelt = prev ? prev->next : dpy->head;
@@ -60,7 +60,7 @@ XIfEvent (
 *event = qelt->event;
 _XDeq(dpy, prev, qelt);
 _XStoreEventCookie(dpy, event);
-dpy->in_ifevent--;
+dpy->in_ifevent--;
 UnlockDisplay(dpy);
 return 0;
  }
diff --git a/src/OpenDis.c b/src/OpenDis.c
index 17dc4cb2..7c8d4e1a 100644
--- a/src/OpenDis.c
+++ b/src/OpenDis.c
@@ -189,7 +189,7 @@ XOpenDisplay (
  dpy->xcmisc_opcode = 0;
  dpy->xkb_info = NULL;
  dpy->exit_handler_data = NULL;
-dpy->in_ifevent = 0;
+ dpy->in_ifevent = 0;

 /*
  * Setup other information in this display structure.
diff --git a/src/PeekIfEv.c b/src/PeekIfEv.c
index 7e09c00b..68c028b7 100644
--- a/src/PeekIfEv.c
+++ b/src/PeekIfEv.c
@@ -49,7 +49,7 @@ XPeekIfEvent (
  register _XQEvent *prev, *qelt;
  unsigned long qe_serial = 0;

-dpy->in_ifevent++;
+ dpy->in_ifevent++;
  LockDisplay(dpy);
  prev = NULL;
  while (1) {
@@ -64,7 +64,7 @@ XPeekIfEvent (
  _XStoreEventCookie(dpy, );
  *event = copy;
 }
-dpy->in_ifevent--;
+dpy->in_ifevent--;
 UnlockDisplay(dpy);
 return 0;
  }
diff --git a/src/locking.c b/src/locking.c
index 690b2bf6..c550603e 100644
--- a/src/locking.c
+++ b/src/locking.c
@@ -486,12 +486,12 @@ static void _XIfEventUnlockDisplay(
 )
 {
 if (dpy->in_ifevent == 0) {
-dpy->lock_fns->lock_display = _XLockDisplay;
-dpy->lock_fns->unlock_display = _XUnlockDisplay;
-dpy->lock->internal_lock_display = _XInternalLockDisplay;
-UnlockDisplay(dpy);
+ dpy->lock_fns->lock_display = _XLockDisplay;
+ dpy->lock_fns->unlock_display = _XUnlockDisplay;
+ dpy->lock->internal_lock_display = _XInternalLockDisplay;
+ UnlockDisplay(dpy);
 } else
-return;
+ return;
 }

 static void _XLockDisplay(
@@ -521,9 +521,9 @@ static void _XLockDisplay(
 _XIDHandler(dpy);
 _XSeqSyncFunction(dpy);
 if (dpy->in_ifevent) {
-dpy->lock_fns->lock_display = _XIfEventLockDisplay;
-dpy->lock_fns->unlock_display = _XIfEventUnlockDisplay;
-dpy->lock->internal_lock_display = _XIfEventInternalLockDisplay;
+ dpy->lock_fns->lock_display = _XIfEventLockDisplay;
+ dpy->lock_fns->unlock_display = _XIfEventUnlockDisplay;
+ dpy->lock->internal_lock_display = _XIfEventInternalLockDisplay;
 }
 }

-- 
2.20.1

[PATCH libX11 1/2] Indention fixes around recent dpy->in_ifevent changes

[Ulrich Sibiller]

Resent due to gmail mangling tabs.. Seems impossible nowadays to send a 
plaintext mail unmodifed using gmail's web interface...


From 35072d172d0bfecb24fdd8437ecdcd0e391e1f14 Mon Sep 17 00:00:00 2001
From: Ulrich Sibiller 
Date: Wed, 30 Nov 2022 22:18:42 +0100
Subject: [PATCH libX11 1/2] Indention fixes around recent dpy->in_ifevent
 changes

Use the same indention as the surrounding code.

Signed-off-by: Ulrich Sibiller 
---
 src/ChkIfEv.c  |  6 +++---
 src/IfEvent.c  |  6 +++---
 src/OpenDis.c  |  2 +-
 src/PeekIfEv.c |  4 ++--
 src/locking.c  | 16 
 5 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/src/ChkIfEv.c b/src/ChkIfEv.c
index 1bbcba5b..eba36941 100644
--- a/src/ChkIfEv.c
+++ b/src/ChkIfEv.c
@@ -49,8 +49,8 @@ Bool XCheckIfEvent (
unsigned long qe_serial = 0;
int n;  /* time through count */

-dpy->in_ifevent++;
-LockDisplay(dpy);
+   dpy->in_ifevent++;
+   LockDisplay(dpy);
prev = NULL;
for (n = 3; --n >= 0;) {
for (qelt = prev ? prev->next : dpy->head;
@@ -80,7 +80,7 @@ Bool XCheckIfEvent (
/* another thread has snatched this event */
prev = NULL;
}
-dpy->in_ifevent--;
+   dpy->in_ifevent--;
UnlockDisplay(dpy);
return False;
 }
diff --git a/src/IfEvent.c b/src/IfEvent.c
index 593e7acf..54c37f00 100644
--- a/src/IfEvent.c
+++ b/src/IfEvent.c
@@ -48,8 +48,8 @@ XIfEvent (
register _XQEvent *qelt, *prev;
unsigned long qe_serial = 0;

-dpy->in_ifevent++;
-LockDisplay(dpy);
+   dpy->in_ifevent++;
+   LockDisplay(dpy);
prev = NULL;
while (1) {
for (qelt = prev ? prev->next : dpy->head;
@@ -60,7 +60,7 @@ XIfEvent (
*event = qelt->event;
_XDeq(dpy, prev, qelt);
_XStoreEventCookie(dpy, event);
-dpy->in_ifevent--;
+   dpy->in_ifevent--;
UnlockDisplay(dpy);
return 0;
}
diff --git a/src/OpenDis.c b/src/OpenDis.c
index 17dc4cb2..7c8d4e1a 100644
--- a/src/OpenDis.c
+++ b/src/OpenDis.c
@@ -189,7 +189,7 @@ XOpenDisplay (
dpy->xcmisc_opcode  = 0;
dpy->xkb_info   = NULL;
dpy->exit_handler_data  = NULL;
-dpy->in_ifevent = 0;
+   dpy->in_ifevent = 0;

 /*
  * Setup other information in this display structure.
diff --git a/src/PeekIfEv.c b/src/PeekIfEv.c
index 7e09c00b..68c028b7 100644
--- a/src/PeekIfEv.c
+++ b/src/PeekIfEv.c
@@ -49,7 +49,7 @@ XPeekIfEvent (
register _XQEvent *prev, *qelt;
unsigned long qe_serial = 0;

-dpy->in_ifevent++;
+   dpy->in_ifevent++;
LockDisplay(dpy);
prev = NULL;
while (1) {
@@ -64,7 +64,7 @@ XPeekIfEvent (
_XStoreEventCookie(dpy, );
*event = copy;
}
-dpy->in_ifevent--;
+   dpy->in_ifevent--;
UnlockDisplay(dpy);
return 0;
}
diff --git a/src/locking.c b/src/locking.c
index 690b2bf6..c550603e 100644
--- a/src/locking.c
+++ b/src/locking.c
@@ -486,12 +486,12 @@ static void _XIfEventUnlockDisplay(
 )
 {
 if (dpy->in_ifevent == 0) {
-dpy->lock_fns->lock_display = _XLockDisplay;
-dpy->lock_fns->unlock_display = _XUnlockDisplay;
-dpy->lock->internal_lock_display = _XInternalLockDisplay;
-UnlockDisplay(dpy);
+   dpy->lock_fns->lock_display = _XLockDisplay;
+   dpy->lock_fns->unlock_display = _XUnlockDisplay;
+   dpy->lock->internal_lock_display = _XInternalLockDisplay;
+   UnlockDisplay(dpy);
 } else
-return;
+   return;
 }

 static void _XLockDisplay(
@@ -521,9 +521,9 @@ static void _XLockDisplay(
 _XIDHandler(dpy);
 _XSeqSyncFunction(dpy);
 if (dpy->in_ifevent) {
-dpy->lock_fns->lock_display = _XIfEventLockDisplay;
-dpy->lock_fns->unlock_display = _XIfEventUnlockDisplay;
-dpy->lock->internal_lock_display = _XIfEventInternalLockDisplay;
+   dpy->lock_fns->lock_display = _XIfEventLockDisplay;
+   dpy->lock_fns->unlock_display = _XIfEventUnlockDisplay;
+   dpy->lock->internal_lock_display = _XIfEventInternalLockDisplay;
 }
 }

--
2.20.1

Re: [PATCH libX11 1/2] Indention fixes around recent dpy->in_ifevent changes

[Ulrich Sibiller]

Well, then the documentation is wrong, I tried to follow this:

https://www.x.org/wiki/Development/Documentation/SubmittingPatches/

which clearly talks about sending patches to the ML, but at the same time
mentioning gitlab without mentioning merge requests. Would have preferred a
gitlab MR instead of this ML hassle... ;-)

Uli


On Thu, Dec 1, 2022 at 12:37 AM Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:

> On 11/30/22 14:42, Ulrich Sibiller wrote:
> > Resent due to gmail mangling tabs.. Seems impossible nowadays to send a
> plaintext mail unmodifed using gmail's web interface...
>
> Just one of many reasons we prefer patches to be sent as merge requests on
> https://gitlab.freedesktop.org/xorg/lib/libx11 instead.  We can handle
> emailed patches if using gitlab is a problem for you, but then we have
> to be extra careful to make sure it doesn't get mangled at any point
> along the way.
>
> --
>  -Alan Coopersmith- alan.coopersm...@oracle.com
>   Oracle Solaris Engineering - https://blogs.oracle.com/solaris
>
>

PATCH libX11 2/2] ChkIfEv.c: fix wrong handling of dpy->in_ifevent

[Ulrich Sibiller]

From 9d6bb3d179427d832d811e61fb6e4ebb9d004283 Mon Sep 17 00:00:00 2001
From: Ulrich Sibiller 
Date: Wed, 30 Nov 2022 22:19:15 +0100
Subject: [PATCH libX11 2/2] ChkIfEv.c: fix wrong handling of dpy->in_ifevent

Is no longer a bool but a counter.

Signed-off-by: Ulrich Sibiller 
---
 src/ChkIfEv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ChkIfEv.c b/src/ChkIfEv.c
index eba36941..b32c2d3e 100644
--- a/src/ChkIfEv.c
+++ b/src/ChkIfEv.c
@@ -61,7 +61,7 @@ Bool XCheckIfEvent (
*event = qelt->event;
_XDeq(dpy, prev, qelt);
_XStoreEventCookie(dpy, event);
-dpy->in_ifevent = False;
+   dpy->in_ifevent--;
UnlockDisplay(dpy);
return True;
}
--
2.20.1