s905 - hdmi handshake /color space problem with older TVs

witokondoria · September 13, 2016 at 10:11 PM

I have been unable to test this build, but I can assure my patches solved the problem 100% on a Philips PFL9664. Could be that hdmi_tx_14/hdmi_tx_video.c also needs the changes from hdmi_tx_20/hdmi_tx_video.c commited on drivers/amlogic/hdmi: make output_rgb a device parameter · kszaq/linux@67f076b · GitHub ?

At least my TV doesnt have HDMI 2.0, so the naming could make sense.

@kszaq, wdyt? hdmi_tx_14 is used under hdmi 1.4?

**mmpp** · September 14, 2016 at 5:08 AM

witokondoria I think you are right. The patches I have seen for the odroid-c2 change both hdmi_tx_20 and hdmi_tx_14. Good catch!

**kszaq** · September 14, 2016 at 6:47 AM

hdmi_tx_14 is not used for S905(X): linux.aarch64.conf#L821

witokondoria · September 18, 2016 at 9:28 AM

Its also still happening on my TV. What I have seen is that whilst the screen is wrecked, echoing the same 1 to /sys/class/amhdmitx/amhdmitx0/output_rgb, as it recalls hdmitx_set_display, the colors go back to normal.

Could make any sense that the first time hdmitx_set_display is called, as hdmi_output_rgb is 0, the tvs gets to an "unstable hdmi mode" where even resetting the display mode wont fix it?

What about trying to replace

Code

if(hdmi_output_rgb){  param->color = COLOR_SPACE_RGB444;
}

with something as

Code

if(readFromAttr(output_rgb == 1)){
param->color = COLOR_SPACE_RGB444;
}

at linux/hdmi_tx_video.c at 67f076b4c76fe508457d5c4eccfe08ce6885ae41 · kszaq/linux · GitHub?

PS: I thing the post title should not contain the [SOLVED] tag.

**kszaq** · September 21, 2016 at 8:33 PM

I removed the SOLVED tag.

I also modified my kernel patch to work more like Odroid's solution, by calling hdmitx_output_rgb() on property write - this should keep output_rgb value between resolution change calls.

When I solve sound issues with the latest kernel, I will post a dev build for you to test.

**mmpp** · September 21, 2016 at 8:49 PM

Hi,

as I need to get another box for the basement anyway: did anyone notice the bug with the S905X SoC?

**kszaq** · September 25, 2016 at 2:30 AM

Please test a build with different approach on setting output_rgb: 2016-09-25-devel

**mmpp** · September 25, 2016 at 2:15 PM

Quote from kszaq

Please test a build with different approach on setting output_rgb: 2016-09-25-devel

Thank you for keeping up with this annoying bug. I had only limited time to test, but the new version changed the appearance of the bug:

Before, the TV would continue to stay pink once the bug was triggered, and only switching hdmi input (or pulling the hdmi cable) would reliably switch it back to normal colors. In the new version, the pink bug still appears, but after 0.5s the screen goes black and returns to normal colors on itself. I will continue testing and also check dmesg for anything out of the ordinary.

**kszaq** · September 25, 2016 at 10:47 PM

I'm afraid I just noticed that an updated version of my patch didn't make it into the development build. I will upload a new build soon.

**kszaq** · September 28, 2016 at 7:56 PM

Please try the latest development build - I have added a revised way to switch output_rgb: 2016-09-28-devel

Remember to use updated device tree to avoid audio issues.

Patch used: drivers/amlogic/hdmi: make output_rgb a device parameter · kszaq/linux-amlogic-le@4fd3d70 · GitHub

**mmpp** · September 29, 2016 at 7:18 AM

Hello,

thank you for providing the new version. The /sys node is no longer readable, but I could still write to it. The echo command is in my autostart file.

I tested last night for a few hours. Sadly, the problem still occurs, with no apparent trigger or regularity. During longer movies, it appears about once every 30 minutes. Sometimes the pink color stays, sometimes the screen goes black a few seconds later and normal colors return.

Current workaround: Setting the GUI to 720p60 forces a resolution change when "Back" is pushed during playback of most of my content. This also removed the pink color during my tests yesterday, but I am not sure if that is reliable.

**kszaq** · September 29, 2016 at 8:03 AM

mmpp Can you please test this build: LibreELEC-S905.aarch64-7.0-devel-20160929083522-r23358-gbac9202.img.gz

**mmpp** · September 29, 2016 at 3:42 PM

Preliminary tests are very promising. I ran this release for several hours and did not see the pink bug. I will continue testing.

**kszaq** · September 29, 2016 at 5:57 PM

Thanks. Please let me how how did further testing go.

envagyok · September 29, 2016 at 8:21 PM

Quote from kszaq

Please try the latest development build - I have added a revised way to switch output_rgb: 2016-09-28-devel

Remember to use updated device tree to avoid audio issues.

Patch used: drivers/amlogic/hdmi: make output_rgb a device parameter · kszaq/linux-amlogic-le@4fd3d70 · GitHub

Possible can we switch output mode with this version?
Is it menu?
Or other way can we set up?

**mmpp** · September 29, 2016 at 9:27 PM

Quote from envagyok

Possible can we switch output mode with this version?
Is it menu?
Or other way can we set up?

From the thread for the latest release (LibreELEC)

Quote
added a possibility to force RGB output by
Code
echo 1 > /sys/class/amhdmitx/amhdmitx0/output_rgb

I made an autostart.sh with this command.

**mmpp** · September 30, 2016 at 7:35 AM

Quote from kszaq

Thanks. Please let me how how did further testing go.

My TV ran non-stop yesterday, with the astra UHD channel demo reel during the day and me checking the picture periodically. In the evening I used the box actively and watched movies and some episodes of a series. No pink color showed up. Not even once.

I am very happy and for me the problem seems to be gone. Hooray!

witokondoria: Please try this version with your TV as well.

**kszaq** · September 30, 2016 at 7:55 AM

mmpp Thank you for testing. I will forward this patch upstream.