From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Tue, 11 Aug 1998 15:44:03 -0700 (PDT)

Re: kgicon FAQ

On Tue, 11 Aug 1998, Geert Uytterhoeven wrote:

> 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: 
 
[snip]

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

	First, we still have to support all those older cards with
separate components.  Second, just because those functions are combined on
one IC does not mean that they are not still separate from each other as
far as functionality goes.  I agree that there is a case to be made for
not having to select separate options when you know exactly what ramdac
and clockchip and accel drivers will always go with a particular
integrated chipset, but that is a config system issue and not a driver
architecture issue. 

	If you keep your drivers monolithic, they will degenerate over
time into an unreadable mess of #if blocks and special cases.  This is
exactly what has happened to the XFree86 drivers.  In contrast, with a KGI
driver the interfaces are clean and everyone knows what subsections are
responsible for what tasks/info.  It isn't perfect, of course; IMHO, the
chipset driver is still too monolithic.  Hardware detection and
initialization and IO methods should be broken out into their own driver
subsections.  One thing we need to work on is how we implement our driver
modularity.  Except for the Matrox drivers, right now all the KGI drivers
use .inc files for common code, which just swaps the code in using
#includes.  This is bad.  Hopefully all this will be cleaned up during the
move to Degas-KGI.

	Nevertheless, the basic idea of having more modularity rather than
less is good.  I can look at a KGI driver I have never looked at before
and quickly trace the flow of control to find exactly what I am looking
for.  I know what source files to look at right away, and even if they use
.inc files that only requires one more file to look at.  In contrast,
whenever I have been forced to look at XFree86 drivers for something, I
have usually had to grep like crazy to find the source files where what I
am looking for is located, and after that I still have to open up several
driver source files simultaneously as well as several higher-level XFree86
source files to untangle the mess of data structures and APIs that they
use.  I often run out of VCs, I need to have so many files open at the 
same time!

	fbcon drivers are headed for the same mess.  The fbcon API is
cleaner and more consistent than XFree86's, but the drivers are all still
monolithic and I can see them diverging further and further from
commonality as they are tweaked more and more over time.  It has become
noticeably more difficult to use the fbcon drivers as examples just since
2.1.107.  The more that happens, the harder it will become to maintain the
drivers and pull out common code and the harder it will be to extend the
fbcon API without breaking lots of drivers that did wierd things on their
own.

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

	That isn't the problem.  Right now, the BIOS calls to set the
video mode are made in video.S, which executes early in the boot sequence
before protected mode is entered.  To do this at runtime, you'd need to
open up a vm86() box in the kernel like DOSemu does and make the BIOS
calls in there, and you'd have to *keep* it open as long as the driver was
loaded if you wanted to enable on-the-fly modesetting capabilities.  Not
impossible, but not trivial either. 

> > * 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 :-)

	How so?  I hadn't heard this.

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

	IIRC, the penguin logo bitmap data is thrown away after the kernel
boots.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed