Day 2: Tutorials: XFree86 4.0

Then, the first known accelerated cards came out: 8514, Mach8/32, S3 and the XFree86 code just wasn't designed for those architectures, so new XFree86 servers came out, the way we know XFree86 3.x today. Dirk says while it seemingly made sense back then, it would have been better to rewrite the XFree86 code to support those new architectures instead of forking the server.
A nice thing however, is that XFree86 has always been OS independent and explains why XFree86 can be ported to new architectures like QNX so easily.

Dirk then explained how they had to create a organization to talk to the X consortium in order to be officially recognized and be able to work with the specs, but it didn't work in time for Xfree86 3.0 although that was fixed for version 3.1.
Another problem back then in the 3.2 days was that it was really difficult to get programming information from card vendors. Some will remember how it was common to buy a video card that wasn't supported by XFree86.
For 3.3, released in June 97, tons of new drivers were added, thanks to the several big card vendors (Diamond, Matrox to name only those two) who changed their policies and agreed to release their specs. Another notable improvement is XAA, the X Acceleration Architecture.

Writing a driver for XFree86 4.0 more or less requires a rewrite, but it's well worth it because all the legacy stuff, that made sense for an ET4000 but is ridiculous for today's cards, can be thrown away. The people who've done rewrites have reported that it was not only easy, but that it also provided very noticeable speed increases (up to 20 times).

The upcoming plans are snapshots of 3.9.x every four to six weeks, have a reasonable configuration tool, and realistically there will still be a few 3.3.x releases since the change to 4.0 will be rather big. Another issue is how many old cards to support knowing that it will delay the release (some people use 5 year old cards that are impossible to find nowadays).

As far as features go: X11R6.4 Security and bug fixes Better colormap handling Multihead/Xinerama Better support of pointer devices Smaller memory footprint Some clients are broken in 24bpp mode, like netscape, so XFree86 4.0 will let you choose between 24bpp and 32bpp pixmaps. Other applications are so broken that they only work in pseudocolor mode (8 bpp), so overlays lets you give those applications an 8bpp setup while the server is really running in a higher bpp mode. Truetype font support (both FreeType and X-TrueType, which work differently but seem to offer different features for Asian character sets) DGA 2.0 (with a commitment from the VMware folks to use it, as they currently use DGA 1.1, which they extended themselves (open sourced)). OpenGL/Mesa support with the DRI effort from Precision Insight, Suse will merge its unfinished 3D efforts with PI, so that we don't have fragmentation. You also have the open sourced GLX donated by SGI XFree86 4.0 will provide default VESA modelines up to the max frequencies that your monitor can take. No need to include the default modelines anymore. With multihead support, you need to be able to address individual cards and order them, so you can address them with the BusId keyword. The other cool thing is that multihead can work with sets of non matching cards. A lot of code was moved to modules, which are OS independant. The driver modules and feature modules, like font rendering, are compiled once, and will run on any ia32 OS that supports XFree, including OS/2. This also means that there is now a unique server binary and it is the only OS dependent part. As much probing as possible, which is facilitated by the PCI id info and plug and play monitors. However, some vendors don't always put useful info in the PCI id, and some monitors report capabilities that are way beyond what they can do. scanpci is now built-in XFree86. For the 4.0 release, the great new configuration tool will most likely not be ready yet, but it will come later. In the meantime, there will be a tool equivalent to xf86config. More command line options to choose screen sections so that you can choose your full resolution without needing root access to edit the configuration file back and forth Better support for framebuffer devices, including shadowFB which lets you read back from write only dumb framebuffers. For developers, there is a full skeleton driver with lots of comments and documentation, as well as a list of pitfalls.

Jim Gettys, one of the creators of X, attended Dirk's tutorial

After finishing his slides, which you can find in the middle of the picture library, Dirk gave a demo of Xinerama (you can see in the picture below that the netscape window is straddling between the two screens). You can also find other pictures of his demo in the middle of the picture library

Picture library

Back to Main Page

Next page

99/08/12 (00:54): Version 1.0