Linux 2.2 and the Frame-Buffer Console

Under the hood, Linux 2.2's text mode was designed to be a more modular system with defined interfaces and less of a dependency on VGA hardware internals. The casual observer will not notice either of these improvements. This is the same text mode we have come to love. However, improvements were made to allow better serial consoles for machines without video hardware and to allow for the turning off of virtual consoles, but these features are not expressly part of the text-mode driver.

Frame-buffer devices are the biggest new video feature of Linux 2.2 for i386. Unlike earlier versions of Linux, it is possible through the frame-buffer device to access the video hardware of a machine directly and in a device-independent manner. All the basic graphics primitives are supported, although acceleration is not generally supported at this time. Exactly how accelerated architectures will fit in is still a matter of debate. Some point to user-mode programs and libraries (such as GGI); others believe the best location for at least some types of acceleration is in the kernel. Note that, in contrast to the text-mode driver, there is no character cell display—it is handled elsewhere. SVGAlib applications and, to a lesser extent, X applications can both obtain approximately the same level of control over video hardware, but they are usually less portable and more of a security risk.

In addition to those features, it is now possible to access the frame-buffer devices through the use of device nodes, just like any other device. As an example, these device nodes, /dev/fd*, can be used to get a screen capture simply by doing a standard copy command.

Above the frame buffer is the frame-buffer console (fbcon). This is where the standard vt100+ terminal emulation is implemented. In fact, the emulation is so good that the end user may not even notice the system is in graphical mode. At this level, the kernel has a much larger control over fonts and other features formerly provided through utilities such as SVGATextMode.

Now, all of these features are great, but the major feature that will probably be the reason most Linux users try out the frame-buffer driver is the boot logo. Yes, now you can finally have a cute little picture of Tux carrying a beer whenever you turn on your computer.

Not nearly as many security problems exist under the new system as under the old. Programmers who write graphical applications do not need to be as careful as their legacy counterparts, since they are protected by the user-level security of the kernel. System administrators will also have fewer “setuid root” applications to track, making their security audits easier. In contrast, there will be more code in the kernel that could go awry, and kernel developers will need to keep the new video subsystem as bug-free as the rest of the Linux kernel.

My favorite feature of the new kernel subsystem, if it were to go into wide use, can be summed up in two words: cross-platform compatibility. Simply put, applications written to use the frame buffer will be immediately portable to all Linux platforms. This is in direct contrast to the current SVGALib system which does have some cross-platform compatibility—but only on systems with VGA-like hardware. This will, in theory, make compiling any graphical application on multiple Linux architectures as easy as compiling an application with ncurses is today.

Bear in mind, however, that this argument does not apply to X applications which are already cross-platform. Rather, this level of compatibility would help with X at a somewhat lower level.

Another advantage of having a single level of abstraction for video hardware at the kernel level is with X servers. Unlike older X servers which needed to concentrate on the specific features of a class of video cards, frame-buffer-aware ones can concentrate solely on the networking and other X aspects while allowing the kernel to handle video specifics. In my perfect world, that would allow developers more time to look at X issues rather than video issues. If a developer was still interested in developing video code, he or she could always look to the kernel for something to do.

The X server for the frame buffer is already available as Xfree86-FBDev and has shipped with some distributions.