Bug 110496

Summary: [GLK] no signal - with samsung 4k TV - HDMI UHD Color (ENABLED)
Product: DRI Reporter: Piotr Kasp. <piotr.kasprzak>
Component: DRM/IntelAssignee: shashank.sharma <shashank.sharma>
Status: RESOLVED MOVED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: high CC: gary.c.wang, intel-gfx-bugs, ramalingam.c, sergey79, shashank.sharma
Version: DRI git   
Hardware: x86-64 (AMD64)   
OS: All   
Whiteboard: Triaged, ReadyForDev
i915 platform: GLK i915 features: display/HDMI
Attachments:
Description Flags
NUC with UHD color enabled at 1080p then I switch resolution to 4k
none
4k@60 enabling hacks
none
4k@60 enabling hacks
none
edid-samsung(QLED)-disbaled_HDR_support
none
edid-samsung(QLED)-enabled_HDR_support
none
drm_debug_HDR_enabled.log
none
drm_debug_HDR_disabled.log
none
EDID - UHD Color on
none
EDID - UHD Color off
none
Chroma subsampling test in 4k60 non UHD Color mode
none
MU7000 manual - UHD colour modes none

Description Piotr Kasp. 2019-04-22 16:26:20 UTC
Created attachment 144072 [details]
NUC with UHD color enabled at 1080p then I switch resolution to 4k

Hi
For some reason on Gemini Lake NUC - NUC7CJYH
Latest DRM-tip kernel - latest firmware in Samsung QLED 2018
There is no signal if "HDMI UHD color" is enabled for HDMI where is NUC connected


Here log where is HDMI UHD Color enabled (no signal on TV)
http://ix.io/1GSD

Here where HDMI UHD Color is Disable (no problem)
http://ix.io/1GSG


