LWN.net Weekly Edition for September 1, 2005

Linux and desktop graphics

There is a lot to be said for the X window system. It is, after all, one of the oldest and most successful free software development projects in existence. X helped to pioneer many concepts, including the idea of a graphical display as a network service and the absolute separation of graphical mechanism and policy. Long before Linux began to make proprietary Unix vendors worry, X was pushing aside proprietary desktop implementations.

X has a problem, however: it is very much a two-dimensional system in a three-dimensional world. It was designed around dumb frame buffers, but is now expected to run on graphical adaptors which, in terms of processor performance, far outclass the central processor they serve. As a result, X tends to make poor use of contemporary video hardware; it restricts itself to the hardware's two-dimensional processor (a nearly vestigial afterthought bolted onto the real hardware) and cannot make use of many of the capabilities provided by the 3D processor. X is, essentially, using a legacy interface which is poorly supported now, and which may go away in the near future.

To remain viable, and to help free operating systems develop the best desktop experience possible, X must grow into the current crop of hardware. The X developers have understood this for some time, and have been working in that direction. Events from this week demonstrate, however, that there is a lack of consensus on what needs to be done, and when.

The person driving the debate is Jon Smirl, an active graphics programmer. Frustrations with the X development process have led Jon to write and post a document called The State of Linux Graphics. Regardless of how one feels about Jon's opinions, the document is worth a read; it is a comprehensive overview of the problem and the current body of low-level graphical software. If you've ever wondered what all those acronyms (XAA, EXA, DRI, ...) mean, this document will clarify a number of things.

X developers seem to agree that X needs to make a switch from 2D to 3D hardware. There is less consensus on how the 3D hardware should be made available to user space. One approach is to make OpenGL be the API for next-generation graphics. This interface is relatively well designed, is open, and already has a certain level of support in free software. It is a high-level interface which allows an application to take advantage of the hardware's capabilities. OpenGL supporters see the X of the future as being a sort of management layer around the OpenGL interface.

Jon Smirl is one of those supporters. He has been working on Xegl, a version of the X server which makes the OpenGL interface available. A few weeks ago, however, Jon announced an end to his Xegl work. In his opinion, Xegl is not going to reach a usable state anytime soon, so it is not worth working on.

The problem, it seems, is that Xegl lacks developers and is progressing too slowly. According to Jon, a big part of the problem is that development work in the X community has been spread in too many directions. He is, in particular, critical of an effort called EXA, which is working to integrate drivers using the 3D hardware into the existing X API. EXA may have the effect of extending the life of the current X server, but it does relatively little to make the hardware's capabilities available to applications. As a result, the X server will be faster on supported hardware, but it will still be a 2D server. Says Jon:

Jon seems to believe that the main thing EXA will accomplish is to push back the date when Xegl will show up as the real solution to the problem. He claims that Linux is already far behind the proprietary platforms in providing a desktop which can take advantage of contemporary hardware, and has little patience for developments which threaten to widen that gap. So Jon has stopped development work on Xegl, and is working for process change instead. His conclusion states:

Not all X developers are entirely supportive of Jon's position. The administrator of freedesktop.org, where Jon's document is hosted, posted a dismissive response and promptly shut down Jon's account, making the document unavailable. It has since been restored, but that action (ostensibly taken for other reasons) added an unpleasant note to the debate.

Some developers seem to agree that the OpenGL approach is the right one for the long term, but they never believed that this solution could be implemented in the near future. It is, after all, a complex project. For these developers, EXA makes sense as a short term, relatively easy solution to make X functional on current hardware.

Others seem to disagree with the transition to OpenGL altogether. The current X Render extension makes a number of capabilities available to applications, and it could be extended where needed. Render is seen as a friendlier API for 2D applications than OpenGL. Not moving to OpenGL would mean less disruption for applications and would avoid impacting X performance on older hardware without 3D acceleration.

The discussion, as of this writing, has not reached much in the way of new conclusions. The Xorg project lacks a dictator, and will thus be hard put to pick a direction and expect that the developers will simply follow. What does seem clear, however, is that the developers are determined to bring X forward to where it is, once again, a leading-edge graphical platform. They will probably get there, one way or another.

Comments (30 posted)

The StorageTek DMCA decision

