From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Sun, 30 Aug 1998 14:41:16 -0700 (PDT)

Re: Problems with ATI Mach64 Driver...

On Sun, 30 Aug 1998, Andrew Apted wrote:

> Jon writes:
> 
> >  On Sat, 29 Aug 1998, Andrew Apted wrote:
> >  > So the question is: do we integrate kgicon into the kernel makefile
> >  > system (i.e. right now) ?  
> >  
> >  	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. 
> 
> Hehehe.  Sorry, but there's a snowflake's chance in hell of Linus
> putting it into the kernel before 2.2.  We should be aiming at 2.3
> IMHO, but we can still integrate into the kernel right now if we wanted
> (as an add-on patch like various others around the place).

	I agree.  I gave up on 2.2 a while ago, but others were asking....

> >  > 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.
>   
> It's not so much KGI code itself (and KII etc) but the driver API.
> There were some changes to the API for EvStack (don't know what though),
> and the suidkgi target needed its own changes to the API (to be able to
> live in userspace), and Steffen is making his own big changes to the
> driver API... and I still want to see a merger (probably over the course
> of linux 2.3) of our driver API and the fbcon driver API.

	IMHO this needs to be dune in stages.  The changes to the driver
API (dpp, etc) can be backed in to kgicon, and should be done so ASAP if
at all so we can get busy converting the drivers, debugging, etc.  As for
the KGI *framework* changes, I suggest we table all such until after
Degas.  Then, I propose the following: We dissect kgicon, KGI, SUIDKGI,
fbdev and GGI Console(?) and strip out all framebuffer device handling
code and collect it together into a new KGI spec that can be dropped in to
replace fbdev. 

	This new KGI should be an enhanced fbdev, nothing more.  The input
device stuff from GGI Console and the current KGI should be stripped out
and combined to produce KII, which would be formally spun off into a
separate project.  And of course all the console stuff goes to GGI
Console, if it hasn't already.  Clean separation of function.  And if it
becomes necessary to upgrade fbdev from within in stages and maybe even to
keep calling it fbdev instead of KGI, that's what we do.  No more
politics!  The end result is all that matters!

Jon

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