[Bug 99869] 12bpc deep color not supported by repeater

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Feb 20 17:28:47 UTC 2017


https://bugs.freedesktop.org/show_bug.cgi?id=99869

--- Comment #7 from Ville Syrjala <ville.syrjala at linux.intel.com> ---
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  |. at ...@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 at ..!......|
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170220/c68df432/attachment-0001.html>


More information about the intel-gfx-bugs mailing list