Here are some details about a color issue seen on i.MX8MQ when using the DCSS. This issue can only be seen on displays using DCSS (HDMI & MIPI), but everything is ok when using MIPI with LCDIF.
- i.MX8MQ NXP EVK platform
-> also tested on Boundary Devices Nitrogen8M, same results
- Linux Yocto 4.9.88_2.0.0 GA pre-built image from NXP
-> also tested latest 4.9.123 for i.MX 8MMini GA release hoping for DCSS improvement but the issue is still seen
-> also tested on Android O8.1.0 for i.MX 8MQuad GA
- Display can be HDMI monitor or MIPI display, as long as it is using DCSS
The colors are darker than expected, it is like an alpha layer is added on top the image to be displayed.
Comparing MIPI display colors switching between DCSS and LCDIF setup makes it obvious.
Another approach to compare the colors is to use GStreamer on Linux and switch between waylandsink (GPU composition, DCSS channel 1, global alpha set to 255) and kmssink (no GPU involve, DCSS channel 2 no alpha).
See attached pictures although they don't do the issue justice as it is even more obvious in real life.
How to reproduce
On Linux, as mentioned above, the easiest is to use GStreamer and compare the output when using kmssink vs. waylandsink.
Below are the commands used to generate the pictures attached.
gst-launch-1.0 videotestsrc ! "video/x-raw,width=1920,height=1080" ! kmssink
gst-launch-1.0 videotestsrc ! "video/x-raw,width=1920,height=1080" ! waylandsink
gst-launch-1.0 videotestsrc pattern=red ! "video/x-raw,width=1920,height=1080" ! kmssink
gst-launch-1.0 videotestsrc pattern=red ! "video/x-raw,width=1920,height=1080" ! waylandsink
gst-launch-1.0 videotestsrc pattern=green ! "video/x-raw,width=1920,height=1080" ! kmssink
gst-launch-1.0 videotestsrc pattern=green ! "video/x-raw,width=1920,height=1080" ! waylandsink
On Android however, since all the composition is done through the GPU, everything goes out on DCSS channel 1 and therefore it always looks dark. The only way to compare is to use MIPI output and switch between DCSS and LCDIF.
Debugging the issue
Since it seems to be alpha related, some debugging was done to understand the DCSS DTG setup from the Linux driver.
Reading the DTG Timing Controller Control Register (TC_CONTROL_STATUS, 0x32E20000), it seems that:
- by default the driver uses global alpha setting set to 255 and the pixel format is DRM_FORMAT_XRGB8888:
- changing the TC_DEFAULT_OVERLAY_ALPHA to a value lower than 255 makes the colors even darker (as alpha component is added, that is normal behavior):
0x8000518c = much darker colors
0x0000518c = black screen
(note that Android uses DRM_FORMAT_ABGR8888 pix format but still uses global alpha, tried using per-pixel alpha but it gave the same result)
The above values confirm that the channel 2 & 3 are disabled in a normal setup (just running Weston).
When using kmssink, the driver does the following:
TC_CONTROL_STATUS = 0xff00518c
1- enables channel 2 (DRM_FORMAT_NV12)
2- sets alpha for channel 1 (DRM_FORMAT_XRGB8888) to 0 (basically black plane)
3- disables channel 1
TC_CONTROL_STATUS = 0x0000518a
(stays like this until the pipeline is done or cancelled)
4- sets alpha for channel 1 (DRM_FORMAT_XRGB8888) to 255
5- enables channel 1
6- disables channel 2
TC_CONTROL_STATUS = 0xff00518c
So it seems that as soon as DCSS channel 1 is enabled the colors are darker, maybe another setting needs to be set in order to completely remove the alpha (or bypass the blender).
At this point, we need assistance from NXP DCSS experts as this issue is blocking for many customers.