RGBTO8 shifted each component up before masking:
(((uint8_t)(r) << 5) & 0xe0)
The cast is promoted to int before the shift, so the mask keeps bits 5:7
of the shifted value, which are bits 0:2 of r. The macro therefore
encoded the three least significant bits of red and green and the two
least significant bits of blue, rather than the most significant.
This disagrees with RGBTO16 in the same file, which correctly takes the
high bits, and with RGB8RED/RGB8GREEN/RGB8BLUE immediately below it,
which are documented as the inverse transformation but read the result
as high bits.
All in-tree callers pass full 8-bit components, so all were affected:
RGBTO8(39, 64, 139) in apps/examples/nxterm, intended as midnight blue,
evaluates to 0xe3 -- full red plus full blue, i.e. magenta.
Take the high bits instead, so that RGBTO8 matches RGBTO16 and the
RGB8xxx macros become its true inverse.
Tested on a RISC-V LiteX/VexRiscv target with an 8bpp RGB332 frame
buffer, and with a host round-trip check over all 256 representable
colours.
Assisted-by: Claude:claude-opus-5
Signed-off-by: William Byatt <william@byatt.io>
a6b45dd471