[ANNOUNCE] libX11 1.1

Jamey Sharp jamey at minilop.net
Thu Nov 23 23:58:43 PST 2006

It's not pinin', it's passed on! This library is no more! It has ceased to be!
It's expired and gone to meet its maker! This is a late library! It's a stiff!
Bereft of life, it rests in peace! If you hadn't nailed it to the perch it
would be pushing up the daisies! It's rung down the curtain and joined the
choir invisible! This is an X-lib!

After two candidate releases, the XCB developers have nailed libX11 1.1 to
the perch.

This release includes the Xlib/XCB work, which uses XCB as the Xlib
transport layer, and allows a client to use both Xlib and XCB on the
same connection. This allows clients to transition from Xlib to XCB

Clients which link only to libX11, and do not use XCB, should not notice
any differences between the previous 1.0 branch and this release.  Clients
desiring XCB interoperability can additionally #include <X11/Xlib-xcb.h>,
link to libX11-xcb, use XGetXCBConnection(dpy) to obtain the underlying XCB
connection, and then use XCB functions directly on that connection.

MD5: 6810531abcacf6da20da2d3257089960
SHA1: 78f7100258c75da826f16529654030a10811a660

MD5: a653fd80644cac700b98559db8d8186b
SHA1: 5c87ca009e1a73fb73dc8784755908ad6c85711b

GIT tag: libX11-1.1

Detailed changes:

* Add note in man-page that XListFontsWithInfo is not thread-safe.  _XReply
  drops the Display lock, so the value of dpy->request may change before
  _XReply is called again.  Jamey Sharp discovered this by inspection a few
  years ago.

* Fix Bug #8622, by fixing the response processing order for threaded apps.
  process_responses (the common code for _XReply, _XReadEvents, and
  _XEventsQueued) now handles responses in order, by adding condition variables
  to the list of outstanding requests in dpy->xcb->pending_requests, and
  blocking on them when those requests should get processed, to allow _XReply
  to process them; if actually called from _XReply, it returns when _XReply's
  request should get processed.  _XReply broadcasts on its condition variable
  after it has read its reply and re-acquired the display lock.

* Don't hold the display lock around callbacks to the application. This avoids
  recursive locking of the display lock (which triggers an XCB locking
  assertion), particularly with emacs.

* Add xcb-xlib dependency to x11.pc when built against XCB.

* Allocate the right amount of memory for dpy->lock_fns.  Fixes a crash on
  startup with gdk.

-- Josh Triplett <josh at freedesktop.org>, Jamey Sharp <jamey at minilop.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xorg-announce/attachments/20061123/bdb82832/attachment.pgp

More information about the xorg-announce mailing list