"Linux Gazette...making Linux just a little more fun!"

The long-awaited new stable version 2.2 of the Linux kernel is on the verge of release as the new year begins; a great variety of new features and drivers will be included. One of the new features is the option to use a new device type for the virtual consoles, the frame buffer device (/dev/fb[0-7].) This new device type isn't really essential for the many Linux users running Intel machines, but those people using Alpha, Sparc, PPC, or any of the other platforms supported by Linux should benefit, as the idea behind the frame buffer console is to provide a hardware-independent console device.

Geert Uytterhoeven, a Belgian programmer and one of the primary frame buffer developers, wrote a succinct introduction to one of the frame buffer documents included with the kernel source:

The frame buffer device provides an abstraction for the graphics hardware. It represents the frame buffer of some video hardware and allows application software to access the graphics hardware through a well-defined interface, so the software doesn't need to know anything about the low-level (hardware register) stuff.

Users of Intel machines already have methods available to vary the size of the text console screen, such as the video=ask Lilo parameter and the SVGATextMode utility. I've used SVGATextMode for quite some time to set the console text to a 116x34 resolution. It works fine, but while configuring recent 2.2 beta kernels with menuconfig I couldn't help but be intrigued by the choices offered in the Console Drivers sub-screen. My video card these days is a Matrox Mystique, and when I saw a new frame buffer driver for Matrox cards and another option for Mystique support I just had to give it a try.

The first time I tried a kernel with Matrox frame buffer support I could see that the card was detected (as the boot messages scrolled by) and the penguin logo's appearance at the upper right corner of the screen seemed to indicate that at least part of this compiled-in feature was working, but the console was the same old 80x25 default. Back to the documentation, where I learned that a utility called fbset would be helpful. This small program (written by Geert Uytterhoeven and Roman Zippel) is used to change or query the current frame buffer mode. Even more important, the installation of fbset creates the special device files /dev/fb[0-7] which are needed for frame buffer functionality. The fbset archive can be found at this FTP site.

Another document found in the fb subdirectory of the kernel source's Documentation directory is called matroxfb.txt. Written by Petr Vandrovec, the Czech developer responsible for the Matrox frame buffer drivers, this document is a great help in setting up workable frame buffer modes. Another, more generic document called vesafb.txt can be consulted when setting up modes for other VESA-2.0 compliant video cards.

There are two ways to tell the kernel which frame buffer mode to use. While experimenting, setting the mode specification at the Lilo prompt is a quick way to try a mode out. Let's say that your main dependable kernel is the first one in the /etc/lilo.conf file, and the frame buffer kernel is the second and is named bzImage-2.2. Your computer boots, the LILO prompt appears, and you press the shift key. Here is an example of a mode being set:

LILO bzImage-2.2 video=matrox:vesa:0x188

If the mode is acceptable, the console screen will switch to the new mode (in this case, 960x720) soon after the boot messages begin to scroll by. The relevant boot messages will look something like this:

matroxfb: Matrox Mystique (PCI) detected 
matroxfb: 960x720x8bpp (virtual: 960x4364) 
matroxfb: framebuffer at 0xE0000000, mapped to 0xc4807000, size 4194304 
Console: switching to colour frame buffer device 120x45 
fb0: MATROX VGA frame buffer device 

If you like the mode, a variation of the above Lilo command can be inserted directly into the /etc/lilo.conf file; the line should look something like this:

append="video=matrox:vesa:392"

The quotes are essential, and notice that the hex number 0x188 has been converted to its decimal equivalent 392, since Lilo can't understand hex numbers in the lilo.conf file.

Once the frame buffer kernel is booted the fbset utility can be used to switch to other modes. Mode specifications can be derived from X modes, but not wanting to spend hours fooling around with this I took the easy way out. Before I edited the lilo.conf file so that the mode would be set automatically when booting, I tried several different hex numbers at the Lilo prompt. After booting each one I ran fbset without any arguments. When run this way fbset outputs to the screen the current mode specs in a format usable in the (initially nonexistent) config file /etc/fb.modes. Here's a sample of the output:

kbdmode "name"
    # D: 56.542 MHz, H: 45.598 kHz, V: 59.998 Hz
    geometry 960 720 960 4364 8
    timings 17686 144 24 28 8 112 4
endmode

Several of these mode specs can be pasted into a new /etc/fb.modes file, substituting different mnemonic names for the "name" in the pasted output. One useful mode to include is a basic, non-color text mode, either by trying one of the text modes described in the documentation or simply by running fbset -depth 0. SVGAlib console graphics programs won't run properly in frame buffer consoles with higher color-depths. Once a fb.modes file has been created the frame buffer mode can be changed by running the command fbset name, where "name" is one of the mode names in the file.

Naturally, the big question many readers will have is "Will X Windows run when started from a frame buffer console?". The answer is "It depends.". Some combinations of X servers and video cards are known to have problems, especially when switching back and forth from X to a virtual console. This can be a problem with SVGATextMode as well. The XFree86 3.3.3 SVGA server I've been using with my Matrox card has worked well with the frame-buffer consoles. Your mileage may vary.

There is a special server available in source form; it's called XF68_FBDev and it's included in the XFree86 3.2 (and later) sources. Binaries aren't available, and the server is unaccelerated and would mainly be of interest to those running Linux on non-standard hardware such as PPC.

The majority of Linux users probably won't be using the frame buffer kernel options any time soon. It has advantages with some hardware, but it takes time to figure out and use effectively, and the benefits are nice for console users but won't be of much use to those who spend most of their time in X Windows. I think that the reason it will be a part of the next stable kernel release is that frame buffer devices aren't Intel-specific, as is much of the current console code. It's likely that the much-anticipated release of XFree86 4.0 (possibly this year) will include more frame buffer compatibility in its server modules, such as seems to exist now in the SVGA server.