This is a framebuffer driver for various Intel(R) 810/815 compatible graphics devices. These would include:
Intel(R) 815 Internal graphics (100MHz FSB)
Intel(R) 815 Internal graphics
Intel(R) 815 Internal graphics and AGP
First and foremost, these chipsets do not have dedicated video memory. They do have a reserved logical space for graphics memory (up to 64MB), but this space is empty. For this space to become usable at all, pages of System RAM must be mapped to this space. However, as with all video memory, the space must appear linear to anybody trying to access the graphics device. That's where GART comes in. GART (which stands for Graphics Address Relocation Table) or GTT (Graphics Translation Table) as Intel(R) calls it, basically does all the memory address juggling acts such that this logical space becomes functional as linear graphics memory.
Besides this 64MB logical space, the i810/i815 chipsets can access "stolen memory" of up to 1 MB. This memory is typically used for VGA, but because this memory is banked, you cannot access more than 64KiB at a time without some form of bank switching.
In the end, some form of GART service must exist in order for the i810/i815 to become usable at high resolutions. For kernels 2.2.19 and above, such an entity exists, agpgart written by Jeff Hartmann.
The present agpgart kernel module currently supports only one user at a time. As we probably all know, the primary user of this module is XFree86, whether directly or via the Direct Rendering Manager (DRM). It is relatively easy to write a framebuffer device for the i810/i815, making it coexist with other users of agpgart (like XFree86), is the most difficult part.
So how do we approach this problem:
A framebuffer driver already exists for this, VGA16. However, since you can only access 64KiB at a time, you will be limited to 640x480 at 8bpp. Most people will not be satisfied with this.
Stolen memory is actually a good idea. You'll be able to access 1 MB of memory, enough for 1024x768 at 8bpp or 800x600 at 16bpp. The downside is, the coder must be patient enough to write code for banked switching, else, you'll be stuck with 64KiB. (And I do know of someone who successfully wrote banked switching for the i810).
Another downside is lack of accelerated support. Overall, this is the safest option, since it will leave X with exclusive access to agpgart.
This was the first approach of the early versions of the driver. At first glance, this seems to be the correct technique, but actually it isn't. Even though the driver will be able to have it's own AGP memory, at some point down the hardware level, contention of critical hardware registers cannot be avoided. Therefore, the framebuffer driver must be careful in saving and restoring the register states each time X, or any agpgart requiring application becomes active. This is actually more complicated than it sounds.
I consider this the best method and there are several techniques. The first technique is to have XFree86 communicate with the kernel framebuffer driver whenever it needs to acquire or release agpgart. This is how the current i810/i815 driver works. Whenever X becomes active, it tells the framebuffer driver to release the device, and when X becomes inactive or exits, it tells the driver that it can re-acquire the device. The solution is simple, and we avoid a lot of hacks/workarounds and code bloat.
If it's not possible for the framebuffer driver and XFree86 to communicate with each other, then either the framebuffer or XFree86 will just have to be careful not to conflict with each other's memory and hardware states. Since XFree86 is a long-standing and trusted application, it's the job of the framebuffer driver to take care of not upsetting this balance or introducing new conflicts. That's how the the i810fb-lite driver maintains compatibility with XFree86.
Another novel idea (not mine) is to make AGP memory sharable. Sharable means it becomes like any other graphics device. In a few words, more than one application will be able to use the same memory space that another application is already using. The very distinct advantage of this method is that we save a lot of RAM. Since the current agpgart does not allow more than one user at a time, if an application needs 8 MB of video RAM, and another requires another 8MB, then agpgart will allocate a total of 16MB. However, if the AGP memory is sharable, agpgart needs to only allocate 8MB of RAM and then let both applications share the same memory block.