3. The Intel(R) 810/815 Framebuffer driver

At present, the i810fb package is deprecated, and the i810fb-agpgart driver is now renamed as i810fb. I also introduced a new driver, i810fb-lite. This is a stripped down version of i810fb-agpgart without the Console Display Rotation Code and Hardware Interface. The i810fb-lite driver does not require a patched XFree86 driver in order for X to run.

What version should you use? If you just want to experience the functionality of the framebuffer driver in the most unobtrusive way possible, then get the i810fb-lite version. The i810fb-lite version just requires a kernel patch. No other files need to be altered. For most users, this is the version I will recommend.

If you want to experience the full features of the driver or experiment with development code, such as Display Rotation or the accelerated DirectFB gfxdriver for the i810, get the i810fb version. Note, i810fb requires you to patch XFree86 for X to run. Also, the additional features may introduce bugs/misfeatures or security risks.

3.1. Supported Features

3.2. Compilation

3.2.1. Adding i810/i815 support for the first time

  1. Get the kernel patches from the Sourceforge Project site. Patches to add i810fb support for the first time in the kernel will always be  found in linux-i810fb-xxx-0.0.23. If a new kernel version is released, the v0.0.23 tarball will be repackaged to include the new kernel.

  2. Apply the patch. Each patch has a version number and the kernel version number that has to be patched.

  3. Assuming your kernel tree is in /usr/src/linux

          cd /usr/src 
          cat /patch/location/linux-i810fb-'version'.diff | patch -p0

  4. Configuring the kernel.

    Agpgart support is REQUIRED. How support for the i810 will be added depends on how you enabled agpgart. Then just enable i810 Framebuffer support in Console->Video->Framebuffer. The following are a list of options available for the driver. These options are not enabled by default.

    1. 'use VESA GTF for Video Timings' - select this if you want to experiment with nonstandard modes (like 936x702 at 72 Hz for instance). Although this option may theoretically carry a certain risk, I still prefer to enable this option. This option also makes your kernel a teenie bit smaller.

    2. 'enable accelerated drawing functions' - select this option if you want to maximize console performance. It is significantly faster than non-accelerated mode but the difference should not be noticeable unless you are using the console at high color depths. It will also add some 2KiB to your kernel.

    3. 'enable display rotation code' - select this option if you want to rotate the console display. Most users will leave this unselected. It will also add some 4KiB to your kernel. This option is not available with the i810fb-lite driver.

    4. 'enable hardware interface' - very experimental, very high security risk option. If you want to use the experimental DirectFB gfxdriver, then enable this option, otherwise turn this off. It will also add some 2KiB to your kernel. This option is not available with the i810fb-lite driver.

  5. Recompile the kernel as usual.

  6. For users of the i810fb-lite versions, you're done. For i810fb users, you have to patch the XFree86 i810 driver.

  7. In order to use X with the i810/i815 framebuffer driver, you must get the patched i810 driver from the Sourceforge Project site. Only versions 4.1 and 4.2 is supported. Just copy the file i810_drv.o to /usr/X11R6/lib/modules/drivers.

    If you want to do it the hard way by recompiling X, then:

    1. Grab the XFree86-4.1 or 4.2 source from http://www.xfree86.org

    2. Untar the package somewhere

    3. cd to xc/programs/Xserver/hw/xfree86/drivers

    4. bzip2 -dc patch-xc410-i810fb.bz2 | patch -p0

    5. recompile

3.2.2. Upgrading the driver

Once you have patched your kernel, and as long as you don't upgrade kernels, you don't need to patch the kernel again when upgrading. All you need to do is to get upgrade patch. Then

  1. Untar the package somewhere in your system.

  2. Browse the included README file first, as this file contains updated information, or extra instructions on upgrading.

  3. Upgrades will be in the form of patches. There should be two types of patches available per upgrade. One is a direct upgrade from v0.0.23, and the other is an incremental patch (ie. an upgrade from a previous version, 0.0.23-0.0.24, for instance)

  4. cd /usr/src/linux, then:

          cat i810fb-xxx-yyy.diff | patch -p1

  5. recompile.

