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

Re: Last kgicon update before it goes in CVS

On Mon, 6 Jul 1998, Emmanuel Marty wrote:

> Jon M. Taylor had slept before he wrote:
> 
> >         Hm.  This post didn't have a Reply-To: for some reason.
> 
> Heh, well, using netscape as a mailer, I never wonder why it formats
> my text funny, forgets my reply-to, or such things :)

	I have never been able to use anything except pine with a local 
spool without becoming insane.
 
> [I wrote]
> 
> > > 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.
> 
> Obviously :) Sorry for being unclear - I meant, the "Dali" KGI API is
> way different from the "EvStack" KGI API, and slightly different (just
> some sane renaming) from 'your' Dali KGI API.. So, of course they'll
> write for the KGI API.. but .. which :-) 

	Oh, OK.

> It's settled now - it's the
> kgicon API; until Steffen introduces his changes, in which case both
> the kgicon and the drivers will be updated, I assume.

	Yes.
 
> > > 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.
> 
> Well, the problem is rather with CVS - once you create a directory somewhere,
> you can of course always remove all files and move it to some other place,
> but it's hell on earth - either you play nice and use cvs commands and the
> files stay twice, one copy in the attic of the removed directory and one copy
> at the new place, or you dirtily copy the RCS files from the server itself in
> which case you are unable to come back to the exact tree status of a
> date previous to the change.. (todd, see I'm learning.. :) That's why we
> should really put them in a place we won't change soon.. :) Maybe
> make a kgicon/ directory, and under that, put an include/ and a drivers/video/
> one ? Just a suggestion ..

	How about:

degas/kgicon
degas/kgicon/include
degas/kgicon/kgi
degas/kgicon/kgi/chipset

	Is that acceptable?  This will need to change when KGI goes
multi-OS (see below), but kgicon/ implies Linux/fbcon only for now anyway.

> > > 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 |-<.
> 
> Yup.. The Amiga uses a modern detection scheme, where at boot time,
> each card appears in the expansion memory space ($E0000 if my
> memory doesn't fail me), provides its manufacturer and product number
> like in PCI, and is assigned a memory region to decode, by the OS
> (expansion library iirc :). Then it latches this address and reappears
> immediately in the assigned address space.. real plug'n'play before
> the time :)
> 
> I don't know about Ataris, I doubt they use anything as advanced
> as that though. Probably more like the trial-and-error-possibly-even-
> crash approach of ISA.
> 
> .. But that's besides the point sorry. Yes, we'll need to move the
> detection scheme out of the drivers, and rather quickly too, if we
> want, say, the S3 driver to work both with PCI S3 cards on PCs
> and Alphas, and with Retina Z3 (that's S3-based, Geert, right ?
> That's SO far away now.. :() boards in an Amiga ..

	This dovetails with the porting-to-Roadrunner discussion.  All the
OS- and archictecture-specific stuff needs to be broken out into an OS
subsection of KGI.  The old kernel/ subsection sort of did this, but not
really.  Maybe something like this: 

kgi/
kgi/chipset
kgi/os
kgi/os/linux
kgi/os/linux/io.c
kgi/os/linux/memory.c
kgi/os/linux/detect.c
kgi/os/linux/init.c
kgi/os/freebsd
kgi/os/roadrunner
kgi/os/dolphin

	Right now each chipset driver has to deal with issues of ISA vs.
PCI with regard to detection, initialization, resource allocation, MMIO
vs. port IO, virtual vs. physical memory layouts, etc and it's all Linux
and x86 specific on top of that.  All that stuff needs to be located
elsewhere.  A driver for an S3 Trio64V+ should not have to know about 
anything other than how to program an S3 Trio64V+.

	The KGI driver should be able to assume that all the groundwork
has been take care of before it is initialized - the hardware is present
and has been properly initialized, there are no resource conflicts, the
appropriate methods of hardware access have been chosen and hooked into
abstract KGI hardware access functions, command and data pathways to and
from the OS have been properly set up and hooked into their own abstract
KGI interfaces, etc.  Of course KGI is light-years ahead of other driver
already WRT these issues, but it still has quite a way to go yet. 

	With PCI becoming a universal expansion bus on more and more
hardware platforms, The same hardware will potentially be in use on many
different OSes and CPU types in many different combinations.  Even without
PCI we already see this happening, like with the Amiga Retina Z3 as
described above.  The need to properly handle this issue will only grow
more and more urgent for the open source community as time goes on.  It is
pure time wastage and and unnecessary hassle for drivers for the same
hardware to be rewritten and code duplicated for different OSes and
architectures, or if the drivers are unified to have them junked-up and
made unreadable and much longer than they need to be with #ifdefs.

	Hopefully, this idea will take hold with KGI and Linux and from
there spread to other types of Linux drivers and other OSes.  Ideally, all
open-source OSes should be able to use the exact same driver set with
their own OS-specific interface layers (like fbcon, for example).  If that
happened, the kgi/os directory described above would no longer be needed
because it would be a standard part of each OS out of the box.  I imagine
that the idea of only having to write one driver in C and having it work
unmodified on *every* open-source OS on *every* platform would be
appealing to the hardware companies.  They could distribute binary modules
if they wanted to as well, without losing the architecture and OS
independence.  If the commercial OS makers were to adopt a similar
interface, this could mean that only *one* driver would have to be written
*ever* and it would work on *every OS*.  Sounds nice to me!


> And anyway thanks a lot for your work, Jon :)

	I am in a position in life right now where I can work on KGI to my
heart's content (1/2 time easy work, no girlfriend, one stupid and easy
class in the evenings twice a week, live with parents and use their car,
no social life since all my friends graduated and moved away) like I
haven't been able to do for a long time now.  My current class is my last,
and after it is over I will be completely done with college and be obliged
to get a real job, move out of my parents' house, get my own car, get new
friends, probably get a girlfreind, etc.  I need to get my licks in while
I can |->. 

	Also, the current state of Linux, fbcon, KGI, Degas and the GGI
project in general affords many opportunities for useful and needed
innovation.  The zeitgeist is quite positive right now, and I intend to
take advantage of it to the fullest extent possible.  KGI has taken a back
seat to LibGGI and EvStack within the GGI project for the last year or so. 
Maybe that was as it should have been, and we have certainly gotten two
very cool and innovative (and *needed*) systems out of it, but my area of
interest and expertise within computer science is graphics hardware and
the parts of OSes that handle same, and that was what prompted me to get
involved with GGI in the first place.

Jon

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