nanogui@linuxhacker.org

Jamie,
    Sorry I took so long to reply.  I've been busy, and as well,
as long as it took to come up with the PIXEL/COLOR macros
in the first place, I needed to make sure that I had enough quiet
time to study them, since they're a real mind-twister to get right.

And, you're right!  The PIXEL565TOCOLORVAL macro
shifts the 5/6/5 values into the LOW BGR color positions,
rather than using the full 8 bits per RGB.

Also, the PIXEL565RED* macros return the 5/6 bit component
values, rather than the correct 8 bit values.

Great catch, thanks for the inspection.  Would you like me
to fix them, or have you fixed them and tested them.  Perhaps
with reason, I can't get 16bpp color working on my system...
I see we've got the same problems with PIXEL332 as well.
The PIXEL888 macros are correct.

: so it seemed less work to write a new set of macros for
: "MWPF_TRUECOLOR565LE" then reworking the driver code.
:                   ^^
: Any better ideas are welcome.

I think the macros are a good idea.  Yes, we only handle the
BGR oriented rgb stuff, we probably need another set of
macros for the RGB rgb stuff....

Regards,

Greg






: (microwindows-0.88pre11)
: 
: In include/device.h, we have,
: 
: /* create 16 bit 5/6/5 format pixel from RGB colorval (0x00BBGGRR)*/
: #define COLOR2PIXEL565(c) \
:   ((((c) & 0xf8) << 8) | (((c) & 0xfc00) >> 5) | (((c) & 0xf80000) >> 19))
: 
: This takes the 5 high bits of RR and packs them into the red component 
: of the 16-bit value.  Similar for GG and BB.
: 
: Then we have,
: 
: /* create RGB colorval (0x00BBGGRR) from 5/6/5 format pixel*/
: #define PIXEL565TOCOLORVAL(p) \
:  ((((p) & 0xf800) >> 11) | (((p) & 0x07e0) << 3) | (((p) & 0x1f) << 16))
: 
: This seems to take the 5 bits of the red component and shift them
: into the *low* bits of RR.  Similar for green and blue. 
: Shouldn't the latter macro go,
: 
: #define PIXEL565TOCOLORVAL(p)   \
:  ((((p) & 0xf800) >> 8) | (((p) & 0x07e0) << 5) | (((p) & 0x1f) << 19))
: 
: so that PIXEL565TOCOLORVAL(COLOR2PIXEL565(p)) = p ?
: 
: Or more precisely, ... = (p & 0xF8FCF8)
: 
: FYI, I bumped into this while working on a driver for an Epson SED1356
: development board.  It has a little endian memory mapping, so the 5/6/5
: layout actually becomes 3/5/5/3 (G-low/B/R/G-high) when plugged into my
: PowerPC target system (MBX/821).  The development board has a switch for
: big-endian mode, but the control register addresses get byte-swapped as 
: a side-effect, so it seemed less work to write a new set of macros for
: "MWPF_TRUECOLOR565LE" then reworking the driver code.
:                   ^^
: Any better ideas are welcome.
: 
: -Jamie
: 
: p.s.
: I just noticed, the PIXEL565* macros need similar fixing if they are
: intended to return 8-bit values instead of 5/6 bit component values.
: 
: 
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: nanogui-unsubscribe@linuxhacker.org
: For additional commands, e-mail: nanogui-help@linuxhacker.org
: 
: