False colors on display when g2d composition is enabled on Android12 2.0.0

[OliW]

I am using the Android 12.0.0 2.0.0 in a custom i.MX8M Mini hardware. The board has 4GB of RAM and a display attached through LCDIF and a TI SN65DSI83 DSI to LVDS bridge.

On the display I can see false colors on some images (e.g. background wallpaper of the launcher or at boot animation).

I have digged down the problem and found out, that it is related to the 2D composition done in IMX graphics composer.
If I disable it via the "vendor.2d.composition" property set to 0 colors are correct.

So I digged a little further and found the following problem.
See source located in vendor/nxp-opensource/imx/display/display/Composer.cpp function "composeLayer".

There the function "blitSurface" get called to apply 2D composition:

If the source surface to this function has pixel format G2D_RGBX8888 the colors are wrong. Red and Blue channel is swapped when shown on the display.
If the source surface to this function has pixel format G2D_BGRA8888 the colors are right.
Destination surface always has pixel format G2D_RGBA8888.

For example bootsplash uses G2D_RGBX8888 pixel format and shows false colors. Rendered system UI screen use G2D_BGRA8888 and show right colors.

As the blitSurface function goes down to "libg2d-viv.so" which is a proprietary and precompiled library I cannot analyse any further now.

What could be the reason for that behaviour?
Might it be some problem on kernel driver level (unsupported pixel format conversation)? The board uses lcdif (driver unchanged) -> sec_mipi_dsim-imx (driver unchanged) -> TI SN65DSI83 DSI2LVDS bridge (this driver is not default in IMX kernel)

Does anyone know about an issue in g2d composition regarding pixel format conversion?

BTW: On our latest Android11 2.6.0 port for the board the colors are displayed correctly.

[Zhiming_Liu]

Hi @OliW 

Can you provide test case on EVK?

As you said bootsplash uses G2D_RGBX8888 pixel format and shows false colors.I can't see false colors when use ADV7535.

[OliW]

Hi @Zhiming_Liu ,

I have tested it with EVK which has a RM67191 MIPI panel connected (the only setup I have). I have used a bootanimation containing red and blue colors to see an potential color swap. But the colors are displayed correctly during the boot animation.

So I have no test case for EVK at the moment.

I will try to analyze further on our custom board which has the TI DSI MIPI to LVDS bridge (SN64DSI83). We also have another board which has a MIPI panel attached (no bridge). It shows the same false colors.

[OliW]

Hi @Zhiming_Liu ,

I have now done deep debugging. It seems that all pixel formats passed to display HAL and processed there by G2D Composer are the same on our custom board and on EVK. Also the reported modes and pixel formats from the LCDIF driver are absolutly the same. Kernel driver gets the same modes and LCDIF is set the ABGR8888 pixel format on both boards.

I have to correct my first post. All bitmaps are (boot animation screen and system UI) are passed as RGB (FORMAT_RGBA8888 and FORMAT_RGBX8888).

So I have analyzed the g2d Composer more deeply and I found some difference in how g2d output formats are converted. The magic seems to happen in "libgpuhelper.so" library, which provides a "hwc_alterFormat" function which is used in Composer.cpp -> alterFormat to evaluate the needed output surface format for g2d composing.

This function returns different values on EVK than on our custom board.

Example:

On EVK the function transforms format for output surface from G2D_RGBX8888 (2) to G2D_BGRX8888 (4). Input G2D_RGBA8888 (1) gets transformed to G2D_BGRA8888 (3).

On my custom board the same function does no transformation and leaves G2D_RGBX8888 (2) with the same value. Input G2D_RGBA8888 (1) gets transformed to G2D_BGRA8888 (3) as on EVK.

This seems to be the problem because all bitmaps without alpha channel are not converted to correctly and red and blue is swapped.

As I cannot analyze the "libgpuhelper.so" library and the "hwc_alterFormat" function because it is part of the precompiled packages NXP provides. So my possibilities to debug any further are now very limited and I cannot find out what conditions must be met that this function does correct format transformation.

[Zhiming_Liu]

This hwc_alterFormat function in A12_2.2.0 added more code for verifying surface format.

1.You can try to replace this library from A11_2.6.0 and give me feedback.

2.We can give you patched library, but this process will be very long. We will need the agreement of several departments before we can send you this library.

[OliW]

We had A11_2.6.0 running on our board and all colors on the display were correct. So I would assume that taking the lib from 2.6.0 will solve the issue.

But I see this solution as not future proof because I assume that the behaviour will not change in future versions and keeping our system fixed with the A11_2.6.0 library might break something in future and take us long again to investigate like this time.

So I would prefer to understand, what are the conditions that the library chooses this format change and to establish the same conditions on our custom board so that we stay compatible with future releases of the i.MX Android.

[Zhiming_Liu]

Hi @OliW 

We are checking this issue.

Best Regards

Zhiming