Raspberry Pi D0 Framebuffer Alpha

Open
#1,971 12 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
raspberry-pi
Domain
computer-graphics, embedded-iot, operating-systems

Research direction

Start by reviewing the related DRM code in vc4_plane.c at lines 1221-1267 and the behavior of framebuffer_ignore_alpha=1. Investigate whether a mailbox command or register setting controls framebuffer alpha interpretation; done means the D0 framebuffer treats RGB images with null alpha as 0xFF so lower-level OS interfaces no longer render them black or with black artifacts.

Written by the indexing model from the issue text.

Description

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.

Dominant language
No language data
Stars
5.6k
Forks
1.7k
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from raspberrypi/firmware

All issues in raspberrypi/firmware

Similar issues

More Computer Graphics issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.