jerpelea opened a new pull request, #19689:
URL: https://github.com/apache/nuttx/pull/19689
## Summary
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
## Impact
RELEASE
## Testing
CI
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
