\n"; ?>
Interviews

XFree86 - A Glance Behind the Scenes

Jana Jaeger

Assuming you were not one of these hardcore Linux-purists who do their daily work just using the text console and nothing else, you should already have been confronted with X. Even when reading this text, your browser window or the output of Lynx that is displayed in your xterm make use of the X server routines which provide you with a convenient graphical interface. Dirk Hohndel, one of the XFree86 "fathers", vice president of the XFree86 Project Inc. organization, and, last but not least CTO of SuSE Linux AG kindly answered a few questions regarding some background information on XFree86.

Web Portal : Unlike most other open source projects, XFree86 is not under GPL. Which are the differences between GPL and the XFree86 licence? Why was it not GPLed? When considered retrospectively after nine years of XFree86, did this decision make sense?

Hohndel : The XFree86 license is similar to the MIT / X consortium's license for X Windows. The license essentially permits anyone to use the software without restrictions, as well as to modify and resell it. This is the crucial difference compared to GPL: with GPL, any derived work also must fall under GPL and thus must be freely available, including sources. This is explicitly not the case with the XFree86 license.

The historic reason for this license and for adopting it for XFree86 is perfectly clear. At MIT and the X consortium in particular, companies with commercial Unix versions have contributed to the development of the X Window system. Naturally, these companies wanted to base their commercial products on X sources without revealing their products' source code. Or, simply put, these companies wanted to establish a standard for which the sample implementation would merely serve as an easy launch point. Everybody would then be able to work based with this sample implementation without any substantial restrictions. (Of course, there are the usual disclaimers about "promised features" as well as advertisements stating the fact that this code is being used).

Naturally, as part of the "X community", the XFree86 project joined this license. In this context it is important to understand that X was, in fact, the first truly global and successful open source project, long before the GNU concept became more widely known. From our perspective, this license makes a lot of sense, because we also want to enable as many individuals and businesses as possible to use our code as a development and project basis, regardless of what kind of agreements these projects are licensed under. There are persistent claims that a license such as ours would automatically split the project and invite attempts to "take closed source", that is to say, attempts to use the open source project to create a closed source project offering various additional features, thus luring "customers" away from the open source project. In my opinion, such thinking demonstrates nothing but a lack of confidence in the advantages of the open source strategy. Nobody would gain a significant advantage by creating a closed source project, since doing so would only cut off the creator from continuing XFree86 developments and improvements.

Interestingly, what actually happened was the exact opposite of what was predicted. Due to our license, Metro Link, one of two commercial providers of X servers for PC Unix, modified its own product so that it is now based on XFree86. (In the process, the company also improved some technological aspects of XFree86). In other words, it turned out that the tendency was not to split up in different directions, but to unify on this basis of one source.

Now, after almost nine years of XFree86, the answer is crystal clear. This license for XFree86 makes total sense and it was, without a doubt, a good decision.

Web Portal : Is the X server limited in any aspect? Is there any kind of upper performance limit for the X server itself? Is a software as complex as the X server suited for the whole new market of embedded systems? On the other hand, is it powerful enough to face all this 3D stuff?

Hohndel : So many questions at once. Let me address them one at a time:

I certainly don't see any reason for, nor any point in the X or Xfree86 architecture that would point to an upper performance limit. Naturally, there's always the question of how much 2D performance is required by the individual working with X. (The answer, in 99% of the cases, is "less than is already available with inexpensive graphics cards today"). However, as far as 2D is concerned (and X clearly is a 2D protocol), I don't see any real limitations. Some more relevant questions relate to rendering models, or which options the X applications offer for the display of two-dimensional objects. The old X RasterOps model has certainly reached its limits. That is why we have introduced a new rendering model with the current XFree86 version. This model is based on image composition that updates X to keep pace with current technology without sacrificing compatibility with older applications.

Last week Troll Tech released the latest version of the Qt libraries based on this new rendering model, thereby enabling the use of anti-aliased fonts, i.e. character sets with smoother edges.

The question about the complexity of X is naturally justified and one that is being asked quite frequently. I believe that X offers incredible advantages compared to other current graphics infrastructures under consideration. Standardization, network transparency and comprehensive compatibility with existing applications are all factors that make X an ideal environment, including and especially for embedded systems. Moreover, a complete X server, including several character sets, easily runs in only 800kB of memory. tinyX is a good example of such a server. Naturally, X is already running on today's exhibition devices, such as, for example Compaq's iPAQ or IBM's famous Linux clock.

3D is another topic entirely, since X is a 2D infrastructure, as discussed above. 3D under Linux is generally referred to as OpenGL. The X server is involved here only if GLX is used to "tunnel" OpenGL through the X protocol so that OpenGL can also be used through the network (with certain performance drawbacks, of course) and whenever X must "make way" for the OpenGL rendering engine, since the graphics processor can run only one control instance at a time. In this context the direct rendering infrastructure (DRI) comes into play in connection with XFree86. The DRI ensures just this type of cooperation between the OpenGL drivers and the X server.

Accordingly, the quality and performance of the OpenGL implementation under XFree86 are once again only a question of the quality of the OpenGL drivers for the corresponding graphics hardware.

Web Portal : With the release of version 4.0, the world saw a whole new concept of XFree86. Now you have just one X server for all types of cards which is supplemented by the driver modules for each particular graphics card. Card manufacturers can now contribute their own driver modules. How did they respond to that? Do they cooperate and most importantly, how would you rate the quality of these manufacturer-provided modules?

Hohndel : It was a good idea, but it obviously took too long to finish XFree86 4.0. However, all good things to those who wait (or something to that effect) :-). Seriously, though, manufacturers quickly understood the principle, but initially there were significant differences in what they did about it. While some manufacturers were inspired to write open source drivers as modules, others preferred to market closed source drivers (some of them of dubious quality).

The whole issue, however, was overpowered by brutal competition in this sector, a process that many manufacturers did not survive. The remaining competitors had to continuously reposition themselves with respect to Linux and XFree86. By now, large manufacturers that are still market contenders have all introduced XFree86 modules or have invested in their development. This means that today there are drivers on the market for all commonly used cards. In my opinion this means that the strategy has proven itself as successful.

Web Portal : XFree86 4.0 is still a youngster. Did you notice any growing pains? Which were the problems and have they been resolved? How would you rate 4.0 vs. 3.3 from the performance point of view?

Hohndel : Growing pains ... , 4.0 was already approaching young adulthood by the time it was finally released ... still, a few problems remained here and there and it might have been better for us to have waited a little bit longer ... nonetheless, at some point we just had "to get it out".

In light of the fundamental changes from Version 3.0 to 4.0, 4.0 proved quite stable with surprisingly few problems. With commonly used chip sets, the performance of 4.0 was better than that of 3.3 from the outset. Also, the exactness of the drivers was inferior to 3.3 in only a very small number of exceptional cases. The real problem of 4.0 was that it still did not have enough drivers and that one or another of these drivers had stability problems. This problem has been largely corrected with Version 4.0.1. Version 4.0.2 then went on to fix a few small design problems and introduced the new rendering architecture as its most innovative feature. The bug list for 4.0.2 is unbelievably short for a project at this level of complexity.

Web Portal : Thank you for this interview.
\n"; ?>