{bp-19685} video/rgbcolors: Fix RGBTO8 to use the high bits of each component. - #19689
Open
jerpelea wants to merge 1 commit into
Open
{bp-19685} video/rgbcolors: Fix RGBTO8 to use the high bits of each component.#19689jerpelea wants to merge 1 commit into
jerpelea wants to merge 1 commit into
Conversation
xiaoxiang781216
approved these changes
Aug 5, 2026
github-actions
Bot
added
Size: XS
Contributor
Author
|
PLEASE DO NOT MERGE |
cederom
approved these changes
Aug 5, 2026
linguini1
approved these changes
Aug 5, 2026
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
RGBTO8 shifted each component up before masking:
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