From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Sat, 29 Aug 1998 14:43:49 -0700 (PDT)

Re: Problems with ATI Mach64 Driver...

On Sat, 29 Aug 1998, James A Simmons wrote:

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

	Actually, if you either autodetect or ask the user to select the
_card type_ (i.e. STB PowerGraph 64 Video), that should tell you which
chipset, clockchip, ramdac, and accel drivers to use.  That would give you
a nice, linear set of yes/no/module options which would work perfectly
with the kernel config system.  The only sticky issue is the monitor
driver.

	It would be nice to still be able to select the individual
sub-drivers, but if the main kernel config system couldn't do that I
wouldn't be too upset.  Maybe you could have one generic "custom KGI
driver" option, and the user would have to cd to drivers/video/kgi and do
a make config from there to select the individual sub-drivers. 

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

	Yes.  "Evolve" is the keyword here.  The GGI project has been 
hurt in the past by trying to change too much stuff all at once.  If we 
pick our battles more carefully and make each one smaller, we will be a 
lot better off.

Jon

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