|| ||Jamey Sharp <jamey-AT-minilop.net>, Josh Triplett <josh-AT-freedesktop.org>|
|| ||xcb-AT-lists.freedesktop.org, xorg-announce-AT-lists.freedesktop.org,
|| ||[ANNOUNCE] XCB 1.0 release candidate 2 now available|
|| ||Sat, 7 Oct 2006 22:19:37 -0700|
The XCB developers proudly announce the 1.0 RC2 (0.9.92) release of
xcb-proto and libxcb, now available from:
with sha1sum: 49a99e3de998ae68668fe2f4a96073e9e55ee3ab
with sha1sum: 2171efebfefa7b528c8a4a9ca5fba7cacff039f4
with sha1sum: 51452589aab68ac60fd968ceeacf8af8de835c84
with sha1sum: ed04ea3c0990c0e868cdb8a55c55b502d5aad95b
libxcb provides an interface to the X Window System protocol, slated to
replace the current Xlib interface. It has several advantages over
- 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.
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.
Why this release?
We have provided this second candidate release to allow for more widespread
review and testing before XCB 1.0. As of version 1.0, libxcb will
provide a stable API and ABI; future changes will consist only of
additions, and applications compiled against XCB 1.0 or newer will work
with all future versions of XCB. Barring discovery of serious issues
with the API, we do not anticipate any API changes between this release
and the 1.0 release.
We would greatly appreciate API review in this final release candidate period.
Comparison between the protocol descriptions, generated protocol stubs,
and existing protocol documentation and implementations would be particularly
XCB has received testing on various operating systems, including
GNU/Linux (multiple distributions), FreeBSD, Solaris, MacOS X, and GNU/Hurd.
Most testing has occurred on x86 and x86-64, but big-endian processors such
as PowerPC and SPARC have also received limited testing. The library
should build with recent versions of GCC and Sun's compiler. We would
welcome testing on more diverse operating systems, processors, and
Please report any issues you find to the freedesktop.org bug tracker,
Discussion about XCB occurs on the XCB mailing list:
You can obtain the latest development versions of XCB using GIT.
For anonymous checkouts, use:
git clone git://anongit.freedesktop.org/git/xcb/libxcb
git clone git://anongit.freedesktop.org/git/xcb/proto
For developers, use:
git clone git+ssh://git.freedesktop.org/git/xcb/libxcb
git clone git+ssh://git.freedesktop.org/git/xcb/proto
This release corresponds to the GIT tag "1.0-RC2", signed by Josh Triplett
with key ID D0FE7AFB. In each repository, the tag may be verified with
git verify-tag 1.0-RC2
Detailed notes on this release follow.
-- Jamey Sharp <email@example.com>, Josh Triplett <firstname.lastname@example.org>
xcb-proto Release 1.0 RC2 (2006-10-07)
* Add <import>xproto</import> explicitly to extensions that use xproto;
this goes along with the change in the code generator for libxcb 1.0
RC2 to stop implicitly importing xproto.
* Change "union" to "xidunion" for XID unions like DRAWABLE and
FONTABLE, so that the code generator can more easily declare these XID
unions as integer typedefs rather than unions.
* Replace structures attempting to provide C type safety with CARD32
* render.xml no longer describes the CompositeGlyphs* requests as taking
lists of complicated unions of structures of lists: it says instead
that they take a LISTofBYTE. The caller is responsible for
constructing an appropriate sequence of glyph elements. Previously,
the requests could not actually be used because XCB did not correctly
compute the length of the provided data.
libxcb Release 1.0 RC2 (2006-10-07)
In our announcement of XCB 1.0 RC1, we proposed two API changes for
We would greatly appreciate API review in this final release
candidate period. We've had some limited feedback that our attempts
to impose static type safety on XIDs in C pose more a hindrance than
a help, so we would appreciate discussion over whether this
constitutes a "serious issue with the API". Some question also
remains of whether xcb_poll_for_event should have the out-parameter
'error', now that XCB has a more uniform mechanism for reporting
connection errors. Speak now on these points or leave us alone. ;-)
Since we've received feedback agreeing with our proposed changes, and no
objections or requests to keep the existing API, we made both changes
and bumped the soname to libxcb.so.1.0.0 in preparation for the release
of XCB 1.0.
* Remove XID wrapper structures and replace them with uint32_t typedefs.
XID union types like xcb_drawable_t and xcb_fontable_t also become
uint32_t typedefs. The API conversion script now replaces xcb_*_new
with calls directly to xcb_generate_id. This change makes
xcb_generate_id part of the client API rather than the extension API,
so move xcb_generate_id from xcbext.h to xcb.h.
* Remove the 'int *error' out-parameter for xcb_poll_for_event.
xcb_poll_for_event now shuts down the xcb_connection_t on fatal
errors; use xcb_connection_has_error to check.
The Xlib-specific API in libxcb-xlib also changed:
* Stop exposing the XCB IO lock for Xlib's benefit, by removing
xcb_get_io_lock from the Xlib-specific XCB API; instead, libxcb-xlib
now provides xcb_xlib_lock and xcb_xlib_unlock.
Code generation changes
* The code generator no longer implicitly imports xproto for extensions.
xcb-proto 1.0 RC2 includes the corresponding change to explicitly
import xproto in extensions that need it
* The generated protocol headers now declare "struct foo", "union foo"
or "enum foo", not just the typedef "foo" of an unnamed
* Make Plan 7 'checked' requests work correctly.
* Document xcb_generate_id.
* Tutorial enhancements.
to post comments)