From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : Emmanuel Marty <core@suntech.fr>
  Date: Mon, 6 Jul 1998 13:39:12 -0700 (PDT)

Re: Last kgicon update before it goes in CVS

On Mon, 6 Jul 1998, Emmanuel Marty wrote:

	Hm.  This post didn't have a Reply-To: for some reason.

> Jon M. Taylor wrote:
> 
> >         Very well, degas/kgicon and degas/kgicon-include it is, unless
> > anyone has objections and I hear from them before tomorrow evening.  I
> > guess it really doesn't matter what the directories are called - the stuff
> > is going to be isolated from the rest of degas as far as makefiles and
> > installation goes anyway.  We can always rearrange things later when the
> > separation of EvStack and KGI in Degas is completed.
> 
> No objection from me as to adding that to the repository; we needed to
> agree on something so that driver writers wouldn't spill efforts adapting
> them for 15 different APIs. 

	Huh?  They would always write them for the KGI API.  The bridge 
layer is what connects the KGI API to another API, like fbcon.  Maybe I 
misunderstood you.

> About the include dir, can it be folded under
> kgicon or is it really a seperate entity? :)

	Well, the logical place for it would be degas/include/kgi, but I
don't want to overwrite the existing KGI includes and possibly break
EvStack or the LibGGI KGI target.  So I thought to keep them separate for
now.  We do need to work out a good long-term solution in the near future,
however. 
 
> I suppose that the whole set of drivers under kgicon/ and the wrapper
> itself, can be slightly modified when Steffen releases his new KGI
> specification; it's not like your changes are real work for driver
> programmers anyway, it's just some good sanity cleanup and
> renaming.

	Yes.  I imamgine that there will be quite some reorganization of 
the whole tree when that happens anyway.  In the meantime people will 
have to manually copy the directories into the linux/ tree anyway, so one 
directory renaming won't matter.

> > > > * Make sure that drivers work properly on non-x86 architectures.
> > >
> > > That's not going to be evident :)
> >
> >         It may take quite a bit of work in some cases (Amiga S3-based
> > boards) and be quite painless in others (like the Open Firmware Mac PPC
> > drivers).  Luckily that isn't my problem as I only have x86 |->.
> 
> Yes, Geert mentioned that some Amiga display cards don't even provide
> direct access to the framebuffer. Those don't go through fbcon at all at
> the moment but use a special set of framebuffer ops, we'll have to fold
> them in sometime.. :)

	Also, Amigas and Ataris don't have PCI, so at some point the card
detection routines (which are currently hardwired to detect either by ISA
I/O or PCI) will probably need to be broken out into separate modules,
just as the I/O port programming is now.  Otherwise we will end up with a
hideous unreadable mess of #ifdefs like the XFree86 drivers have |-<. 

Jon

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