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.
Supports a kernel configurable option to select either discrete (Intel) or non-discrete (VESA Generalized Timing Formula or VESA GTF) timings. You will be able to use any combination of horizontal (multiples of 8) and vertical resolution, and maximum refresh rates, as long as they are within the range of the monitor specifications.
Supports color depths of 8, 16, 24 and 32 bits per pixel
Supports accelerated (8, 16 and 24 bpp only) and unaccelerated modes
Utilizes monitor specifications to automatically compute modelines
Uses kernel agpgart services
Can coexist with XFree86 driver running with native i810 drivers.
Supports hardware cursor
Supports hardware vertical panning for faster text updates
Supports Tiled memory
Resource Manager and Instruction Buffer interface
Supports Variable Display Aspect Ratio
Supports Console Display Rotation for 8 , 16 and 24-bpp only if memory is untiled, or 8 and 16-bpp if memory is tiled.
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.
Apply the patch. Each patch has a version number and the kernel version number that has to be patched.
Assuming your kernel tree is in /usr/src/linux
cat /patch/location/linux-i810fb-'version'.diff | patch -p0
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.
'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.
'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.
'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.
'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.
Recompile the kernel as usual.
For users of the i810fb-lite versions, you're done. For i810fb users, you have to patch the XFree86 i810 driver.
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:
Grab the XFree86-4.1 or 4.2 source from http://www.xfree86.org
Untar the package somewhere
cd to xc/programs/Xserver/hw/xfree86/drivers
bzip2 -dc patch-xc410-i810fb.bz2 | patch -p0
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
Untar the package somewhere in your system.
Browse the included README file first, as this file contains updated information, or extra instructions on upgrading.
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)
cd /usr/src/linux, then:
cat i810fb-xxx-yyy.diff | patch -p1
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.
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)
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.
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
I will provide a few recommendations on how to best configure the driver based on your needs.
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.
For maximum stability, keep your boot parameter as is:
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.
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:
Horizontal Synchronization Frequency
Vertical Refresh Rate
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..
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.
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:
|Surfaces||Offsets in MiB|
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.
As of this writing, the driver is already very stable. However, a few 'bugs' still exist which may or may not affect your system.
You might still experience a green cursor if hardware cursor is not enabled, and if the framebuffer pixel format is in 8 bpp. This is fixed by enabling hardware cursor, starting XFree86, or using a pixel format higher than 8 bpp.
At present, gdkxft (the gnome anti-aliasing library) is not compatible with X running in framebuffer mode. If you run X in framebuffer mode, then switch to console, X will die.
The render option for the i810fb package, as mentioned previously, is still buggy. If XFree86 is loaded with DRM, then exiting XFree86 abnormally will result in a system crash. For a demonstration, launch X, then switch to the console where you launched X, then type 'Ctrl-C'. This bug is absent with the i810fb-lite version.