I am using an STM32H7A3ZI and am seeing some unexpected behavior with the LTDC color keying in L8 mode.
Setup:
- 2-layer mode.
- Layer 1 (background) is fully opaque
- Layer 2 (foreground) has CLUT configured such that pixel value 0xFF maps to RGB (0,0,0), the desired transparent color
- Layer 2 framebuffer (L8 format) has 0xFF for transparent locations, other values elsewhere
The reference manual says this:
If the color keying is enabled, the current pixels (after format conversion and before CLUT respectively blending) are compared to the color key. If they match for the programmed RGB value, all channels (ARGB) of that pixel are set to 0.
and
In all CLUT-based color modes (L8, AL88, AL44), set one of the palette entry to the mid-yellow color 0x808000 and set the LTDC_LxCKCR to 0x808000.
The first paragraph is somewhat vague ("CLUT blending" - does it mean "CLUT conversion"?), but the second example is clear enough - it implies that the transparency color is compared after CLUT lookup.
So I would expect that setting LxCKCR= 0x00000000 would make RGB=(0,0,0) transparent, regardless of its CLUT index.
That's not what I'm seeing. The pixel value 0xFF (with CLUT value=(0,0,0)) is appearing as black, not transparent.
If I set LxCKCR=0x00FFFFFF, then it is transparent.
So that implies the color keying is being applied to the L8 (index) value, before CLUT lookup.
Some other experiments:
- setting LxCKCR=0x000000FF does not make 0xFF pixels transparent. So the color keying comparison seems to be done on a replicated L8 value
- Setting LxCKCR=0x00FEFEFE and using 0xFE as the transparent pixel instead works.
- setting LxCKCR=0x00000000 and using CLUT index 0 (so pixel 0x00) as the transparent color instead works.
So is the documentation wrong, does the HW have a bug, or am I missing something?
