Commit 1472048b7 to fix a colormap threading issue added a display
lock/unlock and a call to SyncHandle() to _XcmsFreeClientCmaps().
When running synchronized, that means calling XSync().
_XcmsFreeClientCmaps() is called from _XFreeDisplayStructure() via
XCloseDisplay() after the xcb connection is closed.
So when running synchronized, we may end up calling XSync() after the
xcb connection to the display is closed, which will generate a spurious
XIO error:
| #0 in _XDefaultIOError () at /lib64/libX11.so.6
| #1 in _XIOError () at /lib64/libX11.so.6
| #2 in _XReply () at /lib64/libX11.so.6
| #3 in XSync () at /lib64/libX11.so.6
| #4 in _XSyncFunction () at /lib64/libX11.so.6
| 8#5 in _XFreeDisplayStructure () at /lib64/libX11.so.6
| 8#6 in XCloseDisplay () at /lib64/libX11.so.6
To avoid that issue, closed the xcb connection to the display last.
v2: And same in OutOfMemory() as well (José Expósito)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/264>
Make use of the new 64-bit sequence number API in XCB 1.11.1 to avoid
the 32-bit sequence number wrap in libX11.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71338
Signed-off-by: Christian Linhart <chris@demorecorder.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
And there was much rejoicing.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Consensus on #xorg-devel agrees with removing --without-xcb; in
particular, acks from Adam Jackson, Daniel Stone, Kristian Høgsberg,
Julien Cristau, and Rémi Cardona.
Rename all instances of "XCL" to Xlib/XCB-derived names.
The only user-visible change: rename the include file <X11/xcl.h> to
<X11/Xlib-xcb.h>; programs will need to change their #include lines to match.
Remove the XCL cast inlines from Xlib-xcb.h.
We can never change the libX11 soname, and we don't want to commit to never
changing the public Xlib/XCB functions, so split them into a separate library
libX11-xcb. This also means that a program linked solely against libX11
should work with either Xlib or Xlib/XCB, which will make life easier for
package maintainers.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Acked-by: Jamey Sharp <jamey@minilop.net>
- For Xcomposite and Xdamage, don't link the build system out of the xc tree
- Link the public X11 headers into their own directory
- Add links to XKeysymDB and XErrorDB
- Add links to all the Xlib man pages
- Add links to the lcUniConv subdirectory
- Conditionally include config.h in Xlib source