The XCB (http://xcb.freedesktop.org) developers and maintainers have
released xcb-proto 1.0, libxcb 1.0, and libx11 1.1. (More details about
XCB at the end of this mail.) We have uploaded packages of xcb-proto 1.0
and libx11 1.1 into experimental, with libxcb 1.0 packages on their way
after #398327 gets fixed. We plan to upload these packages to unstable
after the etch release.
libx11 1.1 includes our work on Xlib/XCB, 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
incrementally. libx11-6 1.1 is API- and ABI-compatible with previous
versions, and does not require any software changes or package rebuilds.
Due to the number of packages with dependencies on libx11, we need your
help to get as much widespread testing as we can. Please install
libx11-6 from experimental, and test it with your normal everyday usage.
Test your packages against it. Build and test it on your preferred
architectures. Stress-test it if you like; throw whatever you can at
it, and let us know about anything that doesn't bounce off.
Ideally, you will not notice any change at all. However, Xlib/XCB
includes some additional code to check for bugs in calling software. If
you encounter a problem, you will most likely just see an application
disappear, due to having triggered an assertion and aborted. If you ran
the application from a terminal, you can look there to see error output
and get more details; otherwise, look at ~/.xsession-errors. The
assertions look like one of these:
xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Both of these represent bugs in a caller of libX11, and *not* in libX11
or libxcb. The first assertion means that a caller attempted to lock
the display while already locked. The second assertion means that a
caller attempted to unlock the display without having it locked. If you
encounter such bugs, please report a bug against the offending software
(*not* libx11-6 or libxcb), provide a backtrace, and X-Debbugs-CC:
xcb@lists.freedesktop.org if you need help tracking down the problem.
If the bug always consistently occurs when running the application (or
in the case of a library, invoking the library), use severity
"important", and raise to "grave" after the etch release.
Several core X libraries have locking bugs of this type, with fixes
applied upstream, and filed as bugs against the corresponding packages:
http://bugs.debian.org/400440
http://bugs.debian.org/400441
http://bugs.debian.org/400442
http://bugs.debian.org/400443
http://bugs.debian.org/400445
http://bugs.debian.org/400446
About libxcb
============
libxcb provides an interface to the X Window System protocol, which
replaces the current Xlib interface. It has several advantages over
Xlib, including:
- size: small library and lower memory footprint
- latency hiding: batch several requests and wait for the replies later
- direct protocol access: one-to-one mapping between interface and protocol
- proven thread support: transparently access XCB from multiple threads
- easy extension implementation: interfaces auto-generated from XML-XCB
Xlib can also use XCB as a transport layer, allowing software to make
requests and receive responses with both, which eases porting to XCB.
However, client programs, libraries, and toolkits will gain the most
benefit from a native XCB port.
About xcb-proto
===============
xcb-proto provides the XML-XCB protocol descriptions that libxcb uses to
generate the majority of its code and API. We provide them separately
from libxcb to allow reuse by other projects, such as additional
language bindings, protocol dissectors, or documentation generators.
This separation between the XCB transport layer and the
automatically-generated protocol layer also makes it far easier to write
new extensions. With the Xlib infrastructure, client-side support for
new extensions requires significant duplication of effort. With XCB and
the XML-XCB protocol descriptions, client-side support for a new
extension requires only an XML description of the extension, and not a
single line of code.
- Josh Triplett <josh@freedesktop.org>, Jamey Sharp <jamey@minilop.net>
Attachment:
signature.asc
Description: Digital signature