XCB, of course; if you're using a recent Xorg, you probably have this already
Lisp: cffi master (with libffi), static-vectors, trivial-garbage
Not strictly necessary: cl-opengl if you want to use GLX, cl-cairo2 if you want cairo-xcb integration.
Build this in a very fast console, or turn down SBCL verbosity. It normally builds reasonably fast, but if you try and run this in SLIME or a slow terminal with the compiler noting every top-level form, it will take forever. This imports the majority of Xlib and XCB, and the wrappers are nearly 21k lines and growing.
You may notice style-warnings for some undefined aliens; I get a list of some SGIX/MESA GL extensions. Nothing critically necessary should be on this list.
This has currently only been tested on SBCL, but more to come.
Demos, or "I want to see it work!"
I've started writing some demos, which should illustrate some basic things.
The rationale behind this is simple:
There are many nice libraries that depend on
libX11structures such as
libGLis one of these, especially if you want direct rendering.
CLX is an existing standard.
Thus, it would be nice if we could write to CLX, but somehow obtain
libX11-compatible data structures. Meet clx-xcb-xlib.
XCB, similar to CLX, is a reimplementation of the X protocol, but for
C. It, too, is not directly compatible with
libX11 and cannot
directly interface with things like OpenGL (excepting pure indirect
GLX), but the compatibility layer, Xlib/XCB, can. Many new things
are including XCB support directly.
The choice of wrapping XCB rather than directly wrapping
mostly due to its far superior error handling; it will not force-exit
a process when it encounters an I/O error. This makes it much more
(Unfortunately, things which call into
libX11 can still result in
fatal errors, but error handling is in place to prevent an immediate
CLX support is not 100%, but tries to be as close as possible. Work is still underway to complete the API, and it is getting very close. Generally not implemented, but coming soon:
- ICCCM / NET_WM
- Extensions beyond GLX (though list-extensions and query-extensions are implemented)
Unlikely to be implemented:
- Resources (chapter 13)
Unimplemented functions are listed in
are probably a few stragglers not listed above, but the rest of the
API should be in place.
This may not be enough to run all existing CLX applications, and there are (a very few) known-broken return formats. However this should be more than enough for new apps.
Some things are not directly compatible; for instance,
requires an XCB struct name, and has slightly different type syntax in
some cases. Incompatibilities should be noted in
doc/incompatibilities.txt. Perhaps of greatest note is GL/GLX
support, which requires
cl-opengl, and due to newer OpenGL APIs,
probably requires reworking GLX calls when coming from