3.2.3. Using the precompiled modules

The precompiled modules are in the linux-i810fb-xxx-mod.tar.bz2. Rename them into i810fb.o and place them anywhere but preferably in /lib/modules/'version/kernel/drivers/video/i810. Then you must recompile the kernel so you enable Framebuffer support and 8-, 16-, 24-, and 32-bit packed pixel support under the “Advanced Low Level Driver Options”. Then load the module as usual.

Please note that the precompiled modules may not work in your system, especially if you use a different compiler. The modules were compiled with gcc-2.95.3.

3.3. Kernel boot parameters


enables the i810 driver


the horizontal resolution in pixels (default = 640)


the vertical resolution in scanlines. Computed as (3*xres)/4. This is an independent parameter if the 'use VESA GTF for Video Timings' option is selected. (default = 480)


the virtual vertical resolution in scanlines. If greater than "yres", hardware y-panning will be automatically enabled. (default = 480)


the amount of system RAM in MB to allocate for the device (default = 4)


the RGB pixel format in bits per pixel (default = 8)


the minimum and maximum Horizontal Sync Frequency of the monitor in KHz . For fixed frequency monitors, hsync1 must be equal to hsync2. default (30/30)


the minimum and maximum Vertical Sync Frequency of the monitor in Hz. You can also use this to fix/limit the refresh rate of your monitor. So, if you need fix the refresh rate at 60Hz (no more, no less), then set vsync1=60 and vsync2=60. (default = 60/60)


enables text acceleration (default = not set)


enables MTRR. This allows data transfers to the framebuffer memory to occur in bursts which can significantly increase performance. (default = not set)


enables hardware cursor (default = not set)


enables secondary/external VGA output (default = not set)


Forces display refresh during vsync only. This may be useful if display panning causes the display to flicker. Enabling this option will limit the flicker. Note:  the newer versions waits for vertical retrace by default, thus, this option is deprecated.  See nosyncpan. (default = not set)


Forces the hardware engine to do a "sync" for each accelerated function. This will produce a more stable setup, but will be slower. (default = not set)


forces the framebuffer memory to be aligned to the framebuffer size. At the same time, the whole video memory will be tiled. Memory tiling is a method to localize graphics data which speeds up hardware access to surface data. This might be useful for high-bandwidth modes (3D, Video, or just plain high resolution, high bit depth modes).


rotates console display. "rotate=0" = no rotation; "rotate=1" = rotate to the right; "rotate=2" = rotate 180 degrees; and "rotate=3" = rotate to the left. Prerequisite: "accel" must be enabled, swap xres value with yres if display is rotated by 90 degrees. (default = no rotation). Please note, the i810fb-lite version does not support this option


This option is specific for the i810fb-lite version only. This option specifies at what offset to allocate the framebuffer memory relative to the start of the graphics aperture. Since the graphics aperture is to be shared with XFree86, one must be careful not to cause any memory overlaps. (default=16 MiB for 64MiB aperture sizes, and 8 MiB for 32MiB aperture sizes)


This option will pan the display without waiting for vertical retrace.  This feature only works with the render option. (default = not set)


This option wil use interrupt handlers to wait for vertical refresh, by letting the current process sleep until a signal is received. Theoretically, this allows lesser CPU usage than polling CGA/MDA registers and might provide smoother buffer flips.  Only applications that use the hardware interface will be able to take advantage of this feature, ie. DirectFB. (default = not set). Please note, the i810fb-lite version does not support this option.

As an example, in /etc/lilo.conf, add the line:


This will initialize the framebuffer to 1024x768 @ 16bpp. The framebuffer will use 2 MB of System RAM. MTRR support is enabled. The refresh rate will be computed based on the hsync1/hsync2 and vsync1/vsync2 values. REMEMBER: you need to include hsync1, hsync2, vsync1 and vsync2 to enable video modes better than 640x480 at 60Hz.

3.4. Module options

