From: Marcus Sundberg <e94_msu@e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Tue, 14 Jul 1998 12:35:19 +0200

Re: New ggi_graphtype

Steve Cheng wrote:
> 
> On Tue, 14 Jul 1998, Marcus Sundberg wrote:
> > /* Subschemes */
> > #define GT_SUB_LSB_NORMAL     ((0x01) << GT_SUBSCHEME_SHIFT)
> > #define GT_SUB_MSB_NORMAL     ((0x02) << GT_SUBSCHEME_SHIFT)
> > #define GT_SUB_LSB_REVERSE    ((0x03) << GT_SUBSCHEME_SHIFT)
> > #define GT_SUB_MSB_REVERSE    ((0x04) << GT_SUBSCHEME_SHIFT)
> 
> libggi-issues says that subscheme aren't supposed to stand for anything by
> itself, but rather to differentiate between all the possible modes.  For
> example:
>
>                                           subscheme
>                                               v
>           sp16a16r5g5b5A1 =     GT_RGB  |  1 << 8  |  16
>           sp16a16r5g5b5A1rev =  GT_RGB  |  2 << 8  |  16
>           sp16a16b5g5r5A1 =     GT_RGB  |  3 << 8  |  16
>           sp16a16b5g5r5A1rev =  GT_RGB  |  4 << 8  |  16
>           sp16a16r5g6b5 =       GT_RGB  |  5 << 8  |  16
>           sp16a16r5g6b5rev =    GT_RGB  |  6 << 8  |  16
>           sp16a16b5g6r5 =       GT_RGB  |  7 << 8  |  16
>           sp16a16b5g6r5rev =    GT_RGB  |  8 << 8  |  16
> 
>           sp24a8b8g8r8 =        GT_RGB  |  1 << 8  |  24
>         [...]

Well, this was only one of the suggestions, and I choosed a method
that I considered cleaner. And Andrew seemed to aprove it to except
for some minor things. 

> Your method isn't technically in conflict, but in case a driver exports some
> weird mode (as you acknowledge later), we would simply be adding both
> DirectBuffer entries and subscheme entries.  On the other hand, not all such
> modes are necessarily DirectBuffers.

As I said in another mail we should adapt DirectBuffer to ggi_graphtype
as DirctBuffer needs changing anyway, not the other way around.
As we're breaking things anyway we should not think "it's bad, but that's 
the way it is". NOW is the time to change everything that is not
good.

> I think this needs to be clarified.
>
> > * Having GT_INDEXED as a flag instead of a searate scheme is also the right
> >   thing to do as you can have both indexed and non-indexed RGB, greyscale,
> >   YUV or whatever modes.
> > * The MSB/LSB part of the subscheme should cause no confusion. The
>         ^^^^^^^
> My understanding is that the subscheme will be OR'd by the target as part of
> mode negotiation.  I don't think we should have code in every target to
> detect endianess to set the appropriate subscheme.  DirectBuffer uses
> "native" and "reverse" endian which makes more sense in this case.

Detecting native/reverse endian will require MORE work in
targets than LSB/MSB. In the first case the target has to know
the endianess of BOTH the CPU and the gfx hardware. With my
suggestion it only has to know the endianess of the gfx HW.

> >   NORMAL/REVERSE part refers to RBG or BGR style pixelformats.
> >   This is the two parts that users is likely to want to change.
> 
> You don't mean changing the machine endianness, do you!? :-)

;-) Well, sort of. IIRC someone mentioned that there's gfx HW
that support both MSB and LSB pixelformats.

//Marcus