From: James Simmons <jsimmons@edgeglobal.com>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Tue, 23 Feb 1999 11:11:05 -0500 (EST)

Re: KGI system needs a lot of work

Hi all! Sorry I have been so quite. Have been busy with the patch.

> 	However, the existing system is more or less stable and Steffen's
> new KGI is still rough around the edges.  The new KGI's design is much
> better, however, and there are numerous flaws in the Dali-based KGI, so at
> some point KGIcon will have to be ported to Steffen's new KGI.  That 
> point may be fast approaching.  

Yep. I have been waiting to port the drivers over to my patch.

> I am beginning to encounter non-trivial 
> problems with the existing KGIcon system at work.  Enough cruft has 
> accumulated over the years that I think it may be time to rewrite 
> everything from the ground up.  Not from scratch, of course, but with a 
> group rethink and pulling in pieces from everywhere:
> 
> * Steffen's new KGI
> * The existing KGIcon
> * James and Fabrice's work

I haven't heard from fabrice in a while. I think the patch in now in my
hands. I'm still working on some code optimizations and trying to figure
out how iplans work for amigas. Anyone knows?

> * My new register handling, depending on how well it ends up working
> * New code
> 
> 	Here is what I see as needing to be done:
> 
> * Rip the video driver code out of Steffen's new KGI and port fbcon-kgi.c
> to it.  Use the VGA driver as a testbed.  Once the new system with the new
> VGA driver is up and running, porting of the other drivers (including the
> one I'm developing at Creative) can begin.

We need really good docs on the new KGI with a skeleton driver.   

> 
> * We need more tools.  fbset needs to be co-opted by GGI until Geert
> decides to start working on it again.  It could use a lot of work right
> now.  Grabmode also needs to be enhanced.

I believe geerts is still working on it. You can get a newer version from
his homepage.

> 
> * The drivers need to be cleaned up and reorganized.  All of them should 
> be laid out nice and clean like the Matrox drivers are - no .inc files, 
> unified ISA and PCI I/O handling, etc.  Especially the S3 drivers....
> 
Yes please. We should also move all code thats very similar in the drivers
out. By this I mean the pci code. I would like to a kgifb.c, pcifb.c,
offb.c zorrofb.c etc.

> * All drivers should insert and remove cleanly, and handle plug 'n play 
> MMIO reloc correctly as well.  Some do, many do not.  All should.
> 
Which ones? What about isa cards?

> * I will be adding DDC2b monitor autodetection support to the chipset 
> driver I am writing as work, and I should be able to allow KGIcon to pick 
> that info up from the chipset driver and send it to the generic mondriver 
> using the sysctl interface.  The code should actually be really easy.

That would be great. I notice ATI cards can do this too. 

> 	I don't expect all this this to happen overnight, obviously we are
> looking at quite a bit of work.  But it HAS to happen somewhat soon and I
> cannot do it all by myself.  Steffen has to keep working on getting the
> new KGI design nailed down tight.  I therefore strongly encourage all
> those folks who have KGI or KGI driver coding experience to step up and
> take charge of some part of this mess to help me clean it up. Actually, 
> anyone at all can help - test, write documentation, read through the 
> code and suggest changes or spot out problem areas, write or enhance
> test utilities, etc etc.

No problem. The weekend is coming up and I will post my new patch on
monday. It might not be complete. I need drivers to test it. I have 5
video cards at home waiting to be fully tested.