It looks as though the bits are masks and not passes, i.e.
0xFF0000 will mask out the red channel (allowing 0x00ffff
(i.e., cyan) to pass thru), etc.  magenta is green's complement,
and yellow is blue's complement.

Try:
#define RED_MASK 0xFF0000
#define GREEN_MASK 0x00FF00
#define BLUE_MASK 0x0000FF

and work with those.


-----Original Message-----
From: David C. Myers [mailto:myers@iname.com]
Sent: Thursday 06 January 2000 11:32
Cc: port-sparc@netbsd.org
Subject: Re: Observations about Xsun24




> All three primaries work correctly in your small test-scribbling
> program, I take it, so it's not the hardware?  Perhaps the pixel fields
> are wrong, and the green primary got switched with the spare byte?  Or
> is the hardware really three addresses per pixel instead of four?  (All
> the above assumes it's four bytes per pixel as far as addressing goes.)


Well, all three primaries do work, but not in the way I expected.  Which
is the subject of another good question, so at the risk of testing
anyone's patience, I'm going to ask it...

I always thought that the following color definitions would apply:

#define RED 0x00FF0000
#define GREEN 0x0000FF00
#define BLUE 0x000000FF

And yet, if I blast those into my framebuffer, I actually get cyan,
magenta, and yellow.
Could this be why my colors aren't displaying right?  

Or am I just wrong about these color values from the start?

By the way, it does not matter at all what you put into the upper eight
bits of the color value.  Thus I assume the hardware maps all 32 bits,
but only cares about 24 of them.  In my device driver, I set the fb_size
value to (4 * 1024 * 1024), and the bit depth to 24.

-David.