Fix rgb565 / bgr565 interchange issue in Zephyr display

[ngphibang]

There is a wrong assumption about the "byte swap" in Zephyr display that makes RGB565 and BGR565 formats are used interchangeably.

This mistake (perhaps) originally comes frome the display samples that leads to the confusion in display drivers, shields, video sample. This PR fixes it.

• Fix display sample
• Fix video sample
• The NXP eLCDIF driver should not force BGR565 to RGB565.
• The rkxxx panel overlays should declare RGB565, not BGR565.

[ngphibang]

@danieldegrasse : The display format is RGB565, not BGR565. I think there are two mistakes that makes it "works" in practice for NXP display, but make it confused for others, and that impacts the video capture where we forced RGB565 to BGR565 for display.

• The rkxxx panel overlays should declare RGB565, not BGR565.
• The NXP eLCDIF driver should not force BGR565 to RGB565.

[josuah]

Taking the example of RK055HDMIPI4MA01:
https://www.nxp.com/docs/en/data-sheet/RK055MHD091A0-CTG.pdf

I did not test on hardware though.

[danieldegrasse]

Zephyr's definition of BGR_565 is unfortunately rather odd- BGR_565 corresponds to what most definitions consider RGB565, and RGB_565 corresponds to BGR_565, but byte swapped.

The only reason I can imagine we did this was that most SPI displays that use 16 bit color would use the RGB_565 format, since the byte swap would result on the data on the SPI MOSI line being in the correct order.

This comment by @zejiang0jason does a good job explaining what is going on here: #71406 (comment)

Another way to check this would be to run samples/drivers/display with this PR, you'll see that the box we expect to be gray is instead cycling through a set of incorrect colors.

[ngphibang]

@danieldegrasse : I did check with both samples/drivers/display and samples/drivers/video/capture (where we used video_sw_generator to generate RGB565 color bar patttern) and see it works correctly.

[ngphibang]

I will look through Jason's explaination but honestly, I can't understand where and how Zephyr define a RGB565 to become BGR565. If it's an issue with only NXP's displays, it should not be enforced widely in Zephyr.

[ngphibang]

Oh, just retested. Indeed, with the display sample, the colors are wrong, from top-left to bottom-left the box colors are : R -> B, G -> R, B -> G and the grey box cycling through a set of incorrect colors as you said, sorry for that (I am not too familiar with the display sample, so I didn't check carefully).

But for the video capture sample, the color bar pattern are all correct how do we explain that ?
/* Black, Blue, Red, Purple, Green, Aqua, Yellow, White */

Addressed

[avolmat-st]

Would it make sense to add a comment into the display header to describe what is the expected orderring for each format ?
Something similar to what is already available on the video side.

/*
 * 5 red bits [15:11], 6 green bits [10:5], 5 blue bits [4:0].
 * This 16-bit integer is then packed in little endian format over two bytes:
 *
 * @code{.unparsed}
 *   7......0 15.....8
 * | gggBbbbb RrrrrGgg | ...
 * @endcode
 */
#define VIDEO_PIX_FMT_RGB565 VIDEO_FOURCC('R', 'G', 'B', 'P')

With this PR merged, the LTDC is now broken since we merged the PR #92483 in the v4.2.0 release cycle in order to have LTDC behaving properly in v4.2.0. So related swap done in the PR #92483 should now be reverted I believe to have it work again.
Could you also make the revert part of this PR or do you prefer I do it on top of this one ?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ngphibang]

Would it make sense to add a comment into the display header to describe what is the expected orderring for each format ?

Yes, it's a good idea.

Could you also make the revert part of this PR or do you prefer I do it on top of this one ?

It should better be done in the same PR I think. I will do it.

[danieldegrasse]

Let's go ahead and get this moved forwards. @josuah I appreciate you creating #92343- I have an st7796s based display, which appears to need updating. I made the change here: danieldegrasse@0bce970. @ngphibang would you prefer I make a PR with that fix, or to just pull that commit into this PR?

[avolmat-st]

@ngphibang since this PR got merged yesterday I will prepare and push a PR in order to tackle the two points I raised in my previous comment, that is, adding format description and fixing the LTDC.

[ngphibang]

@avolmat-st : Sorry for the delay. I am working on it now.
@danieldegrasse : Yes, I will pick your commit. Thanks !

[ngphibang]

Here is the PR : #93805