Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Extensions
One of the great strengths of the X11 protocol is its support for extensions. In the 1990s, this was also its great weakness because every UNIX vendor shipped its own X server with different extensions. Now, X.org is used almost everywhere, and so the same set of core extensions can be used everywhere.
Supporting extensions with Xlib was very difficult. The code was confusing and needed to be modified for each extension. With XCB, it is much easier. All extension developers need to provide is an XML description of the protocol. This is then automatically turned into a set of functions. All users need to do is link against the library generated from this description and include the relevant headers.
Each extension in X11 defines a set of requests and events. Any X server can support a different set of extensions, and not all of them are always used by the same clients. The numbers used to identify the events are therefore assigned dynamically.
If you want to use an extension in an XCB program—which you almost certainly will—then you need to first query that it is present using xcb_query_extension(). As with all of the other XCB functions that issue requests, this returns a cookie which is then passed to xcb_query_extension_reply() to get the reply later. The mapping for requests is handled internally in XCB—the API for issuing them will automatically calculate the request number—but you have to handle events yourself.
The event structure's response_type field contains a number uniquely identifying the event type. For the core protocol, these numbers are constant. For extensions, they are found by adding the first_event field of the extension reply to a number defined by the protocol.
When you look in the headers for an extension, you will find a constant for each event that the extension can generate. These must be added to the first event number for the extension to give the real event number.