From: Hartmut Niemann <niemann@cip.e-technik.uni-erlangen.de>
  To  : ggi-develop@eskimo.com
  Date: Tue, 14 Jul 1998 16:34:23 +0200 (MESZ)

Re: New ggi_graphtype

Steve 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
>           sp24a8b8g8r8 =        GT_RGB  |  1 << 8  |  24
> 	[...]
> 
> 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.
> 
> I think this needs to be clarified.
IMHO the direct buffer entry should be folded into this new graphtype.
All you need to do is define all necessary subschemes.
Whether the sub scheme numbers (we currently have 255 of them, plus
'I don't know/don't tell you') are allocated in some systematic way or
as enumerations does not matter at all.

I would simply #define the sp* as graphtypes with ascending subtype number.


Hartmut.
--  
Hartmut Niemann   --   niemann(a)cip.e-technik.uni-erlangen.de
http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi]