From: Johan Karlberg <wlfshmn@failure.ml.org>
  To  : ggi-develop@eskimo.com
  Date: Thu, 13 Aug 1998 00:06:08 +0200 (CEST)

Re: Graph types...

On Wed, 12 Aug 1998, Marcus Sundberg wrote:

> > > >  we define a couple of graphtypes, but for exampl GT_16BIT, what IS 16 bit?
> > > >  is it a 5-5-5-1 (XGA) mode, a 5-6-5 (TARGA) mode, or even a 6-6-5 RGB
> > > >  mode?
> > > 
> > > It depends on the hardware.  The mode could be RGB 5:6:5 or 6:6:4 or
> > > 5:7:4, with or without byte swapping (e.g. little endian card in a big
> > > endian machine).  Once you set the mode, you can query the format with
> > > the ggiGetPixelFormat() function or via the DirectBuffer interface.
> > > 
> > Ok, and what should be set as default in a RAMDAC driver then? Since the
> > ramdac has to set different multiplexing values for each? Since we don't
> > support Overlay, that's not a problem, I'll discount those modes, but, a
> > 565 mode would then be more exact I assume...
> 
> Please note that the KGI API still uses the old, limited and VGA
> centric graphtype scheme which only defines GT_1/4/8/15/16/24/32BIT
> and GT_TEXT16/32.
> 
> Whereas libggi uses a new system where a graphtype is made up of
> depth (number of significant bits), size (physical pixelsize), a
> "scheme" (palette/truecolor/grayscale/text) and a "subscheme"
> (endianness and such), where the GT_??BIT modes are just some
> common predefines.
> 
> Look at degas/include/ggi/types.h in the devel CVS to see the new
> graphtype API.
> 
> Btw, I hope that the graphtype system in Steffens new KGI API is
> more flexible than in the current KGI(s).
> 

OK, this dounds good to me, and rather trival to implement into drivers,
atleast those I'm familiar with, let's all hope Steffen has something
similar in mind.

Johan