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

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.5.1. Maximum resolution and refresh rates

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

     append="video=i810fb"
    

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:

     append="video=i810fb:hsync1=value:hsync2=value:vsync1=value:vsync2=value:xres=1024:yres=768"
    

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:

     append="video=i810fb:hsync1=value:hsync2=value:vsync1=value:vsync2=value:xres=1024:yres=768"
    

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.

     append="video=i810fb:hsync1=value:hsync2=value:vsync1=value:vsync2=value:xres=1024:yres=768:vyres=1536:accel:mtrr"
    

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:

     append="video=i810fb:hsync1=30:hsync2=54:vsync1=60:vsync2=90:xres=936:yres=702"
     Reboot.
    

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:

     append="video=i810fb:hsync1=30:hsync2=54:vsync1=60:vsync2=90:yres=936:xres=702:accel:rotate=1"
    

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:

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..