Inverted colors issues with H3 devices

Question

Inverted colors issues with H3 devices

Opened this issue 8 years ago · 27 comments

I have a Sony Bravia TV and since the very beggining some models of this band and few others invert the HDMI colors if the input was not providing RGB 4:4:4 Pixel Format PC Standard (Full RGB) output.
The manufacters never updated the affected models and they won't see that as a issue. So my solution to every device I have is to output the video in RGB 4:4:4 Pixel Format PC Standard (Full RGB).

So after facing this issues I've tweked the disp_init following instructions form sunxi fex guide (http://linux-sunxi.org/Fex_Guide):
screen0_out_color_range = 1
fb0_format = 10
fb0_pixel_sequence = 0
fb0_scaler_mode_enable = 0

I'm wondering if H3 really supports this color mode. Because even with this settings I have the same issue.

This user also reported the same problem:
http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=1314&extra=page%3D1

Video of someone that has the very same tv that I have:
https://www.youtube.com/watch?v=dMzPjDTUFOU

Answer 1 · 2016-05-17T13:05:41.000Z

I've tried also with fb0_format = 12 and I have the same results.

Also with the current pull playing video gives me a black screen.

Answer 2 · 2016-05-17T18:41:28.000Z

One thing is for sure - my Kodi adaptation requires alpha channel, so setting 10 will not work (black screen at playing videos).

Setting 12 might work, if Kodi doesn't decide to change refresh rate. Basically, every time Kodi decides to change refresh rate, code for changing resolution is also called. Current problem is that in resolution changing code I hardcoded bits per pixel to 32 (never really finish this part of code). I suspect that this is the problem.

You can do a quick test:

Power off Orange Pi and disconnect it from TV
Power on Orange Pi and wait few minutes till you sure that it is fully booted
Connect back HDMI
Test video playback

That way you guarantee than only default resolution/refresh rate is enabled in Kodi.

Answer 3 · 2016-05-17T18:56:56.000Z

That makes sense. I will try that when I arrive home.

However from my experience with other devices is that this problem is not related with the refresh rate.

Does your patch affect the color range value as defined in screen0_out_color_range?

Btw: 12 actually gives black screen.

Answer 4 · 2016-05-17T19:07:56.000Z

I don't know any screen0_out_color_range variable and I can't find it in kernel source code. You mean fb0_format, right? As I said, it might get overriden, so please test scenario above with fb0_format = 12.

Answer 5 · 2016-05-17T19:31:12.000Z

https://github.com/loboris/OrangePI-Kernel/blob/0cc8d855adb457d1860d6e25cb93b6cc75d5a09d/brandy/u-boot-2011.09/drivers/video_sun7i/de_bsp/de/disp_de.c

Can be found in video driver.

Answer 6 · 2016-05-17T19:34:28.000Z

This is for U-Boot, kernel doesn't use that setting. I'm using mainline U-Boot, which doesn't have video driver.

Answer 7 · 2016-05-17T20:49:06.000Z

So with mainline u-boot there is no way to control the color range output by setting? Only the pixel format?

Answer 8 · 2016-05-17T21:18:47.000Z

As I said, mainline U-Boot doesn't touch anything related to display. By the way, you referenced sun7i family sources, but H3 is sun8i, which is AFAIK huge difference.

Anyway, kernel can and, in this case, will reinitialize all parts of display settings. Only important setting in fex file is fb0_format.

Answer 9 · 2016-05-17T22:26:08.000Z

So I've tried the plug-in plug-out method and it inverted the colors after few minutes. I'm suspecting this is related with openelec using limited RGB.

Answer 10 · 2016-05-17T22:35:04.000Z

Does this happen if you are only in menu? If it does, I can't do much...

Answer 11 · 2016-05-17T22:38:09.000Z

It happens everywhere. It is related with the framebuffer. I've seen that this openelec does not use xorg, it it runs directly on framebuffer.

Answer 12 · 2016-05-17T23:01:06.000Z

Ok, then it could be Mali driver bug. Wouldn't be the first.

Using xorg for something like this would be an overkill.

