From: James A Simmons <jsimmons@acsu.buffalo.edu>
  To  : ggi-develop@eskimo.com
  Date: Sat, 29 Aug 1998 16:59:27 -0400 (EDT)

Re: Problems with ATI Mach64 Driver...

> 	OK, I agree.  I think the best solution is to turn the damn cfbx
> code into modules that are compiled and linked intelligently by the kernel
> according to a set of dependencies.  It is absurd to have the user have to
> figure out the dependencies themselves. 
>
I agree to. Thats what I'm aiming for with my system. If you pick say a
Matrox Millenium setup then it sets up the dependecies for you. Only a few
expects exist like the S3 set where the use will have to pick a ramdac
and/or clock. For those types of cards the RAMDAC, clock list will
magically appear. 

> 	We can try, but we'd better ask Alan Cox if he thinks it would
> have a chance of getting past Linus' code freeze first. 

If you do get past the code freeze let me know ASAP. I will be ready with
the patch.
 
> > What worries me is the big question mark
> > floating above Steffen's new KGI API (and the other KGI APIs like the
> > evstack and suidkgi changes).
> 
> 	I'm not to worried about EvStack/GGI Console - Jason seems to have
> taken that under his wing.  I also think that KII can continue to be part
> of GGI Console for the time being, as it sort of is now.  But KGI is a
> problem.  I think we may have to take KGI's features and pull them out
> into fbcon-kgi.c.  We have already done some of this, and we could do more
> now that the kernel has mmap() handler hooks and suchlike.

You will see the kernel evolve into GGI Console.