OhEmGeeModules

(This is an experiment in conversational documentation. Please keep future modifications in this style.)

What is with all these modules?

So, what we used to do is everything that could possibly be related to the project was glommed together in one huge tarball. Including lots of things we weren't upstream for, or things that we didn't really care about, or that we even actively discouraged people from using. This was nice, because it gave you everything you could possibly want, all at once. But it was also terrible, because it meant you spent a lot of time grinding through things you didn't care about in order to actually work on the things you do care about. This was called the monolith, and it was the way of the world from basically X11R4 until X11R7. That's a long time!

In 7.0, we fixed that. In fact we probably over-fixed it. We split everything apart as far down as we possibly thought it could be split, so that everything is its own module and you never ever ever need to touch the things you don't want to worry about. But in the process, we seem to have neglected to document what all these modules are at a high level, so that people merely building things recreationally know where to get started.

So why haven't you documented it?

Well, because like all projects, documentation is rarely fun, so it rarely gets done. We suck. Sorry.

The ModularDevelopersGuide addressed this. Kind of. It addressed the mechanical part of building the world, and building individual modules, but it does so with the assumption that you actually knew what the modules were, and therefore which ones to care about. It turns out the people with that set of knowledge are, well, not in the majority.

This document attempts to address the other part of the documentation. It explains how Xorg is organized in terms of functional components, hopefully at a sufficiently high level that it can be understood by the common everyday compiler-wielding open-source-type crazy person.

Put down the chainsaw, please.

So what *are* all these modules?

X is a protocol. Client applications make requests of a server ("paint my window here", or "tell me when the left mouse button is pressed"), and the server handles interacting with the hardware to make those requests happen. So the very bottom layer of modules is the protocol definition itself. X is an extensible protocol, so the core protocol lives in one package, and the subsequent extensions live in individual packages.

Protocol definitions are wonderful, but ideally you have some libraries built atop that to provide convenient ways of speaking that protocol. Well, we've got some libraries, whether or not they're convenient is another issue. The vast majority of the libraries we provide are just wrappers around the protocol to turn the various requests, replies, events, and errors into something you can interact with from a C program. There are some other libraries that provide small useful things that aren't directly protocol-related, and then there's a third class of libraries that aim at loftier goals, like being a UI widget framework.

After you've got that, you can start writing applications. The X server is itself just another application, so it needs some of these libraries. All of the stock applications from the monolith depend on the libraries, some need more than others depending on what they do. The X server is sufficiently complicated that it needs a number of drivers to talk to different pieces of hardware. Finally, some data is shared between multiple applications, so those bundles are split out too.

Those applications, if they're old enough to use the font system we recommend people not use anymore, probably expect a fair number of fonts to be available, so we've got packages for those too. And some parts of the system really do have formal documentation, so we have packages for the docs as well. And then finally there are those pieces that we really couldn't categorize any better.

So, to recap: protocol, libraries, apps, X server, drivers, data, fonts, documentation, and miscellaneous. Compare that list with the module categories in the archive, it's a pretty exact map.

Hey, write the rest of me!