3 ms·
I imagine this is required for HDCP support, but why is it impossible to run without a blob and no HDCP support?
by formerly_proven 4y ago
I imagine this is required for HDCP support, but why is it impossible to run without a blob and no HDCP support?
- hlandau 4y agoAuthor here. Not all HDMI/HDCP implementations work like this. Basically, the designer of the SoC (NXP) will have licenced an HDMI/HDCP IP block from some company selling such IP. It looks like NXP licenced their HDMI/HDCP IP from Cadence in this case, a major provider of silicon IP. So this particular HDMI/HDCP implementation is designed to require this signed blob in order for it to function. Could Cadence have designed it so you can use it without HDCP without this blob, or use an unsigned blob and forego HDCP support, probably. But they didn't, so that's the situation.
- masklinn 4y agoI would assume it’s because the i.MX8 has no path to not support HDCP, so if you’re using it your choices are not “nothing, HDMI, or HDMI + HDCP” it’s “nothing, or HDMI + HDCP”. You can find old posts on the NXP forums talking about how disabling HDCP kills HDMI. If the chip can do TB / DisplayPort, you could add a separate DP -> HDMI converter, but obviously that increases your costs.
- nyanpasu64 4y agoSo it's impossible to get a HDMI signal out of the chip which can be read by a regular monitor or capture card without decryption keys, even for displaying non-movie images and GUIs? This is utterly disgusting. Or does HDCP turn off when talking to a non-HDCP (eg. DVI) display?