Present - Programming - Radeon Framebuffer Device

Radeon Framebuffer Device

Table of Contents

Copyright

The text of this page is copyright © 2003-2004 C. Daelhousen and licensed under the Creative Commons Attribution/Share-Alike License. It may be freely used, modified, and published, provided it (and derivative works of it) retains attribution and remains under this license.

Introduction

This page explains configuration of the radeonfb framebuffer driver for the Linux 2.4 series of kernels. It is intended for intermediate to advanced users. For more information on video timings, framebuffers, and video hardware, search for the relevant HOWTOs.

Tired of 80x25 consoles? Have a flatpanel monitor that makes them look ugly? The framebuffer device may be just what you're looking for! Here's how to run the console in a sorta-text, sorta-graphics mode, using the radeonfb driver as an example.

Kernel Configuration

First, the kernel needs to be compiled with framebuffer support, which is as of 2.4.22 still experimental. Therefore, prompting for development and/or incomplete code/drivers must be enabled. Then, under "Console drivers", framebuffer support and at least a driver for the appropriate card is needed. It's fine to configure in multiple drivers; one is selected when booting the kernel. Compile them in; they will not work as desired as modules.

To play with fonts, choose "Select compiled-in fonts" and choose as desired. This is not strictly necessary, as normal VGA font loading still works. (I speak for PC/x86 systems; additional information on other architectures welcomed.)

Other options may or may not need set; YMMV. My system was fine with the defaults. Recompile and reboot the kernel. Keep a backup on hand, just in case.

Configuring the device

All of the framebuffers are subdrivers of video, and are configured by passing a video= option to the kernel at bootup. The exact driver must come first, followed by a colon, for instance video=radeon:. Some of the drivers have documentation in "/usr/src/linux/Documentation/fb"; reading them if available is highly recommended. The radeon driver currently (2.4.22) supports several options, separated by commas. Options listed below which are not marked with a version were present in 2.4.20 when I started using radeonfb.

Radeon OptionDescription
font:<any_fontname>Sets the fontname to be <any_fontname>. See below.
panel_yres:<number>Sets the height in pixels of the DFP-based monitor to <number>.
dfpForces the driver to believe that there is a DFP-based monitor attached to the DVI port.
crt(2.4.22+) Forces the driver to believe that there is a CRT monitor attached to the VGA port.
nolcd(2.4.22+) Forces the driver to believe that there is no LCD monitor. By my reading, this only affects PowerPC.
noaccelDisable acceleration. This is much slower and much more stable.
nomtrr(2.4.22+) Disable use of MTRRs by the driver. This is less drastic than noaccel.
mirror(2.4.22+) Send output to both the DVI and VGA ports.
<X_res>x<Y_res>-<depth>@<refresh>Set video mode. See below.

If given a panel_yres, the corresponding X resolution is selected off of a table.

Font parameter

Each particular font file under drivers/video, such as font_8x16.c, contains at the very end of it a struct fbcon_font_desc containing the actual name of the font as its second element. The fonts available depend on which were compiled into the kernel. Following is a list of font names as used by the font option in 2.4.22, with their descriptions from kernel configuration. (For brevity, the size of the font is not repeated.)

Font NameDescription
ProFont6x11Mac console*
VGA8x8VGA
VGA8x16VGA
Acorn8x8Acorn console
PEARL8x8Pearl (old m68k) console
SUN8x16Sparc console
SUN12x22Sparc console*

* Not supported by all drivers.

Mode parameter

The format of the video mode looks like it should be the same for all drivers using modedb. (Documentation/fb/modedb.txt has an outdated list of drivers that support it.) <X_res> and <Y_res> are the size of the screen in pixels. <depth> is the number of bits per pixel to use--8 for 256 colors, 16 for 65536 colors, and 24 or 32 for 16 million colors (dependent upon hardware). Finally, <refresh> is the desired refresh rate in Hz, because most modes support more than one. It must be chosen to be within the specifications of the monitor. Not all fields are required. The mode may also be "off" to disable the driver.

The database containing all timing information for each available mode is stored in "/usr/src/linux/drivers/video/modedb.c", in an array near the top. Each mode contains a comment stating what mode the timings translate into, such as /* 640x480 @ 85 Hz, 43.27 kHz hsync */. Remember to keep the hsync and refresh rate within the monitor's capabilities. Select an appropriate mode, and build the kernel option from it. For instance:

Kernel OptionDescription
video=radeon:offVGA video: 80x25 characters, text only
video=radeon:640x480640x480 pixels, using the first entry of this size in the database
video=radeon:640x480@85640x480 pixels at 85 Hz
video=radeon:1280x1024@61,dfp1280x1024 pixels, 61 Hz refresh rate, with a DFP monitor on the DVI port
video=radeon:1280x1024-16@851280x1024 pixels, 85 Hz refresh rate, and 65,536 colors
video=radeon:1280x1024@61,panel_yres:10241280x1024 pixels, 61 Hz refresh rate, with the size of the monitor set to 1280x1024 pixels if autodetection fails
video=radeon:1024x768,font:SUN8x161024x768 pixels, with the 8x16 pixel SPARC font

The number of characters onscreen can be calculated by dividing the width by the font size, which is 8x16 by default. For 640x480 with an 8x16 font, the screen will hold 80x30 characters. At 1280x1024 with the same font, the screen will hold 160x64 characters.

Once the kernel option is created, it needs to be passed to the kernel at bootup. Testing the option before making it default is recommended. The exact procedures vary with bootloader. For the sake of completeness, use "append=video=..." under the appropriate "image" section in lilo.conf for LILO; or append the relevant "video=..." parameter to the appropriate "kernel" line in grub.conf for GRUB. For other bootloaders, consult the bootloader's documentation.

Version-specific issues

In 2.4.20 and 2.4.21, using the Radeon with a DVI cable will cause the display to lose signal and go blank when the framebuffer is initialized. This is because the timings are copied from the (unconnected and off) VGA/CRT monitor, instead of being calculated from the new mode parameters. Patches are available. Also note that in these versions, the "noaccel" option is forced on.

In 2.4.22, radeonfb tries to get the display size from the Radeon's BIOS, then an EDID block, and examines panel_yres only if those two methods fail. If the card reports the correct size, this is ideal, but mine does not. My card always reports 1024x768, and specifying a larger size causes the display to show a 1024x768-sized chunk in the upper-left of the display. A patch to make panel_yres override the BIOS and EDID is available in the patch list. Furthermore, acceleration is enabled by default. The screen tends to collect stray pixels while editing, but redrawing erases them again.

No changes have been made to radeonfb between 2.4.22 and 2.4.25.

Somewhere in the 2.5 series, all framebuffer device names have been changed to end in "fb" for consistency. So a proper video line should read something like video=radeonfb:1280x1024@61,panel_yres:1024 for 2.6.

In kernel 2.6.4 and possibly earlier, the new radeonfb driver supports getting the EDID data from the monitor. This should allow it to come up with a sane size and refresh rate without any video parameter. Some garbage is displayed on the screen when switching the console to the framebuffer, but it is harmless.


This page is Copyright 2003 C. Daelhousen <loonxtall@hotmail.com> and covered by the legal page for the Present.