From: Emmanuel Marty <core@suntech.fr>
  To  : Jon M. Taylor <taylorj@ecs.csus.edu>
  Date: Mon, 06 Jul 1998 20:52:42 +0000

Re: Last kgicon update before it goes in CVS

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 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 :-) 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.

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

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

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

--
Emmanuel