From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Tue, 11 Aug 1998 11:29:30 +0200 (CEST)

Re: kgicon FAQ

On Sat, 8 Aug 1998, Jon M. Taylor wrote:
> 3. How are KGI drivers different from fbcon drivers?
> 
> 	fbcon drivers are "monolithic".  This means that all the driver
> code is contained in one source file.  KGI drivers are modular.  Each
> driver is composed of five driver subsection that are selected separately
> and linked together at compile time.  These subsections are: 
> 
> * Chipset driver.  This is analogous to the monolithic fbcon driver, 
> which is usually designed around a particular video chipset.
> 
> * Clockchip driver.  Controls the calculation of mode timings.  The same 
> chipset can be use with a different clockchip on some video cards.
> 
> * Ramdac driver.  Controls the digital-to-analog conversion circutry on 
> the card.  As with clockchips, the same chipset can be used with 
> different ramdacs.
> 
> * Acceleration driver.  This controls accelerated drawing commands,
> anything from drawing lines and block copying to more complex 3d
> acceleration.
> 
> * Monitor driver.  This subsection does not actually control any video 
> hardware.  It consists of a set of mode timing constraints, which prevent 
> the other driver subsections (mostly the clockchip driver) from 
> generating mode timings that the monitor cannot handle.
> 
> 	This modular architecture allows for greater re-use of driver 
> code.  It also enforces a clean separation of functionality and imposes a 
> more consistent driver code layout.

But these days the trent is to put all things in one chip. So everything except
the monitor driver is specific for one graphics chipset.

> 2. What can kgicon do that vesafb cannot?
> 
> * Work on older hardware that does not support VESA 2.0. 
> 
> * Load as a module.  vesafb must be compiled into the kernel.

Can't be difficult to change. Just add init_module() etc. functions.

> * Use YWRAP/YPAN to speed up console scrolling.  vesafb is limited in its
> knowledge of the layout of and ability to control the underlying hardware,
> and so it cannot use some tricks such as changing the start address of the
> framebuffer to speed scrolling.  KGI drivers have full control over every
> aspect of the hardware, and so they can use whatever capabilities are
> present to speed up scrolling.

Obsolete comment :-)

> 3. What can vesafb do that kgicon cannot?
> 
> * Be compiled into the kernel and used at boot time.  kgicon drivers only 
> work as modules right now.  Sorry, no penguin logo |-<.

Time to make fbcon.c a module, too?

Greetings,

						Geert

P.S. Can I post this FAQ to the Linux/m68k list?
--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium