Full range/32bpp graphics output support

[iion]

Hello everyone,
I realize that this has been raised in one form or another a number of times (here and here for example), but I would like to get info on this in a more systematic way.

I have a setup consisting of C2 and VU7 Plus. I've tried running both the latest Ubuntu and Android images and with both I get a video output that from what I can see is similar to 16 bit color per pixel. I have tested the VU7 Plus display on its own with another video source (desktop PC with AMD GPU) and it seems to work a lot better, displaying smoother gradients and color range. At the same time the C2 connected to external monitor performs in the same way and shows limited color range.

I have tried to override the color settings using the system tools of the OSes as well as editing U-Boot's boot.ini. The variables I've tried to pass there In one form or another are:

Code: Select all

setenv vout_mode "hdmi"/"dvi"
setenv video_mode   "hdmi"/"dvi"
setenv video_bpp    "32"
setenv m_bpp        "32"
setenv hdmihotplug  "1"
setenv hdmioutput   "1"
setenv vpu          "1"
setenv display_autodetect "true"/"false"
setenv hdmi_forcergb "1"/"0"

My auto-detected HDMI settings in display.bin look like this:

Code: Select all

Auto Detect OK:custombuilt,dvi(1024,600,32000,27777,43,1024,1064,1112,1152,600,613,616,645,0,0,1)

I've also read through the forums here and elsewhere that:

- Amlogic force 16 bit color by default to enable/lower the computational cost of 4K video mode
- they leave their firmware to select the bit depth/signal range based on current video content being shown

So, before I throw myself in building my custom U-Boot/OS builds, can anyone confirm, deny or add any info to the above? I'll be very grateful to anyone who could.

[iion]

To bring some progress to this - the latest armbian image compatible with C2 with kernel 3.14.79-odroidc2 also shows color banding (16-bit color). The settings in boot.ini are enabling 1024x600 VESA resolution, 32 bit color and DVI HDMI output. Could this be related to the old 3.xx kernel? Or is there any firmware I can update on the C2 board OS images? The revision of the board says v0.2 20160226.
Once again any insight into this will be appreciated.

[odroid]

Frankly speaking, my old eyes can't distinguish 18bit graphics from 24bit full RGB-888.

I think S905 GUI layer has 16 or 18bit color depth while the video rendering layer has full 24bit depth since nobody has complained the 4K video quality.
But there is no such information in their datasheet.
http://www.hardkernel.com/main/products ... &tab_idx=2

We can see a WIP Kernel 4.xx development. But any video acceleration parts don't work yet.
viewtopic.php?f=135&t=22717

[crashoverride]

can anyone confirm, deny or add any info to the above?

There are two different issues being discussed.
1) "Full range" - This is visible as gamma. The picture will either look darker or brighter than it should.
2) 16/18/32bit - This is visible as banding.

I have not tested the VU7 plus; however, every display panel in this size/cost class I have seen (and all low cost TVs) are usually 16 or 18bit LCD panels. The HDMI converter chip can also play a role in the color presented. This information should be available in the chip's datasheet. Finally, the HDMI/DVI mode will also play a role: YUV420 vs RGB color space.

On the C2 itself, the display controller can use 16bit, 24bit, and 32bit framebuffers. Applications are also allowed to choose 16, 24, and 32bit surfaces.

The easiest test is to use the latest official Ubuntu Mate 16.04 image unmodified. Connecting the C2 to a HDMI monitor (not TV) should display the desktop in 32bit without any banding. If swapping the monitor with the LCD panel results in banding, then the issue is the LCD panel. If banding is not present on either, then its possible the target application being observed is rendering 16bit.

TL;DR = I have not observed any 16bit (banding) limitations on C2 and nobody has reported such a limitation.

[iion]

odroid, crashoverride - thank you. I'll keep the investigation having in mind your notes. Currently I suspect that HDMI negotiation/setup might play a role in this, so I'm going to dig in to CEC modes and experiment more with different OSes and monitors. Still, VU7 is my target display for now, since I want to add it to my car and 7 inch display with this ratio will be a direct replacement for the old 10+ year old navigation screen that is in there. As I wrote and double-checked today, using VU7 as a second HDMI monitor on an PC/Laptop shows no color banding or issues of any kind. It is not the best display ever, but the image is very decent with good angles and saturation.

[iion]

To bring some update to this - the issue I was seeing could be resolved by changing a piece of code, related to HDMI color range settings. The current code in the Android code tree of Odroid-C2 forces limited color range through conditional addition of a bitmask vaulue that always evaluates to 'false'. The code is located in './kernel/drivers/amlogic/hdmi/hdmi_tx_20/hw/hdmi_tx_hw.c' while the possible values of the enum type used for the evaluation is defined in './kernel/include/linux/amlogic/hdmi_tx/hdmi_common.h'.

The patch necessary for the change is attached to the post. The end result after running the newly compiled Marshmallow image is that the VU7+ display shows identical image quality when HDMI feed comes from C2 and external feed (laptop,desktop). While banding is still visible in large area similar-colored gradients, it is not as noticeable as before and I can live with it and well... it is not going to get any better Please, note that photos/static images look fine, but video in browsers is horrible in terms of banding. At the same time video through VLC looks great with no visible artifacts.

As far as I can tell, the fix is the same as the one outlined a while ago in this post - viewtopic.php?f=135&t=26003

[rooted]

