Toolkit, please: Xlib -> XCB

We all know since 2006 (?) that the world is turning to use XCB instead Xlib as the interface between X clients and the server. The advantages of using XCB is well know but, even so, it’s being adopted very slowly for some reason – for instance no toolkits yet ported it. If this serves as a motivation, Alan got a really nice measurements porting a simple X app.

Translate your toolkit and application now! :)

17 thoughts on “Toolkit, please: Xlib -> XCB

  1. I can name you a problem why people don’t want to switch to xcb. But it’s just my opinion (e.g. why I don’t switch to xcb). You see, we don’t use just xlib anymore, there a lot of essential extensions (like ximage, xrender, etc.) that everyone use. And even though we have XCB now, no one actually said: “ok, I’m gonna do those extension things now”. As a result we have the xcb-util and by naming it util and having all those important tiny things as a pile of headers in a strange library.. It just doesn’t work for people. Personally I need a good library with versions, appropriate name and stuff like that, not some kind of “util”, because after all it feels like it will be required to write few more “utils” by myself.

    It just doesn’t feel like a real library even if it is. Period. I bet a lot of people who start new project or just considering to switch think the same way. It’s like choosing between two libraries and you know that there are a lot of projects written using xlib and almost none (except weird WMs like awesome) using xcb. So.. the choice is kind of obvious (even if it isn’t really).

    1. All X extensions go through some X library, be it Xlib or XCB… but yeah, reading the rest of your comment made me think to deprecate entirely Xlib then to force people use *the* *correct* :)

    1. that might be true yeah. But it’s also likely that other different apps will have performance improvements anyway if implemented to use XCB only.

    1. Are older X servers on old unix platform actually going to be used to run apps requiring, say, GTK+ >2.20? I really doubt it.

    2. It absolutely does not break compatibility with older X *servers*.

      It might break compatibility with old versions of Xlib, if you use the Xlib/XCB compatibility layer that requires recent Xlib (where “recent” here means “years”). But it won’t break compatibility with the X *server*.

  2. Has the situation with glx improved? Last time i looked it seemed like you still needed xlib for glx related operations. With the adoption of clutter into gnome-shell and i’d expect other things this would seem that xlib isn’t going away (unless i’m wrong, which i hope I am).

    1. Short answer: We recommend a particular migration strategy for libraries, such as Mesa, which cairo is currently illustrating: re-write the library in terms of XCB, but provide the old Xlib interface as a thin wrapper on top using Xlib/XCB. This strategy means we certainly aren’t stuck with Xlib forever, no matter how much code is written today using it: we can replace it incrementally.

      Jeremy Kolb was doing this work on Mesa five years ago, but it needs somebody else to pick it up again. Mesa is a particularly appealing target because, like XCB, much of its code is auto-generated from descriptions of the GLX requests.

      For hand-written code, Josh Triplett has been using Coccinelle to automate parts of the migration process, which should help with getting more code migrated more quickly.

  3. Tiago tells me I have to defend XCB now. Of course, I feel the best technology should win, and if people feel that’s Xlib, I guess their insanity is not my problem. :-)

    Sander: There was one GLX implementatation bug in X server versions around 6.8, but other than those sorts of server bugs, XCB should work with every X server back to September 1987. What breakage did you have in mind?

    nsf: X extensions are provided by XCB, not by util, and XCB does provide most extensions that applications use today. The important exceptions at the moment are XKB and XI, which a Summer of Code student is fixing right now. (Those extensions turn out to be awfully hairy, as anyone who has worked with them will tell you.)

    When I first started lumping code into a “util” module, I was just trying to give some examples of using XCB, not trying to design real APIs. It turned out that some people found my scribbles useful and built on them, to the point where they have very little resemblance to where I started. Now we mostly have a problem of release management for those libraries. Contributions gratefully accepted. :-)


    These apps may not be representative of Gnome or KDE desktop workloads, but people do actually care about them. I’m as surprised as you are…

    XCB offers opportunities for better performance in *all* applications to some extent. If you think you have a counter-example, try me. :-) In many cases users probably can’t tell the difference, but of course improved performance is only one of XCB’s advantages. Any discussion trying to pit Xlib against XCB should consider the larger picture.

    1. the main reason of my post was to let people aware about the situation of XCB.

      I don’t intent now to start port every single X client around to use XCB. Rather, I hope that client side X developers (toolkit’s mainly) understand the situation we are living and think in a strategy to port their apps. My guess is that for “cultural” aspects (e.g. laziness) Xlib stills being used everywhere.

  4. I’ve been writing my own simple apps in XCB for a while now. So far I definitely like it and it’s useful, the biggest issues are input and graphics, two of the things which are rather necessary when writing an X application :). The input portion of it is being worked on this summer which is great to see. The graphics on the other hand still needs some help. There is the xcb binding for cairo which was announced on the mailing list a while ago. I’ve been using it with my program and it works well for everything I’ve done. It would be nice to see this backend pushed into the next cairo release as a stable backend. ATM with the distro I use it happened to be compiled in, and I had manually looked to see if there was a header which told me it existed, but pushing it into the standard package as a default compile and adding it to the online cairo API reference ( would make it a lot easier to find. The other thing that’s really missing as someone previously hinted at is direct OpenGL support. I know there has been some progress on multiple fronts, but having to use Xlib/XCB mix is a pain. It would be really nice to either make a GLX for XCB, which I know has been worked on some in mesa, or utilize something like EGL which is designed to be Windowing API agnostic.

    Overall though definitely want to say thanks for all the great progress! While there’s plenty to still gripe about, the linux desktop seems to be getting out of the dark ages, with XCB, an auto-config xserver, and other recent improvements.

  5. The first thing I noticed while looking at xcb is all the *_t types. On POSIX systems, it is ill-advised to define your own _t types.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s