Last year, StorageTek (soon to be a subsidiary of Sun) brought a suit against Custom Hardware Engineering, alleging copyright and DMCA violations. CHE is a third-party maintenance vendor which was offering maintenance services for StorageTek's tape libraries. To carry out that maintenance, CHE built a gadget which would intercept diagnostic messages sent within the library; CHE also had to bypass StorageTek's "GetKey" system which protected access to those messages. StorageTek claimed that running the maintenance code (which generates the diagnostic messages) was a copyright violation, and that bypassing GetKey went against the DMCA's anticircumvention measures. A U.S. district court agreed, and issued an injunction shutting CHE's maintenance service (for these libraries) down.

CHE appealed the injunction, and an appeals court has now produced a ruling [PDF] reversing the injunction. In doing so, the appeals court has placed some limits, however small, on the application of the DMCA.

This case matters. It is not hard to imagine similar situations which could affect the free software community. If StorageTek's internal diagnostic streams are privileged, many other hardware communication paths may be as well. Consider a closed network adaptor, for which a free, reverse-engineered driver exists. The vendor could claim that the communications between the proprietary driver and the firmware on the card serve as an access to that (copyrighted) firmware, and that the (undocumented, complex) interface to the card is a technical measure preventing unauthorized access. By this reasoning, a free driver would be a DMCA violation. As DRM systems work their way into (what used to be) general-purpose computers, this sort of issue will come up in that context as well.

When viewed in this context, the StorageTek decision, while welcome, does not give much relief. It is a narrow decision which does little to return control of hardware to those who have purchased (and believe that they own) it.

The core of the appeals court decision is that CHE's activities did not, in fact, constitute copyright infringement. The infringement argued by StorageTek took the form of CHE loading StorageTek's maintenance code into the library's processor by means of rebooting the machine. This allegedly infringing activity is the same thing that happens when the owner of the machine turns it on. This "copying" of the software into RAM might well have been a copyright infringement, except that the copyright law contains an explicit exception for third-party maintenance providers. Even in this case, CHE might not have been in the clear, however; the company prevailed in the end because StorageTek had never made a clear separation between its operational and maintenance programs. The whole mess is loaded when the system boots, so the appeals court decided that it was all necessary to operate the library.

In other words, if StorageTek had been more careful to keep its maintenance software separate, and to not load it automatically when the system boots, it might have gotten through this appeal. The court also notes that StorageTek could have written its software license agreement to forbid third parties (such as CHE) from turning on the machine at all - but didn't.

Once that decision was reached, the court had little trouble with the DMCA claim. The DMCA, the court decided, is a copyright law. To that end, the anti-circumvention provision does not stand on its own, but is tied to the underlying copyright regime. That limits how this provision can be read:

In theory, this interpretation means that circumvention, itself, is not a crime. It is only when that circumvention is part of a violation of copyright that the DMCA comes in to play. Unfortunately, anything which is said to "facilitate" copyright infringement will fall on the wrong side of that line, so there is nothing good in this ruling for DeCSS (for example).

So, in the end, this ruling does little to enable us "consumers" to keep control over the devices that we believe we own. It is more likely to serve as a checklist for companies like StorageTek in the future: their systems are likely to be designed to avoid the pitfalls encountered by StorageTek in this case. This ruling has, mainly, increased the number of lawyers that hardware manufacturers must apply to achieve their aftermarket goals.

Whenever one buys a device containing proprietary software, one must accept that said device may serve somebody else's interests. That is in the nature of proprietary software, but that nature is made worse by current copyright law, which sees the act of paging software into RAM to execute it as an act of copying which may be controlled by the copyright owner. The ruling in the StorageTek case has drawn some boundaries on how far vendors can use copyright law to assert control over hardware they have sold, but the situation, fundamentally, has not changed.

Comments (14 posted)

Writers wanted

For the last couple of years, Joe 'Zonker' Brockmeier's articles have been a regular feature here at LWN. We are thus sad to announce that this week's article (on the Distributions Page) will be Zonker's last for LWN. Zonker has gotten a real job, and will no longer be available to write free-lance articles. We offer Zonker our thanks for many great articles, and wish him well at his new place of employment.

LWN is always looking for good writers, but, for obvious reasons, our level of interest has just gone up. We are, in particular, interested in talking to authors who have top-notch writing skills, are good at meeting deadlines, can generate ideas for articles, are not afraid of fussy editors, and who are not afraid of some of the most demanding readers around. We do pay for articles, though we must say that working for LWN is not a way for anybody to get rich.

If you think you might be interested in writing for LWN, please start by taking at a look at our author guide. Then drop us a note at authors@lwn.net and we'll talk.

Comments (7 posted)