Can you share your pre-compiled image? I have the VU7 which is for an in car display powered by a C2.

I don't really want to compile Android on my old laptop just to test this, but I do want to compare the change to the Hardkernel image.

[iion]

Here is a link to the selfinstall-odroidc2.bin image from the 'out/target/product/odroidc2/' folder - https://drive.google.com/open?id=1pcy_t ... dZOzJSqx2p. I'm using 'dd if=./selfinstall-odroidc2.bin of=/dev/mmcblk0 bs=512 conv=fsync status=progress' to flash the .bin image to an sdcard and then invoking 'sync' several times, but I believe Etcher can be used as well to do the same.

Couple of things about this image:

1. I believe the recovery image in this set might be incomplete/broken, because the '/bin' folder in it contains just 'busybox' and 'mk_e2fs'. The softlinks to busybox for each of the standard commands in '/out/target/product/odroidc2/utilities/busybox/bin/' where the 'busybox' entry of the recovery is taken from seem to get created later in the build process. I'm working around this for the installation process by patching the Edify script for the install process which resides in '/device/hardkernel/odroidc2/recovery/' - the patch file is attached.

2. GApps install on this image fails in recovery phase. I haven't checked the details yet, but could be related to the above.

[rooted]

Thanks for the link and information, I look forward to testing it out.

[iion]

An update - I was able to resolve the recovery image problem properly (fixed all busybox softlinks as part of the build process) and this also took care of the GApps not installing. For anyone interested in building the image - please, take a look at this thread I've started - viewtopic.php?f=137&t=31875

[joy]

Hi iion,
Thank you for the update.
I will check your patch related to hdmi full range.

[rooted]

Hi iion,
Thank you for the update.
I will check your patch related to hdmi full range.

Was this ever implemented?

[joy]

Hi iion,
Thank you for the update.
I will check your patch related to hdmi full range.

Was this ever implemented?

No.
I didn't share the issue's status. Sorry for that.
At that time, we've tested recovery display with iion's patch,
https://github.com/iiontihy/odroid-c2-m ... -hdmi.diff
but still display gradation was shown.
So the commit wasn't merged.

Do you want me to check it again with current version?

[rooted]

Hi iion,
Thank you for the update.
I will check your patch related to hdmi full range.

Was this ever implemented?

No.
I didn't share the issue's status. Sorry for that.
At that time, we've tested recovery display with iion's patch,
https://github.com/iiontihy/odroid-c2-m ... -hdmi.diff
but still display gradation was shown.
So the commit wasn't merged.

Do you want me to check it again with current version?

Yes it's not 16/18bit vs 24bit color that is my problem. It's the full range darkness or gamma, it's hard to describe what I see on my 4K display.

Simply put my display is darker than it should be, like too much dynamic range or not enough. May be that my display is HDR capable but that's just guessing.

If you build it I can test if it makes a difference.

[joy]

Yes it's not 16/18bit vs 24bit color that is my problem. It's the full range darkness or gamma, it's hard to describe what I see on my 4K display.
Simply put my display is darker than it should be, like too much dynamic range or not enough. May be that my display is HDR capable but that's just guessing.
If you build it I can test if it makes a difference.

OK. Good.
I will build a kernel with the patch, then share a kernel image here.
Please test the commit.
I think I'm available late this week or early next week.

[rooted]

No rush, I will test it and let you know once you make it available.

I am currently running Android which is why I didn't build the kernel, I didn't think about building and testing on Linux.

[joy]

Hi rooted,
I made a new Android kernel and dtb images of the latest C2 android marshmallow with iion's patch.
Please fine the attachment, "c2_fullcolor_range_20190215.tar.gz.

Code: Select all

diff --git a/drivers/amlogic/hdmi/hdmi_tx_20/hw/hdmi_tx_hw.c b/drivers/amlogic/hdmi/hdmi_tx_20/hw/hdmi_tx_hw.c
index 3775674..d1ad938 100644
--- a/drivers/amlogic/hdmi/hdmi_tx_20/hw/hdmi_tx_hw.c
+++ b/drivers/amlogic/hdmi/hdmi_tx_20/hw/hdmi_tx_hw.c
@@ -4116,7 +4116,15 @@
 	hdmitx_wr_reg(HDMITX_DWC_FC_AVICONF2, data32);
 
 	data32  = 0;
-	data32 |= (((0 == hdmi_color_range_FUL) ? 1 : 0) << 2);
+	/******************************************************************
+	 * D.Dimitrov - the original commented out condition below
+	 * will always be false since 'hdmi_color_range_FUL'
+	 * is the second element in the enum hdmi_color_range.
+	 * Forcefully setting this to '1' to enable
+	 * unconditional full color range over HDMI (fingers crosed)
+	 * data32 |= (((0 == hdmi_color_range_FUL) ? 1 : 0) << 2);
+	 *****************************************************************/
+	data32 |= (1 << 2);
 	data32 |= (0 << 0);
 	hdmitx_wr_reg(HDMITX_DWC_FC_AVICONF3,   data32);

You can update them using fastboot.
Could you check it with your monitor?

And recent several month, I don't build Android full image,
If you want me to provide a self-install image including for test, could you let me know?

Also if you need to test the patch on recovery stage without a new self install image,
you can use the following commands on u-boot stage.

Code: Select all

movi read dtb 0 ${dtbaddr}
movi read recovery 0 ${loadaddr}
bootm ${loadaddr}