[Xcb] [ANNOUNCE] XCB 1.0 release candidate 1 now available

Jamey Sharp jamey at minilop.net
Mon Sep 25 23:17:29 PDT 2006

The XCB developers proudly announce the 1.0 RC1 (0.9.91) release of
xcb-proto and libxcb, now available from:

	with sha1sum: b447894b8e46bc36dec89cf0ccd65e2db5e20b94

        with sha1sum: b05f6f14d9266aa3827a444a2d77c453c1b3131d

        with sha1sum: 8da28b68107613b67dc0dc51dc06a361b11953b4

	with sha1sum: edad8cb60daad429bc8ef0635ab2d6aeb6b6ae5d

About libxcb

libxcb provides an interface to the X Window System protocol, slated to
replace 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.

Why this release?

We have provided this 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. 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. ;-)

XCB has received testing on various operating systems, including
GNU/Linux (multiple distributions), FreeBSD, Solaris, and MacOS X. 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:

        <mailto:xcb at lists.freedesktop.org>

You can obtain the latest development versions of XCB using GIT. We have
split the previous monolithic GIT repository into separate repositories
for each project; for details on this split and the tool created to do
it, see the release notes below. 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-RC1", signed by Jamey Sharp
with key ID 0E08F665. In each repository, the tag may be verified with
the command:

	git verify-tag 1.0-RC1

Detailed notes on this release follow.

-- Jamey Sharp <jamey at minilop.net>, Josh Triplett <josh at freedesktop.org>

Release 1.0 RC1 (2006-09-25)

The Great XCB Renaming

Rename API to follow a new naming convention:

* xcb_functions_lowercase_with_underscores
* xcb_types_lowercase_with_underscores_and_suffix_t
* expand all abbreviations like "req", "rep", and "iter"

Word boundaries for the names in the protocol descriptions fall:

* Wherever the protocol descriptions already have an underscore
* Between a lowercase letter and a subsequent uppercase letter
* Before the last uppercase letter in a string of uppercase letters
  followed by a lowercase letter (such as in LSBFirst between LSB and
* Before and after a string of digits (with exceptions for sized types
  like xcb_char2b_t and xcb_glx_float32_t to match the stdint.h

Also fix up some particular naming issues:

* Rename shape_op and shape_kind to drop the "shape_" prefix, since
  otherwise these types end up as xcb_shape_shape_{op,kind}_t.
* Remove leading underscores from enums in the GLX protocol description,
  previously needed to ensure a word separator, but now redundant.

This renaming breaks code written for the previous API naming
convention. The scripts in XCB's tools directory will convert code
written for the old API to use the new API; they work well enough that
we used them to convert the non-program-generated code in XCB, and when
run on the old program-generated code, they almost exactly reproduce the
new program-generated code (modulo whitespace and bugs in the old code

Authors: Vincent Torri, Thomas Hunger, Josh Triplett

In addition to the API renaming, the library SONAMEs have changed to
libxcb.so and libxcb-extname.so. The library major version remains at 0,
to become version 1 before 1.0 is released; the SONAME lowercasing means
that this will not conflict with XCB 0.9 libraries.

The header files have moved from /usr/include/X11/XCB/ to
/usr/include/xcb/. The XML-XCB protocol descriptions have moved to
/usr/share/xcb, with extension descriptions no longer relegated to an
extensions/ subdirectory. The API conversion script api_conv.pl will fix
references to the header files, and packages using pkg-config will
automatically use the new library names.

Error handling Plan 7

All request functions now come in an "unchecked" and "checked" variant.
The checked variant allows callers to handle errors inline where they
obtain the reply, or by calling xcb_request_check for requests with no
reply. The unchecked variant uses the event queue for errors. Requests
with replies default to checked, because the caller must already make a
function call to retrieve the reply and can see the error at that time;
the unchecked variant uses the suffix _unchecked. Requests without
replies default to unchecked, because the caller will not necessarily
expect to handle a response, and the checked variant uses the suffix

Connection error handling

Fatal connection errors now put the xcb_connection_t object into an
error state, at which point all further operations on that connection
will fail. Callers can use the new xcb_connection_has_error function to
check for this state in a connection. Functions that return a
connection, such as the xcb_connect function, may instead return an
xcb_connection_t already in an error state.

In the future we expect to add additional API for getting more
information about the error condition that caused the connection to get
into an error state.

Smaller API changes

All functions that have been marked 'deprecated' up to now have been
removed for this release. After XCB 1.0 is released, functions marked
'deprecated' will be preserved until the end of time to maintain

XCB no longer provides a sync function. Most callers of this function
should use xcb_flush instead, which usually provides the intended
functionality and does not require a round-trip to the server. If you
really need this functionality, either use xcb_get_input_focus like sync
used to do, or use the xcb_aux_sync function from the xcb-aux library in
xcb-util. However, note that we do not consider the libraries in
xcb-util remotely stable yet.

XCB no longer provides xcb_[extension_name]_init functions for each
extension. These functions previously caused XCB to issue and process a
QueryExtension request. Callers should now directly call
xcb_get_extension_data on the xcb_[extension_name]_id, or use
xcb_prefetch_extension_data if they do not need to force a round-trip

The compatibility functions in xcbxlib.h, provided solely for use by
Xlib/XCB, now exist in a separate library libxcb-xlib. We don't want to
have to change the libxcb soname if we later change or remove the Xlib
compatibility functions, and nothing except Xlib/XCB should ever use
them. (Applications which use Xlib/XCB do not need this library either;
Xlib/XCB only uses it internally.)

The descriptions of several extensions have been updated to match the
latest versions implemented in the X.org X server.

GIT Repository split

Previously, several XCB-related projects all existed under the umbrella
of a single monolithic GIT repository with per-project subdirectories.
We have split this repository into individual per-project repositories.

Josh Triplett and Jamey Sharp wrote a tool called git-split to
accomplish this repository split. git-split reconstructs the history of
a sub-project previously stored in a subdirectory of a larger
repository. It constructs new commit objects based on the existing tree
objects for the subtree in each commit, and discards commits which do
not affect the history of the sub-project, as well as merges made
unnecessary due to these discarded commits.

We would like to acknowledge the work of the gobby team in creating a
collaborative editor which greatly aided the development of git-split
(as well as these release notes).

Build and implementation fixes

XCB no longer needs proto/x11 from X.org; the XCB header xproto.h
provides the definitions from X.h, named according to XCB conventions.

XCB should now build with non-GNU implementations of Make.

XCB properly handles 32-bit wrap of sequence numbers, and thus now
supports issuing more than 2**32 requests in one connection.

Fixed bugs #7001, #7261.
-------------- 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/xcb/attachments/20060925/21386393/attachment.pgp

More information about the Xcb mailing list