Penguin logo. :o) Seriously, the major advantage of the framebuffer drives is that it presents a generic interface across all platforms. It was the case until late in the 2.1.x kernel development process that the Intel platform had console drivers completely different from the other console drivers for other platforms. With the introduction of 2.1.109 all this has changed for the better, and introduced more uniform handling of the console under the Intel platforms and also introduced true bitmapped graphical consoles bearing the Penguin logo on Intel for the first time, and allowed code to be shared across different platforms. Note that 2.0.x kernels do not support framebuffer devices, but it is possible someday someone will backport the code from the 2.1.x kernels to 2.0.x kernels. There is an exception to that rule in that the v0.9.x kernel port for m68k platforms does have the framebuffer device support included.
With the release of the 2.2.x kernel, framebuffer device support is very solid and stable. You should use the framebuffer device if your graphic card supports it, if you are using 2.2.x kernels. Older 2.0.x kernels does not support framebuffer devices, at least on the Intel platform.
There are some cool features of the framebuffer devices, in that you can give generic options to the kernel at bootup-time, including options specific to a particular framebuffer device. These are:
video=xxx:off- disable probing for a particular framebuffer device
video=map:octal-number- maps the virtual consoles (VCs) to framebuffer (FB) devices
video=map:01will map VC0 to FB0, VC1 to FB1, VC2 to FB0, VC3 to FB1..
video=map:0132will map VC0 to FB0, VC1 to FB1, VC2 to FB3, VC4 to FB2, VC5 to FB0..
Normally framebuffer devices are probed for in the order specified in the
kernel, but by specifying the
video=xxx option, you can add the
specific framebuffer device you want probed before the others specified in