The module parameters are essentially similar to kernel parameters. The main difference is that you need to include a Boolean value (1 for TRUE, and 0 for FALSE) for those options that does have an assignment. Example, to enable MTRR, include "mtrr=1".

Using the same setup as described above, load the module like this:

    modprobe i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 vsync2=85 accel=1 mtrr=1

Or just add the following to /etc/modules.conf

    options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 vsync2=85 accel=1 mtrr=1

and just do a

    modprobe i810fb

3.5. A Few Tips

I will provide a few recommendations on how to best configure the driver based on your needs.

3.5.1. Maximum resolution and refresh rates

To just enable the framebuffer, you can boot just with these options


Without any options, the driver will boot in its default 640x480 at 60 Hz refresh rate in 8 bpp. All features are off and whatever you do, you won't be able to increase the refresh rate or resolution very much, since the driver is locked at VGA timings only. So, to get higher resolutions or refresh rates, you must explicitly tell the driver the characteristics (horizontal and vertical sync frequencies) of your monitor. Check the back of your monitor, your monitor's manual, or if you are using X, the 'HorizSync' and 'VertRefresh' parameters in /etc/X11/XF86Config. You need to specify the values in the hsync1, hsync2 , vsync1 and vsync2 options. To boot to 1024x768, you can also specify xres and yres. Thus:


With the above options specified, you may be able to boot at 1024x768 in 8bpp. If you did not specify the hsync and vsync parameters, the driver will fail to load. Note this is true even if you have laptop displays.

3.5.2. Maximum stability

For maximum stability, keep your boot parameter as is:


3.5.3. Maximum performance

How about the other options? For maximum performance, specify accel. The console drawing functions will now use the chipset's 2D routines, instead of rendering them in software. Although it's very stable, use of the 'accel' option may interfere with X, although I rarely see this happen. So for maximum stability, you can turn this option off. The software functions are actually very fast with the i810 and i815 because the software directly renders to System Memory (Remember: the chipset uses System RAM for framebuffer memory).

You can also enable mtrr (or Memory Type Range Registers) which supposedly increases performance up to 200%. This option is very stable, and I haven't encountered problems with this yet.

There is another option, vyres, which will increase the performance of text scrolling with or without acceleration. If vyres is greater than yres, the extra memory will be used for buffer flipping/vertical panning. If vyres is at least double yres, text scrolling speed may increase several fold. Try testing this by doing a time cat text file and take note of the difference.

How about the pixel depth? This is specified via the bpp option. Just go for 8bpp, since the console uses only 16 colors. Using more than 16bpp is counterproductive, will drop performance and will increase memory requirement.

To summarize, you can use this option line for maximum performance.


3.5.4. Going for unusual display modes?

Before I go on, please remember that using VESA Generalized Timing Formula or GTF carries an inherent risk of damaging your monitor, especially those with faulty circuitry. Although I have provided quite a number of checks not to go beyond the capabilities of your monitor, it's certainly possible that some settings may overdrive it. So be careful.

When you configure your kernel, you'll note that there is an option 'use VESA GTF for Video Timings'. By default, this is off. What is the VESA GTF anyway? The GTF is a VESA standard wherein the required video timings may be completely calculated given only the desired horizontal resolution, the desired vertical resolution and at least one of the following:

  1. Horizontal Synchronization Frequency

  2. Vertical Refresh Rate

  3. Pixelclock

The GTF does not strictly impose a limit on what values to use, as long as these values are within the limits of the monitor's capability. Within these limits, you can get continuous values (nondiscrete timings vs. discrete timings) allowing the possibility of using a wide variety of combinations of display resolutions or refresh rates.

If VESA GTF option is disabled, the driver will fall back to a subset of discrete timings that are published by Intel. You'll be able to use only a fixed set of resolutions ('640x480', '800x600', '1024x768', etc) and refresh rates (60, 70, 72, 75 and 85 Hz). You'll also be fixed to the standard aspect ratio of 4:3. Most of us are probably content with these sets, but others might want to fine tune their timings. If you are such a person, then enable this option.

