From: Emmanuel Marty <core@suntech.fr>
  To  : ggi-develop@eskimo.com
  Date: Mon, 06 Jul 1998 08:56:52 +0000

Re: Last kgicon update before it goes in CVS

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. About the include dir, can it be folded under
kgicon or is it really a seperate entity? :)

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.

> > > * Code up assembly-optimized sotware text rendering routines.
> >
> > I'll take care of that when I have a second. It can already use some
> > C optimization for all platforms too.. (not your code, fbcon I mean)
>
>         There is a lot of tuning and speedups in lots of places that can
> be done.  As soon as I get the !@#$% Trio driver to do acceleration
> properly in MMIO mode I will get to work on that end of things.

Allright :) I'll try to come up with an assembly text rendering routine
as soon as feasible. Probably optimized for 8 and 9 pixel wide fonts
too. Text rendering is one of the areas where planar modes (see other
discussion) is way way better, since you can write text in any color
by just selecting planes, with eight times as less writes for a 8-pixel
wide font for example. So x86 can use some optimization :)

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

I have a 68K, a PPC and an Alpha system at home so I can do some testing,
but most of my coding time is spent on the x86 machines as well.. My
MC68040/25 is somehow slow by today's standards (even if I love that
amiga to bits :), the ppc box is a twin 603/66 mhz bebox which doesn't work
too well with Linux (it only uses one cpu :(), and the Alpha.. mm, nothing
to object to that one, except it's contemporary to 486's (21064A, 275 mhz) :)

--
Emmanuel