LCA: Updates on the X Window System

In its early days, X would normally be run on some sort of Unix workstation. The display hardware in use in those days was not normally expected to change while X was running - or over the life of the system in general. One connected The Monitor to The Adapter and things stayed that way forevermore. So the X protocol was set up to enumerate all of the available screens whenever an application made its connection. There was no way to add more screens on the fly or change their geometry, and there was no way to move windows from one screen to another. Fixing this was a hard problem.

As graphics hardware has become more powerful and flexible, a number of extensions have been developed in an attempt to provide proper support in X. The Xinerama extension uses a clever technique: merging all of the monitors into a single, large, virtual screen. Applications can then move between monitors, because they think they are just moving around on the same screen. The XFree86 VidModeExtension tried to address hardware changes by allowing the video modes to be changed on the fly. Then along came the first version of the Resize and Rotate (RandR) extension, which tried to improve the handling of mode changes and implement rotation - especially useful on handheld devices, where the screen can be used in both landscape and portrait orientations. RandR 1.0 was limited by a policy (imposed by the XFree86 maintainers) that the driver API could not be changed; as a result it was nowhere near as flexible as its developers would have liked.

All of this came together into "a kludge tower of extensions" which was guaranteed to fall down, sooner or later.

Since then, the X Window System has come under new management and the need for display flexibility has continued to grow. Enter RandR 1.2, soon to come to an X server near you. The new RandR release comes with the intention of being able to fully express (and use) the capabilities of the hardware. All configuration options will be brought back together into a single file, and they will all be adjustable at run time. Much of the driver-specific code has been moved back into the core, allowing all hardware to be configured in the same way. This was a much-needed change; according to Keith there are currently five independent Xinerama implementations in the X server.

RandR 1.2 uses a combination of new and old concepts. A "screen" retains its current meaning, and the one big screen is still present. Each screen, however, can work with one or more "CRT controllers," (CRTCs) each of which grabs a rectangular portion of the big screen and sends it to a monitor (highly unlikely to actually be a CRT anymore). Each CRTC, in turn, has one or more outputs which connect to physical devices.

The flexibility of this approach was easily demonstrated on Keith's shiny little laptop. The hardware is able to implement a 2K pixel square screen, which is then scanned by three different CRTCs: the built-in display, the video output, and the (unconnected) TV output. By default, they all look at the same portion of the screen, but, with a little command line magic, that can be changed. So Keith's laptop can display an entirely different set of windows out of each CRTC; the video output can send his talk slides to the projector while the laptop screen shows something else. The display areas can overlap if desired.

If a new monitor is plugged into the system, the RandR code will detect the event and react accordingly. The new output will be turned on and given screen space according to whatever policy is in effect. If need be, the user's desktop area will be expanded to cover a wider display. Similar things happen if a monitor is removed. It all Just Works.

While he was at it, Keith extended RandR to cover some other useful hardware capabilities. These include the ability to configure the gamma lookup table, allowing for on-the-fly contrast and brightness adjustments. Applications can get the monitor's EDID identification data, should they be interested, and parameters like the brightness of the backlight can be tweaked.

The current status is that the protocol and device-independent work are done. The Intel driver works now, and the Radeon driver is "nearly usable." This code is getting ready for people to use. When most people will actually use this code depends on the release schedule, however. At a separate talk (in the middle of the Debian miniconf) Keith covered what's coming up from the X.org project.

Coming soon is the X server 1.2 release. This one looks mostly like a maintenance release; Keith says that a lot of Coverity-found bugs have been fixed. Things have been cleaned up to the point that this release has 40,000 fewer lines of code - but more functionality. Keith noted that the policy of splitting the X drivers from the core server has not worked as well as they would have liked. It adds a whole set of API compatibility issues between the two, making it hard to develop and release improved versions of the server. Keith now thinks that the Linux kernel developers got it right by keeping drivers inside the kernel.

LibX11 1.1.1 is coming soon. The big change there is that the new XCB interface is being used underneath the old Xlib API, making it easy to migrate applications in an incremental manner.

Later on we can expect release 1.2.1 of the X server. This release will include an EXA acceleration implementation "that actually works." The RandR 1.2 code described above will also make its appearance here. Further ahead, the 1.3 release (to be part of a general X.org 7.3 release) will include significant ABI changes. A lot of the "PCI munging" is coming out of the drivers. Yes, he said, this will mess up the proprietary NVidia and ATI drivers. There will also be better support for hotplugging of input devices.

There is a Mesa 6.5.2 release coming with OpenGL 2.0 API support. It also has a new memory manager which can work with the memory management unit found in modern graphics cards; it can do things like map arbitrary regions of host memory into the adapter's address space. Among other things, this means that off-screen objects can be made writable, which will be a big performance win.

On the Intel driver front, the mode setting code has been much improved in recent times. Not surprisingly (considering that Keith works for Intel these days), this driver is the first to have full RandR 1.2 support. All outputs are fully supported, and EXA is as well. Intel has set a goal of having drivers available for new chipsets on the day those chipsets are launched. When asked if Intel planned to start selling discrete adapters, he became very silent, however.

Looking further ahead, the X developers would like to move video card mode setting into the kernel. There are a lot of reasons for doing this, starting with simple robustness. It would also enable better suspend and resume support, and better handling of panics: if the system goes into an oops, an in-kernel mode-setting routine can switch back to a text mode, allowing the oops text to actually be read. There is a lot of interest in supporting multiple, simultaneous X sessions on the same screen without using Linux virtual terminals; the goal here is to enable fast switching between user accounts. And there is interest in H.264 acceleration, facilitating the display of important things like HDTV. It seems that even contemporary CPUs can have trouble keeping up with HDTV streams.

Overall, Keith painted a picture of a revitalized X project which is truly beginning to hit its stride. A lot of work is being done toward the goals of fully supporting current hardware and providing the foundation for the creation of the best desktop available anywhere. One cannot help but look forward to where things will go from here.