To illustrate, I will give an example. Suppose you have a monitor with the following characteristics, hsync1=30, hsync2=54, vsync1=60 and vsync2=90. With this monitor you can get 640x480 at 85Hz, 800x600 at 85Hz up to a maximum of 1024x768 at 60Hz. For some of us perhaps, 800x600 might not maximize screen estate and 1024x768 produces too much flicker. Why not compromise by increasing the resolution but still maintain an acceptable refresh rate, say 936x702 at 72 Hz? With the monitor in question, this can be done. Enable 'use VESA GTF for Video Timings', then change your boot parameters to this:


With the VESA GTF, the driver will always attempt to use the highest refresh rate possible.

The VESA GTF will also enable you to select different aspect ratios. Say you want to display at 1200x600 (2:1 aspect ratio). Just specify them in your configuration file and reboot.

Still willing to go on? Do you want to rotate your display? Then specify the rotate option. The accel option is a prerequisite. Say you want to rotate the display clockwise to the right, then use this option line:


Note that I swapped the values of xres and yres, since this is what the console sees. The driver though will know that the actual xres and yres values must be exchanged..

3.5.5. Options by preference

The other options are basically a matter of taste. Do you have a system with a limited amount of RAM? By default, the driver boots with 4MiB of RAM. You can specify values from 1 to 64 MiB with the vram option. Note: on 32 MiB Systems, you can only use a maximum of 3MiB, and for 64 MB systems, a maximum of 28 MiB.

Do you hate the block cursor? Then, include the hwcur option. Are you bothered by screen flicker when scrolling? Then, enable the sync_on_pan option. Do you want to maximize stability of the accelerated functions at the expense of performance? Then, enable the sync option.

3.5.6. The voffset option

For the i810fb-lite version, an extra option exists, voffset. In order for XFree86 and the framebuffer driver to coexist peacefully, conflicts between X and the framebuffer driver must be avoided. We do this by taking advantage of what I termed as “X memory holes”. These “memory holes” are memory segments of the graphics aperture space left untouched by X. The following table shows what offsets are used by XFree86 when allocating memory for different surfaces:

  Aperture Sizes
  64MiB 32MiB
Surfaces Offsets in MiB
FrontBuffer 0 0
DepthBuffer 48 16
BackBuffer 56 24

Depending on the amount of RAM XFree86 allocates to the surfaces, the largest contiguous hole we can use is between the FrontBuffer and the DepthBuffer. If we use an offset of of 32MiB for the 64 MiB aperture size, we will be able to use the space from 32 - 48 MiB, for a total framebuffer size of 16 MiB. Note however, that the framebuffer driver also needs a few more kilobytes of aperture space for instruction buffers and cursor memory, so subtract 1 MiB from that space. You have the option to change this offset, using voffset. Be careful though not to conflict with X. This is how X will react when there is a conflict:

  • FrontBuffer - fatal, X will refuse to load

  • DepthBuffer - fatal, X will not load unless DRI is explicitly disabled in XF86Config

  • BackBuffer - non-fatal, X will load but with DRI disabled.

The render option also introduces another difficulty. The render allows tiling of the memory which requires that the voffset be also aligned by the framebuffer size (the modulus, or remainder, of voffset/vram must be 0 -- voffset % vram == 0). Thus, if you allocate 8 MiB of RAM, then the offset must also be aligned by a multiple of 8. As an example, if render is enabled and the following options are passed, vram=16 and voffset=8, then voffset will not be aligned. The driver will adjust the voffset to the next lower vram-size multiple, which happens to be 0, and this will conflict with X's frontbuffer. On the other hand, If you pass vram=16, voffset=32, then the framebuffer driver will take the aperture space from offset 32 to offset 32 + vram + 1, or 32 + 16 + 1, which is 49. This will now conflict with XFree86's DepthBuffer, which starts at 48.

3.5.7. Very experimental options

At present, I will not recommend anyone to use the render option since it still has some incompatibilities and conflicts..

3.6. Limitations

As of this writing, the driver is already very stable. However, a few 'bugs' still exist which may or may not affect your system.