raspberrypi
Raspberry Pi D0 Framebuffer Alpha
In the process of trying to port edk2 over to the D0 version of the Raspberry Pi 5, I discovered that the firmware framebuffer is interpreting RGB images with no alpha explicitly set (null alpha) as an alpha value of 0, rather than an alpha value of 0xFF (100% opacity). It was easy to edit the code in edk2 to fill alpha with 0xFF on all write operations, but once the framebuffer is handed over to the OS I can’t control the framebuffer and many lower level OS’s do not handle pre-multiplication processes internally. Higher level OS’s that premultiply internally and always return 100% opacity to the Pi work without issue, but lower level OS’s that use only RGB images in their UI (ESXi) appear black and others that have a mix of RGB and RGBA elements will have black artifacts anywhere that an RGB only UI element exists. Framebuffer_ignore_alpha=1 has no effect.
Is it possible to have the firmware framebuffer interpret null alpha as 100% instead of 0 to resolve this? Is there a mailbox command or register setting that would change the state? I can see the related DRM code in vc4_plane.c #L1221-L1267 that shows that there is a hardware distinction and I’m hoping that there is a way to address this issue.
The earlier C1 version has none of the issues I mentioned above.
As you've noted from https://github.com/raspberrypi/linux/blob/rpi-6.12.y/drivers/gpu/drm/vc4/vc4_plane.c#L1242-L1292, D0 sets up alpha slightly differently from C1 in the dlist. That change hasn't been reflected in the bootloader.
I'll see if I can create a suitable change tomorrow.
Yes, exactly, I was referencing an older version. Thank you for the quick reply and for your effort.
Does it look like there may be a feasible workaround or do you still need to find time to look at it?
I have a patch, but need to find a few minutes to test it. I can throw it on here if you want to test it.
Yes, that would be great. I have time to test it. I personally only have access to a CM5 and CM5 Lite at the moment, if that makes a difference.
Hi, just following up to see whether you have a copy I can test and how I can obtain it. Thanks again.
Sorry, I've been out of the office since Thursday.
Updated fw attached. Extract to a blank SD card with FAT partition, and reboot. After about 5 secs you should get the power light flash repeatedly, and any attached HDMI display should go totally green. Power down, swap back to your normal boot device, and test.
Alternative installation instructions that don't require another SD card:
- Extract to a scratch directory.
cdto the scratch directory.sudo rpi-eeprom-update -f pieeprom.bin- Reboot.
Tested in all OSs where I previously had issues and can confirm that all now appear as expected, including both those with mixed RGB/RGBA elements (previously black artifacts) and no RGBA elements (previously blank). Will this end up being included in a main firmware update and in the meantime is it safe to refer any users to the included firmware (or is this still a WIP)? I assume it is otherwise up to date with the May 8 update.
I hadn't created the internal merge request for the patch as I hadn't had a chance to test.
Based on your report of it working, I have now created that, and I'd expect it to be merged and available in the next rpi-update release (the commit text in https://github.com/raspberrypi/rpi-firmware should reference the change). It'll percolate through to apt eventually, although it sounds like that doesn't affect you.
And I wouldn't recommend you pointing users at test releases from issues/PRs as they will become out of date fairly quickly and hence potentially cause other issues.