Non-modular X?

It has been nearly six years since the release of X11R7.0, the first major release done by the X.Org Foundation. Among the many changes in this release was the change to a new modular architecture that allowed individual graphics drivers to be built and distributed independently from the server itself. Separating out the drivers was seen as a way to make it easier to contribute to their development and to get support for new hardware out to users as quickly as possible. By all accounts, X.Org has been a success, and the modular server architecture would seem to have worked out well.

So it is interesting to see a surge of new discussion of the architecture of our graphics subsystems at all levels. At the kernel level, developers are rethinking the relationships between graphics subsystems; that discussion will be covered in a separate article. At the X.Org level, instead, developers are considering undoing one of the headline changes from X11R7.0 and pulling graphics drivers back into the server itself.

The topic was evidently discussed at the recently-concluded X.Org Developer Conference; Jesse Barnes then brought it to the mailing list with the goal of discussing the good and bad aspects of returning to a monolithic server. At the top of his list of "pros" was that it would make it easier to make API changes in the server and push them into drivers. The kernel benefits from the ability to make internal API changes quickly; X could also make use of this flexibility. Being able to effect API changes immediately would also enable the removal of a bunch of backward-compatibility code intended to make it easier to mix driver and server versions.

The down side, of course, is that life gets harder for developers maintaining out-of-tree drivers - though it must be said that not everybody saw that as a disadvantage. Perhaps a monolithic server will encourage more drivers to move into the X.Org repository. But there is an interesting twist: some drivers, like the Wacom input driver, are licensed under the GPL. X, of course, is under the MIT license; adding GPL-licensed code into the mix would raise some awkward questions. What that means, in reality, is that some drivers will remain outside of the X server repository regardless of what happens to the rest.

Alex Deucher made the claim that API changes in the X server have been decreasing in frequency for some time, so the ability to make them more easily may not be all that valuable. The movement of much of the driver code into the kernel may have caused a reduction in disruptive driver changes in the X.Org server. But it may also be that, as Keith Packard said: "We don't get ABI changes because they're nearly impossible to handle." If those changes could be made more easily, chances are that the server would see more of them. Dave Airlie noted that he has a scheme in the works to make major changes to the driver API, but that he does not see how it can be done with the current, modular model.

How merging the drivers would affect testing is not entirely clear. On the one hand, testers working with new drivers would be building a new server as well, improving testing of the whole system. On the other, testing just a new driver without moving to a new server as well would become harder with the effect that some users are likely to just not bother. So the amount of driver testing could decrease. Nobody really knows how that would settle out, though, without actually trying the experiment.

Distributors could end up working harder to backport drivers to older servers, but the level of concern expressed by distributors in this discussion has been relatively low. As Ubuntu maintainer Bryce Harrington put it: "I favor just doing whatever the upstream developers feel is best for their own needs."

A different concern expressed by driver developers has to do with the core X.Org development process. The rules say that all patches must be reviewed before they can be merged into the master branch. Like all other projects, X.Org is short of reviewer time, so getting the requisite Reviewed-by tags for obscure changes can be a long and frustrating process. Driver code is typically understood by - and reviewed by - fewer developers than core code; that suggests that making changes to drivers in a monolithic server could be hard. The project might have to make some process changes in response; perhaps, as is the case in the kernel, the bar for driver changes could be set a little lower than for changes to the core code.

From your editor's reading of the discussion, it seems that there is a stronger sentiment in favor of making this change than there is against it. Those in favor see a way of making the development process more efficient and more closely integrating all the pieces of the X server. Those who have expressed opposition are mostly concerned about peripheral issues: licensing, review process, etc. Even the developer who is arguably the strongest opponent of the change - Luc Verhaegen - has argued that the real concerns are elsewhere. A better "mindset" when it comes to the design of the core API, he said, would have more far-ranging effects than the organization of the source tree.

As of this writing, no decision has been made public. It is not even 100% clear how such a decision can be made in the X.Org environment, which lacks a dictator (benevolent or otherwise) with the power to impose or block a change. Any project wanting to be successful in the long term must occasionally examine and tweak its institutions and processes. X.Org has already achieved the "long term," but not without some significant changes on the way. Relative to those changes, a decision to pull the drivers back in - or not to do so - seems relatively insignificant. The project, its processes, and its code have all improved considerably over the course of the last six years or so; that trend seems likely to continue into the future either way.

---

(Log in to post comments)