[Xcb] Re: [ANNOUNCE] XCB 1.0 now available
jkolb at brandeis.edu
Sun Nov 26 09:29:08 PST 2006
Woohoo! I come back from vacation and look what I have in my mailbox.
Jamey Sharp wrote:
> First shalt thou take out the Holy Pin. Then, shalt thou release three. No
> more, no less. Three shall be the number thou shalt release, and the number of
> the releasing shall be three. Four shalt thou not release, neither release thou
> two, excepting that thou then release three. Five is right out. Once the number
> three, being the third number, be released, then lobbest thou thy Holy Hand
> Grenade of XCB towards thy foe Xlib, who, being naughty in My sight, shall
> snuff it.
> After three release candidates, the XCB developers proudly lob the release
> of libxcb 1.0 and xcb-proto 1.0, now available from:
> with sha1sum: c7252cc74f75c997227b4dcdba2cb654d89cecda
> with sha1sum: c87c8e9da8a5bfdc0653a93e753cbb19409bf0e2
> with sha1sum: 0a7e0b65e6f1e0ef4dcaecaa01c4b2854206e96e
> with sha1sum: e4f79d6c696d751c088c92237a1695de7e0f1837
> 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.
> Why this release?
> Now that XCB has received widespread testing via three release candidates,
> we have provided a 1.0 release to form a stable base on which to build other
> software. All future versions of libxcb will preserve compatibility with
> libxcb 1.0.
> Please report any issues you find to the freedesktop.org bug tracker, at:
> Discussion about XCB occurs on the XCB mailing list:
> <xcb at lists.freedesktop.org>
> 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
> This release corresponds to the GIT tag "1.0", signed by Josh Triplett
> with key ID D0FE7AFB. In each repository, you can verify this tag with
> the command:
> git verify-tag 1.0
> Detailed notes on this release follow.
> libxcb Release 1.0 (2006-11-23)
> The "Thanksgiving" release: We feel thankful to have it released. Five years
> have passed since XCB's initial commit on September 3rd, 2001:
> * Support IPv6. XCB now supports displays with IPv6 addresses, with or without
> enclosing square brackets, or with hosts which resolve to IPv6 addresses, by
> using getaddrinfo instead of gethostbyname, and by including support for
> authentication for such connections. This allows such displays as "::1:1.1".
> * XCB now uses the libpthread-stubs, to properly support optional use of
> pthreads even on platforms which do not have all the necessary pthread stubs
> in libc or otherwise available by default.
> * Switch from the old AM_PATH_CHECK macro to pkg-config. check 0.9.4 is now
> required to build XCB's unit tests. The version that we were requiring was
> not actually new enough to let our unit tests compile, and the AM_PATH_CHECK
> macro is now considered deprecated. We know that versions of check using
> pkg-config are new enough to work, and the check dependency was optional
> anyway, so we've dropped support for older versions.
> * Provide a xcb_prefetch_maximum_request_length counterpart to
> * Fix Bug #5958: zero out padding bytes in requests.
> * Change xcb_connect to pass the display number to _xcb_get_auth_info, which
> passes it to get_authptr. This allows get_authptr to stop hacking the
> display number out of the sockaddrs of various address families, such as
> port - X_TCP_PORT, or the number after the last X in the UNIX socket path.
> * Remove --with-opt and --with-debug options from configure.ac; configure
> supports the use of custom CFLAGS, so please use that instead.
> * Reove support for the <localfield> tag in protocol descriptions, since they
> no longer use it, and since new protocol descriptions should not need it
> * xcb-proto has no libraries or headers, so don't use XCBPROTO_CFLAGS or
> * XCB builds which use xdmcp now include it in Requires.private, to support
> static linking.
> * Replace "long" with uint32_t when used for a 32-bit quantity
> * Various enhancements to the generation of documentation with Doxygen:
> * Check for doxygen in configure.ac
> * Fix some Doxygen warnings.
> * Install documentation.
> * Handle out-of-tree builds, with srcdir != builddir. xcb.doxygen now gets
> generated from xcb.doxygen.in, so that it can use top_builddir and
> top_srcdir to find source and to output documentation.
> * Fill in PROJECT_NUMBER from @VERSION@, now that we have it readily
> available via autoconf.
> proto Release 1.0 (2006-11-23)
> The "Thanksgiving" release: We feel thankful to have it released.
> * Fix Bug #8990: randr type fixes
> * Fixed screen parameter type in several GLX requests to use CARD32 instead
> of the SCREEN structure.
> * Corrected valueparam arguments to attribute lists in several requests and
> a reply.
> * Estethic change for attribute parameter name
> * Remove support for the <localfield> tag: nothing needs it.
> * Fix Bug #8973: In UngrabKey, the 'key' field should have type KEYCODE, not
> the more general CARD8.
> xorg mailing list
> xorg at lists.freedesktop.org
More information about the Xcb