Answer 13 · 2016-05-17T23:30:52.000Z

Interesting, screen0_out_color_range is used in this h3 script of armbian:

https://github.com/igorpecovnik/lib/blob/master/scripts/h3disp

Answer 14 · 2016-05-17T23:54:29.000Z

Is HDMI CEC working in this project?

Answer 15 · 2016-05-18T06:36:34.000Z

By reading the FAQ (item 7) I would say no :(

Answer 16 · 2016-05-18T22:52:32.000Z

Well, answer in FAQ actually says that there is untested way. I will try to make proper driver in the future, especially if someone provides HDMI documentation. But this is off topic for this issue.

Answer 17 · 2016-05-19T11:03:47.000Z

Quick workaround for people suffering this problem:
If your TV has VGA and 3.5mm audio jack you can buy online, for cheap, a HDMI to VGA/3.5mm audio. It will give you 1080p.
Avoid using the composite of orange pi since it only supports PAL and NTSC.

Answer 18 · 2016-05-20T00:22:54.000Z

Some funny news:

With screen0_output_type = 2 the issue seems to be gone. So strange. But this breaks video playback.

Answer 19 · 2016-05-20T00:49:19.000Z

@jernejsk The current master is giving me black screen during video playback with default disp settings.

[disp_init]
disp_init_enable         = 1
disp_mode                = 0
screen0_output_type      = 3
screen0_output_mode      = 10
screen1_output_type      = 2
screen1_output_mode      = 14
fb0_format               = 0
fb0_width                = 0
fb0_height               = 0

fb1_format               = 0
fb1_width                = 0
fb1_height               = 0

Answer 20 · 2016-05-20T13:22:38.000Z

I'm pretty sure that all settings work as expected. I regulary test them and also at least 4 others already tested master image, at least one of them has OPiPC. How do you change fex file? Using OpenELEC build system? If that is so, then you must rebuild kernel every time you change fex file, otherwise changes will not be applied inside image or update file.

About color range: I checked code path for setting color range and I come to the following discoveries:

It can't be set in fex file
Can be changed with ioctl() call after boot
It defaults to full range for HDMI and not sure about TV

So if this is really only needed setting for you to have proper display support, either driver must be patched to take this setting from fex file or immediatelly after boot special program with ioctl call must be run.

Answer 21 · 2016-05-20T14:18:44.000Z

So I have to cleanup and do the whole kernel build again? make clean && make image ?

For ioctl which file descriptor is the mali driver? I could just make a c program that would be called during boot process everytime.

EDIT: I wonder how to you search the kernel so fast. I'm not really into linux kernel development as you may have seen.

Answer 22 · 2016-05-20T14:26:27.000Z

You can clean only kernel by:

PROJECT=H3 ARCH=arm SYSTEM=opipc scripts/clean linux

This setting is not part of GPU but that of so called Display Engine 2.0 (Allwinner term). Device is /dev/disp. Check this for ioctl interface: https://github.com/igorpecovnik/linux/blob/sun8i/drivers/video/sunxi/disp2/disp/dev_disp.c#L1730 and https://github.com/igorpecovnik/linux/blob/sun8i/include/video/drv_display.h#L101

Answer 23 · 2016-05-21T11:18:52.000Z

Checked DISP_GET_COLOR_RANGE via ioctl and it returns 1 (which is 0-255). It must be something else.

Answer 24 · 2016-07-29T14:28:32.000Z

Is your image by any chance similar to this: http://forum.armbian.com/index.php/topic/971-quick-review-of-banana-pi-m2/#entry7653 Can you switch color space on your TV?

Answer 25 · 2016-07-29T14:35:18.000Z

Yes it looks like that. On my TV I can't switch the color space. It does only happen time to time.

Answer 26 · 2017-01-18T22:32:51.000Z

Can you please pull latest sources and test the image? It is wild guess, but someone reported that adding U-Boot video driver solved his TV issues.

Answer 27 · 2017-03-18T14:10:56.000Z

I am using the compilation "kodi16.1 Git:c1c4b9e Feb 21 2017" and the error continues, from time to time they change the colors.