During one of my recent visits to Chez Dirk, I got to see Linux’s VESA framebuffer console, something I’d previously encountered only in the context of the Gentoo installer, running on a regular system, and I found myself liking what I saw. The higher resolution is gentle on the eyes, and having a viewport of more than 80 columns by 25 lines makes the text-mode experience a lot easier to stomach.
It also happens that I’m in the last throes of yielding to the inevitable, and replacing my 19″ CRT with a 20″ flat-panel: the thought of seeing the VGA text mode, at 640×480, interpolated up to the 1600×1200 native to the monitor is enough to make my eyes hurt in anticipation.
So I spent some time last weekend trying to get vesafb working on one of my boxen as a proof-of-concept. In the end, I succeeded, but… Jeebus. The process highlighted everything that can be other-than-fun about the Linux experience. While it was not quite enough to propel me into the rarefied stratosphere of bitterness currently home to Jamie (“Fuck the skull of ALSA“) Zawinski, it was definitely irksome. Pieces of canonical reference material on the subject were at least one major stable kernel version out of date; others seemed flat-out at odds with reality. There was a bit there where I found myself muttering “VESA: it’s everywhere you can’t quite get to.” I’m better now.
In the deluded but psychologically vital belief that this will somehow help the next poor schmuck down the pike, here’s what I learned in the process of getting vesafb working on a system running Linux kernel 2.6:
- In order to even be presented the VESA VGA framebuffer option, you’ve got to build framebuffer support into the kernel. Building it as module won’t do: vesafb is a builtin-only option, so if its parent is modularized, it will be silently hidden from you. Navigate your way into Device drivers -> Graphics support, in the kernel configurator, and enable (with ‘y’, not ‘m’) “Support for frame buffer devices” and “VESA VGA graphics support”. Then dig down another level, into Console display driver support, and enable both “Video mode selection support” and “Framebuffer Console support”. (Again, modules are an inadvisable selection here, given that all of this stuff runs near the very beginning of the boot process, before even the loading of any hypothetical initrd.)
- Several of the docs indicate that once you’ve built the framebuffer into your kernel, you can add the option vga=ask to your kernel invocation in LILO or GRUB, reboot, and then enter the number of a graphical mode at the prompt. As far as I can tell, this is a big stinkin’ lie. Let me emphasize that. Big! And stinky! While it’s true that you can specify an assortment of text modes at that prompt, anything that would require a switch to framebuffer mode gets rejected out of hand as invalid. I’m not sure why that is. Casual perusal of vesafb.c suggests that the switch from text to graphics mode must happen while the processor’s still in real mode; presumably by the time the kernel is prompting interactively, we’re already in protected mode, and it’s too late.
- You will find, in the Framebuffer HOWTO and various other bits of documentation, a table listing the allegedly-canonical VESA mode numbers. This table, based on the VESA BIOS Extensions 2.0 specification, may or may not correspond to your hardware’s capabilities, especially if the latter’s compatible with VBE 3.0. The best way to find out what your card can actually do is to boot into GRUB, call up a command prompt, and invoke the vbeprobe command, which will spit out a list of mode numers, along with their associated resolutions and color depths. (If’ you’re not running GRUB, I’m very sorry for you. Consider upgrading at your earliest convenience. Seriously.)
-
Armed with a mode number emitted by vbeprobe, and a little bit of extra arcana from the Framebuffer HOWTO and its ilk, you are now almost ready to get down to business. Add 200 hexadecimal to your desired mode number, convert the result to decimal, and use that value to as the parameter to the vga= argument your bootloader passes to the kernel. (You might be able to get away with skipping the hex-to-decimal conversion, but this varies by bootloader flavor and version; if you’re not in a violently-disinclined-to-fuck-around frame of mind by this point in the process, you haven’t been playing long or hard enough.)
Here’s a table of values that have worked for me. You are strongly encouraged to determine your own. No guarantee is expressed or implied, not responsible for items lost or stolen, etcetera, etcetera. That having been said, the first of these should be safe enough, since it’s what the Gentoo installer defaults to.
Decimal value Mode 791 1024×768, 16 bpp 792 1024×768, 32 bpp 794 1280×1024, 16 bpp 838 1600×1200, 16 bpp
With all this done, you should be able to boot into a high-resolution framebuffer console.
This isn’t needed for the proof-of-concept boot, but you will likely want to pass a few extra options to the vesafb driver once you have things up and running. vesafb tends to be CPU-intensive, since it involves a lot of unassisted memory movement. Compiling support for Memory Type Range Registers (MTRRs) into your kernel, and telling vesafb to use that support, will help mitigate the hit. Back in the kernel configurator, under Processor type and features, make sure that “MTRR (Memory Type Range Register) support” is enabled. Then add video=vesafb:mtrr to your set of bootloader kernel arguments. Actually, depending upon your particular card’s degree of brain damage, you will probably also want to request one of the video-memory-based scrolling modes, either ypan or ywrap. See Documentation/fb/vesafb.txt for details.
To re-summarize the required kernel options, here they are in their raw form, the one native to .config (or /proc/config, if you’re reading them out of a suitably-configured live kernel):
CONFIG_MTRR=y CONFIG_FB=y CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y CONFIG_FRAMEBUFFER_CONSOLE=y
Enjoy. If the preceding text either helps you, or conspicuously fails to help you, in getting vesafb mode working on your system, I’d be interested in hearing about it.