I Discover its working when is UHD color Enabled and 1080p resolution 
but when you switch to 4k signal gone :( 
I Attached log where I boot NUC with UHD color enabled at 1080p then I switch resolution to 4k and signal gone




EDID: http://ix.io/1GSV
Comment 1 Ville Syrjala 2019-04-23 14:30:13 UTC
Please attach logs/etc. directly to the bug. Otherwise they may be lost and then the bug report is useless.
Comment 2 Lakshmi 2019-04-29 05:27:09 UTC
@Ram, any comments here?
Comment 3 Ramalingam C 2019-04-29 05:54:59 UTC
@lakshmi,
Based on the observations shared, for me it looks like an issue with deep color at 4k. Ville might have insight into this issue.
Comment 4 Ramalingam C 2019-04-29 11:13:06 UTC
@shashank for analyzing the issue. Adding him for the comment here.
Comment 5 shashank.sharma@intel.com 2019-04-29 11:45:16 UTC
Created attachment 144106 [details] [review]
4k@60 enabling hacks
Comment 6 shashank.sharma@intel.com 2019-04-29 11:46:09 UTC
Created attachment 144107 [details] [review]
4k@60 enabling hacks
Comment 7 shashank.sharma@intel.com 2019-04-29 11:46:18 UTC
I was working with Piotr in a parallel thread, and I could root cause the problem while handling deep color stuff.
- When we allow the CMDB modes to be treated as 4:2:0 modes (rather than RGB) && - we don't allow the deep color output (12 BPC)
we could see both 4k@30 and 4k@60 displays. 

I will add some more findings here. Meanwhile, adding patches which we used to enable 4k@60.
Comment 8 Piotr Kasp. 2019-05-29 19:41:16 UTC
there are any news ? or something what we can test it ?
Comment 9 shashank.sharma@intel.com 2019-05-31 06:22:56 UTC
There are 2 new patches merged in drm-tip with which we are able to see 4k@60 outputs on both GLK and ICL. Can we please confirm this observation ? 

- Shashank
Comment 10 Piotr Kasp. 2019-05-31 21:26:30 UTC
Created attachment 144399 [details]
edid-samsung(QLED)-disbaled_HDR_support
Comment 11 Piotr Kasp. 2019-05-31 21:29:18 UTC
Created attachment 144400 [details]
edid-samsung(QLED)-enabled_HDR_support
Comment 12 Piotr Kasp. 2019-05-31 21:33:12 UTC
ok I tested latest drm-tim from today and nothing was fixed :(
yes 4k@50 or 60 working but with disabled HDR (what samsung calling UHD colors)

I attached for other 2 EDID (sorry by mistake thay had opposite name enabled actual I disabled etc.)

and I will attach 2 logs - one with enabled and one with disabled HDR support on TV
Comment 13 Piotr Kasp. 2019-05-31 21:35:15 UTC
Created attachment 144401 [details]
drm_debug_HDR_enabled.log
Comment 14 Piotr Kasp. 2019-05-31 21:36:50 UTC
Created attachment 144402 [details]
drm_debug_HDR_disabled.log
Comment 15 shashank.sharma@intel.com 2019-06-05 14:29:05 UTC
from the logs, I can see:
extended colorimetry: xvYCC 601 

Can you please set the following property and try again:
- output colorspace: BT2020_RGB

- Shashank
Comment 16 sergey79 2019-07-06 23:10:22 UTC
Any news on this (or patches I can try)? I'm having exactly the same issue with my Asrock J4105 Gemini Lake ITX board and Samsung UE40NU7100 TV.
Comment 17 Lakshmi 2019-07-15 06:13:44 UTC
Piotr, Have you tried Shashank's proposal?
Comment 18 sergey79 2019-07-16 03:28:34 UTC
I tried to switch the colorspace to BT2020_RGB using "proptest -M i915 -D /dev/dri/card0 127 connector 131 9". This did not make any difference, still no signal.
Comment 19 sergey79 2019-07-16 16:01:36 UTC
The other thing I noticed is that when Samsung's "HDMI UHD Color" is enabled - I get "no signal" before the OS is booted, e.g. I cannot see the UEFI setup interface.
However, within the OS I get a signal with any video mode except 4K modes (even 3820x2160 @24Hz does not work).
Comment 20 sergey79 2019-08-04 04:28:50 UTC
I did more testing and this seem to be an issue with 12 BPC mode @4k resolutions. If I set the "max bpc" with proptest to 8-bit - I get a signal. No signal with any 12-bit 4k modes (including 24hz).

I want to test with 10-bit instead of 12 but I have no idea how enable the 10 bpc mode. If I limit max bpc with proptest to 10-bit - I get max 8-bit.
Comment 21 shashank.sharma@intel.com 2019-08-05 03:49:01 UTC
I can see in intel_hdmi_deep_color_possible() that we are allowing 10bpc only for GEN11(ICL) onwards.

if (bpc == 10 && INTEL_GEN(dev_priv) < 11)
                return false;
This means we can't (legally) check 10bpc on GLK.

I am suspecting that this Samsung monitor is expecting something different in it's UHD deep color mode, coz I am not able to reproduce this issue with any of the UHD/HDR monitors available with me (LG, Philips). Unfortunately, this issue can't be worked upon without this particular monitor.

- Shashank
Comment 22 sergey79 2019-08-05 15:52:37 UTC
I removed the GEN11 restriction for 10-bit and I can confirm that it doesn't work - no signal with anything above 1080p/24.
Comment 23 shashank.sharma@intel.com 2019-08-05 15:54:54 UTC
Hey,
Actually the check is there because the HW can't support this before ICL, so it is expected.

- Shashank
Comment 24 sergey79 2019-08-25 02:34:41 UTC
I did some more testing and I was wrong about 12-bit color. The issue is not limited to 12-bit modes. RGB 8-bit 4k @60Hz does not work either.

Looks like the issue has something to do with the HDMI link speed. All modes that require the link speed of > 9.0Gbps don't work.

Is it possible to force the driver to use YCbCr 422 12-bit instead of RGB 8-bit for 24-30Hz 4K modes? This should give a better quality/less color banding when watching videos encoded in 10-bit.
Comment 25 teeedubb 2019-11-04 22:02:31 UTC
Hi,

Did you guys ever get to the bottom of this?
I am having the same issue with a Hard Kernel H2, which is j4105 based CPU and a Samsung MU7000.
If I enable UHD mode on the Samsung TV I am not able to use resolutions above 1080p. Without it enabled I am limited to 4k30. I have tried on a range of distros, libreelec (4.19 kernel), Ubuntu 18.04 and Xubuntu 19.10 (5.3 kernel with oibaf ppa).
Comment 26 sergey79 2019-11-04 23:54:05 UTC
(In reply to teeedubb from comment #25)

I think there is something wrong with the way the HDMI modes that use 594 Mhz pixel clock are implemented on Gemini Lake.

You can still get a 4K 50/60Hz 4:2:0 output as it doesn't require 594 Mhz pixel clock (e.g. 4K 4:2:0 50/60Hz work when using a GBM/DRMPRIME version of LibreELEC, not the "normal" X11 version).
Comment 27 shashank.sharma@intel.com 2019-11-05 03:18:28 UTC
As I had mentioned previously, I dont have access to this monitor, but based on the observations shared by everyone, this is what I think is happening: 

- HDMI 2.0 spec can support a max clock of 600Mhz. 
- Samsung TVs with UHD mode of display expect > 8BPC from the source in this mode of operations. This means you have to at-least drive 10 BPC output from SOC display. 
- 4K@60 modes (RGB/YCBCR444) need 597Mhz clock in 8 BPC mode of operation and will need > 597 Mhz clock to drive 4k@60 10/12/16 BPC.
- 4K@30 modes (RGB/YCBCR444) need 297Mhz clock for 8 BPC mode of operation, so it can even go up-to 16 BPC, which will still be with-in the 600Mhz range.
- YCBCR 4:2:0 needs half the clock, than RGB/YCBCR444 mode of operation. This means 4K@60 YCBCR420 output will need a clock of 597 Mhz and which further means we can drive 4k@60 10/12/16 BPC with YCBCR420 output, with-in the 600 Mhz clock range. 

That's why we can see 4k@30 deep color, 4k@60 YCBCR 420 deep color outputs working on this TV, but as soon as we switch to RGB 4k@60, the driver restricts the HDMI output to 4k@60 8BPC, which is being rejected by the TV, in the UHD mode of operation.

- Shashank
Comment 28 shashank.sharma@intel.com 2019-11-05 03:22:02 UTC
Slight modification in last comment, please read:

- YCBCR 4:2:0 needs half the clock, than RGB/YCBCR444 mode of operation. This means 4K@60 YCBCR420 output will need a clock of "297 Mhz" and which further means we can drive 4k@60 10/12/16 BPC with YCBCR420 output, with-in the 600 Mhz clock range.
Comment 29 sergey79 2019-11-05 05:23:27 UTC
(In reply to shashank.sharma@intel.com from comment #27)

> That's why we can see 4k@30 deep color, 4k@60 YCBCR 420 deep color outputs
> working on this TV, but as soon as we switch to RGB 4k@60, the driver
> restricts the HDMI output to 4k@60 8BPC, which is being rejected by the TV,
> in the UHD mode of operation.

420 works only @50/60Hz, only @ 8-bit. 420 @ deep color and other refresh rates (24/25/30) is not supported by the TV at all (with UHD Color on or off).

The only difference between "HDMI UHD Color" on and off is that TV sends different EDID data. I analyzed both EDIDs - basically the only important difference is the presence of HDMI-Forum VSDB block which enable Deep Color in 4k modes. 

4k modes that work (UHD Color off):
RGB 24/25/30Hz 8-bit
420 50/60Hz 8-bit

4k modes that don't work (UHD Color on):
RGB 24/25/30Hz 12-bit
RGB 50/60Hz 8-bit

As you can see, any mode that require 594 Mhz pixel clock - does not work. And any mode that require only 297 Mhz - works just fine.
Comment 30 shashank.sharma@intel.com 2019-11-05 05:33:41 UTC
(In reply to sergey79 from comment #29)
> (In reply to shashank.sharma@intel.com from comment #27)
> 
> > That's why we can see 4k@30 deep color, 4k@60 YCBCR 420 deep color outputs
> > working on this TV, but as soon as we switch to RGB 4k@60, the driver
> > restricts the HDMI output to 4k@60 8BPC, which is being rejected by the TV,
> > in the UHD mode of operation.
> 
> 420 works only @50/60Hz, only @ 8-bit. 420 @ deep color and other refresh
> rates (24/25/30) is not supported by the TV at all (with UHD Color on or
> off).
4K 420 is targeted for 50/60Hz only.
> 
> The only difference between "HDMI UHD Color" on and off is that TV sends
> different EDID data. I analyzed both EDIDs - basically the only important
> difference is the presence of HDMI-Forum VSDB block which enable Deep Color
> in 4k modes. 
> 
The presence of HF_VSDB indicates HDMI 2.0 EDID, not deep color. Deep color can be supported in HDMI 1.4b EDIDs too if the clock supports. 
 
> 4k modes that work (UHD Color off):
> RGB 24/25/30Hz 8-bit
> 420 50/60Hz 8-bit
> 
> 4k modes that don't work (UHD Color on):
> RGB 24/25/30Hz 12-bit
> RGB 50/60Hz 8-bit

Can you also dump 420VDB and 420CMDB from the CEA-extension blocks?  


> 
> As you can see, any mode that require 594 Mhz pixel clock - does not work.
> And any mode that require only 297 Mhz - works just fine.

GLK supports 4k@60 RGB@597Mhz well, as we have tested it with several other TVs and monitors. We are seeing this behavior on this TV only, and that's why I suspected if it's expecting something different. The UHD/Deep color mode is of operation is not clear to me yet.   

- Shashank
Comment 31 sergey79 2019-11-05 05:59:40 UTC
Created attachment 145883 [details]
EDID - UHD Color on

(In reply to shashank.sharma@intel.com from comment #30)

I have a theory that maybe the TV expects 422 rather than RGB for 4K with deep color. But I have no idea how to force the ycb422 output on Gemini Lake.
Comment 32 sergey79 2019-11-05 06:00:24 UTC
Created attachment 145884 [details]
EDID - UHD Color off
Comment 33 shashank.sharma@intel.com 2019-11-05 07:34:54 UTC
> I have a theory that maybe the TV expects 422 rather than RGB for 4K with deep > color. But I have no idea how to force the ycb422 output on Gemini Lake. 

This could be the case, and we don't support YCBCR422 yet. Its Either RGB888 or YCBCR420 if that's from 420VDB.

- Shashank
Comment 34 teeedubb 2019-11-06 10:32:07 UTC
I have been playing around with custom modelines and with HDMI UHD color off I am able to force 4k60/50 by using the modeline from 4k60/50 with HDMI UHD color on. As far as I can see the 4k60 mode uses a 594mhz clock rate (its in the modeline). I am not sure which chroma subsampling is being used because I'm not sure how to find out.
Comment 35 teeedubb 2019-11-07 08:09:30 UTC
Created attachment 145907 [details]
Chroma subsampling test in 4k60 non UHD Color mode

I haven't been able to find a method in software to check what level of chroma subsampling is being used with the 4k60 modeline in non UHD color mode, but I found a visual test that indicated that 4:4:4 is being used - I could read all the lines clearly from about6m away on a 65' TV. Closeup photo attached of the bottom two lines.

So it seems that the GLK GPU doesnt agree with the UHD color mode EDID, but the modes that are exclusive to it can be forced via a custom modeline when not in UHD color mode.

https://www.geeks3d.com/20141203/how-to-quickly-check-the-chroma-subsampling-used-with-your-4k-uhd-tv/

I didn't have any luck using modelines I found for a similar issue on askubuntu, so these may not work for other TVs, but here the three additional ones that are present in UHD color mode.

xrandr --newmode "3840x2160_60.00" 594.000 3840 4016 4104 4400 2160 2168 2178 2250 +hsync +vsync
xrandr --newmode "3840x2160_59.94" 593.407 3840 4016 4104 4400 2160 2168 2178 2250 +hsync +vsync
xrandr --newmode "3840x2160_50.00" 594.000 3840 4896 4984 5280 2160 2168 2178 2250 +hsync +vsync
Comment 36 sergey79 2019-11-07 13:46:00 UTC
I tested this Samsung TV with an AMD Athlon 200GE (Raven Ridge) system and there were no issues in UHD Color mode. Note that AMD driver default to YCbCr 422/444 in all 4K modes. 

Now I'm 90% sure that in "high speed" 594 Mhz HDMI modes those Samsung TVs expect YCbCr rather than RGB. We need an option to to make the color space switchable and not limited to RGB. RGB is obviously not the best option for some displays.
Comment 37 teeedubb 2019-11-10 02:51:19 UTC
(In reply to sergey79 from comment #36)
> I tested this Samsung TV with an AMD Athlon 200GE (Raven Ridge) system and
> there were no issues in UHD Color mode. Note that AMD driver default to
> YCbCr 422/444 in all 4K modes. 
> 
> Now I'm 90% sure that in "high speed" 594 Mhz HDMI modes those Samsung TVs
> expect YCbCr rather than RGB. We need an option to to make the color space
> switchable and not limited to RGB. RGB is obviously not the best option for
> some displays.

Sergey, you are correct. I have revisited this while trying to get HDR output working on my TV with GLK hardware. I have attached a screenshot of the relevant page.
Comment 38 teeedubb 2019-11-10 02:52:15 UTC
Created attachment 145930 [details]
MU7000 manual - UHD colour modes
Comment 39 teeedubb 2019-11-10 03:03:08 UTC
(In reply to shashank.sharma@intel.com from comment #33)
> > I have a theory that maybe the TV expects 422 rather than RGB for 4K with deep > color. But I have no idea how to force the ycb422 output on Gemini Lake. 
> 
> This could be the case, and we don't support YCBCR422 yet. Its Either RGB888
> or YCBCR420 if that's from 420VDB.
> 
> - Shashank

How can YCBCR420 be enabled? I can not see anything even resembling that mode in xrandr's verbose output.

All I see is
"Colorspace: BT2020_CYCC
supported: Default, SMPTE_170M_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, DCI-P3_RGB_Theater"
Comment 40 Martin Peres 2019-11-29 19:04:37 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/271.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.