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.
The offending commit is 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now""). Before that commit, sinks in this situation worked correctly (at 8bpc).
Have added a quirk for this specific receiver: https://patchwork.freedesktop.org/patch/139980/ Would be great if you could test it.
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.
Created attachment 129757 [details] EDID as presented directly by the TV
Created attachment 129758 [details] EDID as presented by the Rotel receiver
The quirk patch does the trick! Thanks.
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.
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?
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.
(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!
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.