Bug 99869

Summary: 12bpc deep color not supported by repeater
Product: DRI Reporter: Tomeu Vizoso <tomeu>
Component: DRM/IntelAssignee: Tomeu Vizoso <tomeu>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: critical    
Priority: high CC: intel-gfx-bugs, matt, tomeu
Version: DRI gitKeywords: bisected, regression
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features: display/HDMI
Attachments:
Description Flags
EDID as presented directly by the TV
none
EDID as presented by the Rotel receiver none

Description Tomeu Vizoso 2017-02-20 14:13:02 UTC
The rsx-1058 supports only HDMI 1.1, but when forwarding the EDID of the connected sink it will let DC_36bit through.

http://rotel.com/product/rsx-1058

The kernel believes that 12bpc is possible and of course things break.

Bug 93361 contains the original report.
Comment 1 Tomeu Vizoso 2017-02-20 14:15:15 UTC
The offending commit is 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"").

Before that commit, sinks in this situation worked correctly (at 8bpc).
Comment 2 Tomeu Vizoso 2017-02-20 15:28:03 UTC
Have added a quirk for this specific receiver: https://patchwork.freedesktop.org/patch/139980/

Would be great if you could test it.
Comment 3 Ville Syrjala 2017-02-20 15:40:51 UTC
Can someone attach the EDID read both via the receiver and directly from the sink. Would be nice to see how bad of a mess the receiver makes.
Comment 4 Matt Horan 2017-02-20 15:52:23 UTC
Created attachment 129757 [details]
EDID as presented directly by the TV
Comment 5 Matt Horan 2017-02-20 15:52:41 UTC
Created attachment 129758 [details]
EDID as presented by the Rotel receiver
Comment 6 Matt Horan 2017-02-20 16:18:58 UTC
The quirk patch does the trick! Thanks.
Comment 7 Ville Syrjala 2017-02-20 17:28:47 UTC
Let's try to decode the CEA ext blocks a bit:
* = byte offset

original CEA ext block:

80: 02 03 33 f0 
84: 4c 10 05 04  20 22 3c 3e 03 07 02 06 01 (Video)
91: 26 09 07 07 15 07 50 (Audio)
98: 83 01 00 00 (Speaker allocation)
9c: 73 03 0c 00 10 00 b8 2d 2f d0 09 01 40 00 0f 10 40 50 60 46 (Vendor specific / HDMI)
b0: e2 00 fb * (Extended / Video capability)
                   
                   8c 0a d0 8a 20  e0 2d 10 10 3e 96 00 c2  |....... .-..>...|
000000c0  ad 42 00 00 18 01 1d 80  18 71 1c 16 20 58 2c 25  |.B.......q.. X,%|
000000d0  00 c2 ad 42 00 00 9e 00  00 00 00 00 00 00 00 00  |...B............|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 3a  |...............:|

receiver mangled:

80: 02 03 39 72
84: 4c 10 05 04 20 22 3c 3e 03 07 02 06 01 (Video)
91: 2f 09 07 01 0f 7f 07 09 7f 07 15 07 38 3d 07 c0 (Audio)
a1: 83 5f 00 00 (Speaker allocation)
a5: 66 03 0c 00 10 00 b8 (Vendor specific / HDMI)
ac: 2d 2f d0 09 01 40 00 0f 10 40 52 00 46 * 01 (Audio, extends past byte offset -> BAD)

                                         1d 00 72 51 d0 1e  |.@...@R.F...rQ..|
000000c0  20 6e 28 55 00 c4 8e 21  00 00 1e 01 1d 00 bc 52  | n(U...!.......R|
000000d0  d0 1e 20 b8 28 55 40 c4  8e 21 00 00 1e 00 00 00  |.. .(U@..!......|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 29  |...............)|

So looks like it has shortened the HDMI VSDB (starting at 0x73 originally, 0xa5 after mangling) by simply reducing the length of the block, but it has left all the data for the full length block in there. That means we'll interpret the remainder of the data as another data block, an audio data block in this case, but as it extends one byte past the "byte offset" we'll ignore it. Not sure if the receiver has done this on purpose of by accident. Either way it looks horrible, and it's perhaps only by luck that we aren't going to interpret the bogus data from the leftovers of the original HDMI VSDB as a valid data block of some sort.

The receiver also hasn't reduced the size if the HDMI VSDB quite enough to get rid of the deep color support stuff. So this could be an off by one error, or simply an error in clearing all the bits that were reserved prior to HDMI 1.3. I don't have a HDMI 1.1 spec on me, but at least 1.2 already defined that specific byte of the VSDB but all deep color bits were still reserved.

Well, either way the receiver does change the identification information in the EDID, so looks like the quirk should do the right thing no matter what sink is hooked up to it.
Comment 8 Jani Nikula 2017-02-20 19:13:10 UTC
FWIW my A/V receiver reports different EDIDs depending on the order the receiver and the TV are switched on. It's kind of a footnote here, but does the Rotel behave the same? Do both fail?
Comment 9 Tomeu Vizoso 2017-02-21 09:05:14 UTC
Reducing the priority to medium because there's a workaround that restores the previous behavior (replacing the edid with drm_kms_helper.edid_firmware), and my understanding is that the Highest priority is reserved for regressions that don't have a known workaround.
Comment 10 Matt Horan 2017-02-22 03:14:27 UTC
(In reply to Tomeu Vizoso from comment #9)
> Reducing the priority to medium because there's a workaround that restores
> the previous behavior (replacing the edid with
> drm_kms_helper.edid_firmware), and my understanding is that the Highest
> priority is reserved for regressions that don't have a known workaround.

Same behavior either way, and identical EDID.

I have seen similar behavior to what you're describing with audio, however. I sometimes have to power cycle the receiver, TV, or both, to get audio to play from the receiver. Also, when I shut off the TV just to listen to music from my PC, audio stops completely. Turning the TV back on, then off again resolves the issue.

This receiver has had many quirks since the beginning, and I'm amazed that any proprietary devices work with it at all. I appreciate your efforts in looking at this, though -- as I realize this is a pretty specific set of circumstances!
Comment 11 Ville Syrjala 2017-03-01 16:09:00 UTC
commit 3bc8b11dc78e95d0691effa95cf807e013e6449f
Author: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Date:   Mon Feb 20 16:25:45 2017 +0100

    drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058

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.