09_framebuffer example uses BGR rather than RGB on latest firmware

[petemoore]

On previous firmware, the 09_framebuffer example worked perfectly, however, on recent firmware, it looks like RGB pixel order isn't supported for some reason, so homer appears cyan rather than yellow.

The Mailbox property interface wiki page says "The response may not be the same as the request so it must be checked." for tag 0x00048006. I added a check to test the value of mbox[24] after the mailbox call, and indeed the value returned is 0, suggesting that the pixel order option of 1 wasn't accepted. I'm not sure why.

I also tried setting all the tag request codes to 0 (mbox[4], mbox[9], mbox[14], mbox[19], mbox[23], mbox[27], mbox[32]) to see if that would help, but it didn't. I also tried changing the order of the tags, but that didn't help either.

It seems like RGB maybe isn't supported now for the given screen dimensions/colour depth etc, or maybe this is a firmware bug, I'm not sure. But the code probably should check the value of mbox[24] and if it is 0, populate the framebuffer using BGR instead of RGB.

[bztsrc]

Hi Pete,

Thank you for reporting! I don't know why isn't the mbox order work any more, but I think I should simply change the channel order to BGR then. (In all my other projects I'm already using BGR only.) Checking the response seems reasonable too.

Cheers,
bzt

[bztsrc]

the code probably should check the value of mbox[24] and if it is 0, populate the framebuffer using BGR instead of RGB.

Because this supports the old firmware, as well as the new, and it will also work when they fix the firmware, I decided to use this method.

Cheers,
bzt

[petemoore]

Thanks @bztsrc!

Note, I created https://github.com/petemoore/redscreen to demonstrate the problem and reported it.

I'm still a little baffled because I'm pretty sure it used to work, but I tried many older firmware versions and can never get it to work. Can you tell me if you experience the same issue on your rapsberry pis or in qemu? I'm wondering if there is something strange with my hardware that is causing the issue, or if everyone is now having the same problem as me. Many thanks!

[bztsrc]

Hi,

I can confirm that channel order is not set. I can't tell you exactly when the firmware change happened, I've first noticed it about a year ago maybe? When I created the repo about two years ago it was working for sure. This issue was first reported in May last year, back then I decided to leave it as is, see if it pops up for others. Now that you have reported it too, I felt it's time to implement a solution.

When this first appeared, I've checked it in qemu, and the emulation is not 100% correct (or it was not back then). It seems to me that channel order is always the same as the host system's, no matter what you put in the mailbox. Haven't checked this recently.

TBH I don't check these tutorials all the time, I do most developments in my bootloader project, https://gitlab.com/bztsrc/bootboot/blob/master/aarch64-rpi/bootboot.c#L916 . I've originally created these tutorials by separating code snippets from that project, and then I tried to reduce complexity to make them simpler and more understandable. Unfortunately my loader always preferred blue as the least significant byte, as that's more common, so that code does not help here.

Cheers,
bzt

[JamesH65]

AIUI, there are only two options here, so just for reference...

0x0: BGR
0x1: RGB