From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Sun, 21 Feb 1999 18:19:02 -0800 (PST)

KGI system needs a lot of work

	KGI development is not where it needs to be.  The original KGI
'Dali' design was released by Steffen in 1996.  It is still being used,
albeit with a lot of bailing wire and duct tape, in the current KGIcon
system.  Marcus has added the new generic mondriver and a bunch of sysctl
stuff in fbcon-kgi.c, which is good stuff but it doesn't attack the
underlying KGI data structures and fucntionality. 

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

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

* All drivers should insert and remove cleanly, and handle plug 'n play 
MMIO reloc correctly as well.  Some do, many do not.  All should.

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

* A concerted effort should be made to pull as much functionality out of 
Steffen's new KGI design as possible into the new KGIcon.  That way, the 
drivers we develop under it will be as easy as possible to port to the 
real KGI.

* SUID-KGI should also be ported to the new KGI.  Andy?

* xBSD KGI people, lets get organized here too.  We have a lot better
chance of getting the full KGI into one of the BSDs than Linux right now,
and we need to make sure that KGIcon, SUID-KGI and full KGI all work
properly and work the same with the same drivers. 

* This would be an excellent time to split up the mailing list as has been
discussed - no more KGIcon bugreports on the main GGI mailing list.  Also,
it would be a lot easier to begin prototyping the new KGIcon system if we
had a CVS repository for it.  That way we would not have to replace the
existing KGIcon system until the new one works well.  Emmanuel, can 


	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.

	I doubt the new KGIcon will be ready when LibGGI 2.0 comes out, so
the existing KGIcon will have to be what gets released as part of 'Degas'. 
But it needs to be a lot tighter than it is now for that to work well. 
But we really need to begin wrapping up Degas for good and get a solid
LibGGI 2.0 + KGIcon so we can begin design work on the _next_ release of
GGI (I think we should call it 'Dean', after artist Roger Dean who did all
the Yes and Asia album covers).  LibGGI has made tremendous progress
recently, but KGI counts too.  Anyway, as always feedback is appreciated. 

Jon

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