> The point I was trying to make was not that it cant be done but you end up mixing Xlib and xcb regardless. Its that xcb cant be used stand alone. In that sens

> The point I was trying to make was not that it cant be done but you end up mixing Xlib and xcb regardless. Its that xcb cant be used stand alone. In that sense its crippled. GLX is the weak spot, not XCB. And GLX is not something that we can change. Hopefully the situation will improve, either through a GLX+XCB backend, EGL or Wayland. You can't get rid of Xlib, but you can still benefit from XCB by using it for the non-gl stuff, which would be the majority of Qt, or any other X11+OpenGL app for that matter. And it would make no sense whatsoever to try to use a pre-XCB version of Xlib. Unlike XCB, which is machine generated and (partially) formally verified, Xlib has had bugs at a whole different scale. > By the way thank you for taking your time and writing those docs, being there isn't much on XCB as it is. Maybe you can talk some sense into the XCB guys to take a couple weeks of and document XCB properly. XCB is a machine generated library based on X11 specifications. The X11 specs are the documentation you want, just apply XCB coding conventions like the XCB source generator does. I don't want to bug the devs, they have better things to do than writing docs for noobs.