Bug 101166 - option to disable deep color (or set HDMI bandwidth limit)
Summary: option to disable deep color (or set HDMI bandwidth limit)
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium enhancement
Assignee: Axel Kittenberger
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2017-05-24 13:09 UTC by Axel Kittenberger
Modified: 2017-09-01 11:27 UTC (History)
1 user (show)

See Also:
i915 platform: ALL
i915 features: display/color management


Description Axel Kittenberger 2017-05-24 13:09:45 UTC
Steps to reproduce the problem:

* have a kernel (~> 4.6 ) where drm is able to do deep color
* have an chip that uses i915 
* have a deep color able TV screen (1080p)
* connect them via a CAT5-bridge (as in our meeting rooms be done) that can handle 1060p only on 8bit.

Happens all the time.

This setup breaks with and only with Linux laptops with recent kernels, due to them turning on deep color which seemingly overloads the CAT5 bridge and thus the screen starts flickering (turning to black every 10-20 seconds for half a second).

Following "patch" solves the issue for me, since it forcefully disables all deep color ability for this notebook:

linux-4.11.2$ diff -u drivers/gpu/drm/drm_edid.c.org drivers/gpu/drm/drm_edid.c
--- drivers/gpu/drm/drm_edid.c.org    2017-05-24 14:08:19.162452768 +0200
+++ drivers/gpu/drm/drm_edid.c    2017-05-24 14:10:33.149417356 +0200
@@ -3803,6 +3803,7 @@
     if (cea_db_payload_len(hdmi) < 6)
+    return;
     if (hdmi[6] & DRM_EDID_HDMI_DC_30) {
         dc_bpc = 10;

I'd wish there was a module parameter to force this off, other than hacking the source. (Or I kept overlooking an existing one)

PS: As far I realize, unless this is a more sophisticated EDID bug, at fault here is that stupid CAT5-bridge that is supposed to modify the EDID to something it can handle, which it doesn't.
Comment 1 Jani Nikula 2017-05-31 09:16:09 UTC
Try to choose a different mode as a workaround?
Comment 2 Elizabeth 2017-08-24 20:54:03 UTC
Hello Axel, did changing modes make it as workaround?
(In reply to Jani Nikula from comment #1)
> Try to choose a different mode as a workaround?
Comment 3 Jani Nikula 2017-09-01 11:27:22 UTC
It's not really our bug that the cabling is inadequate. I think the workaround is to use a different mode.

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.