liblx

Warning

This document is still very preliminary. It is likely to be incomplete and/or incorrect and is very likely to change.

What is liblx?

liblx is an API to The X Window System, implementing the client side of the protocol spoken between clients and servers. It sits in the software stack at the same place as Xlib and xcb. (If you want you could think of it as a competitor to them. I prefer to think of them as complementary alternatives rather than competitors; their ideal use cases are different.)

liblx was the subject of a talk I gave on 2026-02-01 at FOSDEM 2026. FOSDEM's published video for the talk is, at this writing, here, with a copy mirrored here because video.fosdem.org has drunk the "we're going to ram HTTPS down everyone's throat" koolaid, and, as I read the license, I'm permitted to mirror it provided I give "appropriate credit" (which I believe the foregoing does) and "provide a link to the license" (which is here; I know of no non-HTTPS hosting for it, and that I don't care enough about to provide myself). I'm not particularly proud of the talk; I made various gaffes of varying severity (see below for more thoughts on the talk). But it is what it is, flubs and all.

Where does liblx work?

At this writing, 2026-02-06, the only machines I know it works on are my own and one work Linux machine. Its native home is NetBSD, but I expect it to be an easy-to-trivial port to make it work anywhere libaio and possibly libavl work. (libavl only if the application uses block function orders; see the libaio documentation. liblx itself does not need it.)

I've created a linux branch in the git repo with the changes I found necessary to make it work on the aforementioned work Linux machine. Because there is a huge variety of Linux distros, I can't promise that it'll work out of the box for you, but it's probably closer than the master branch is. Check out the linux branch and look at the READMEs. This branch also includes copies of the various other of my libraries (and one program) that liblx depends on.

So what does liblx-using code look like?

I've written some example programs.

xwarp.c: A program to warp the pointer to a position specified on the command line.
delwin.c: A command-line program to generate WM_DELETE_WINDOW requests.
talk-example.c: An example program I wrote for the aforementioned FOSDEM talk.

I've got many more, a few of which I'm giving here. These ones, though, I haven't gone through and commented, so they are drastically under-documented. As I get them commented, I'll move them to the list above.

sgf A directory containing an SGF replayer. It's fairly rudimentary at present.

More thoughts pursuant to my FOSDEM talk

In the talk, I spoke of SHAPE version 1 being supported but not SHAPE version 2. That was because I had not looked at SHAPE recently enough; the ‘version 2’ I spoke of is actually version 1.1.
Extension support is very incomplete. There is currently no support at all for extension events or errors.
I have written support for BIG-REQUESTS. It is as yet untested, but if it doesn't work it's now a matter of finding/fixing bugs rather than writing new code per se.
I spoke of Wayland as having thrown away network transparency and as being Linux-specific. After the talk, I spoke with someone who told me that both of those are out of date, that it exists on (at least some) non-Linux and that it has grown a network protocol. I'm still not switching, though; in view of Wayland's design, its network protocol is ncessarily far more bandwidth-hungry than X's (that's important to some of my use cases) and I really do not like the Wayland paradigm of rendering everything client-side and pushing rendered bitmaps to the server. (I didn't discuss it at FOSDEM, but I suspect it also doesn't support anything other than, in X terms, 24+-bit TrueColor. I use shallower hardware, such as 8-bit PseudoColor, routinely.)
I spoke of GLX probably being implementable. I have now looked at GLX in enough detail that I am reasonably sure it is implementable, though the GL API built on top of it would necessarily be rather different from the GL API built on top of Xlib-based GLX, just as the X API presented by liblx is rather different from the X API presented by Xlib. As with core X, this is most visible for requests that return things. For example, a GenLists operation would have to take a callback rather than returning the new base list directly. (All the foregoing is from a purely technical perspective. Because of Khronos's unusual licensing, it is not clear to me that it would be legal to even implement, much less distribute, such a thing. It may even vary by jurisdiction.)

Where can I find more doc?

I have not yet even started writing a full manpage (or manpages). At the moment, documentation takes two forms:

Comments in lx.h, which you can find in my unpacked-git-repos space here;
Text doc files, which exist in my unpacked-git-repos space here.

How do I get liblx?

My primary distribution mechanism is a world-clonable git repo: git://git.rodents-montreal.org/liblx is the thing to clone. There's also the unpacked view of the git repo; see here for the contents of HEAD or here for the per-repo top directory for liblx (and here, in particular the README, for more on the paradigm this exemplifies).

For building it, if you don't want to use my build infrastructure, which I expect describes most of you, check out the ‘linux’ branch of the git repo; that branch includes copies of the source to other libraries and tools used for building liblx, and a few updates to work around some of Linux's idiosyncracies. And, of course, as I said in my talk, you can always send me mail. It might even work! :-)

Mouse, reachable @rodents-montreal.org with the obvious local-part (mouse).

Almost all these pages—all, I think—are 100% hand-coded.