Keith Packard took time out of the Desktop Developers' Conference to talk
with the kernel hackers about video drivers. He described the current
situation as a nightmare, mostly as a result of the fact that video
hardware is currently managed from three different places:
- The kernel's framebuffer layer handles things like mode selection,
and is in charge when the console is in text mode.
- If DRI is being used, it feels that it is in charge of the hardware.
It deals with interrupts, DMA operations, and memory management.
- The X server also feels that it is in charge. It, too, does mode
selection; the server also gets involved in the suspend and resume
The end result is a mess where things often do not work right, the video
hardware is not used to its full capability, and confusion abounds.
According to Keith, developers have not yet realized what they are dealing
with. A modern video card can carry 512MB of memory, a processor which is
faster than the system's CPU, and a high-speed interconnect between the
two. It is, in other words, a high-performance computing system in its own right, and it
needs an operating system to run it. Somebody needs to schedule the
processor, and it needs a suitably smart memory manager. Users of those
512MB of onboard memory need to tracked, and some (but probably far less than
half) of that memory needs to be saved when the system is suspended.
There is also the small issue of what happens when the X server tries to
map all 512MB of memory into user space. The Linux kernel currently does
not handle that well, and, on 32-bit systems at least, probably never will.
Video mode selection is a big problem. Video cards can be incredibly
complex devices, requiring a lengthy setup process. The code to set video
modes is, often, far too large to be rationally included in the kernel. So
it needs to happen in user space. But that is problematic too; somebody
needs to set up the console at boot time. That task cannot be handled in
Just as importantly, the kernel needs to be able to get text out to the
display when something goes very wrong. Currently, if the system panics
while the console is in graphics mode, the only user-visible sign is that
everything just stops. Most users are uninclined to do things like setting
up serial consoles, so no useful bug reports get generated. It would be
far better if the system could, somehow, put an oops message where the user
will see it. Options include somehow forcing the card back into text mode
(which can be problematic if it is in the middle of an operation), or
somehow painting the message onto the display graphically.
The general consensus is that these problems can be solved, it will just
require a fair amount of work. Keith is determined to rework the X server
and bring modern graphics capabilities to Linux; with luck, the 2.7 kernel
series will provide the support he needs to get that job done.
>> Next: Desktop performance.
to post comments)