On 2019-09-12 10:57 a.m., Jani Nikula wrote: > On Thu, 12 Sep 2019, Harry Wentland <hwent...@amd.com> wrote: >> On 2019-09-12 3:47 a.m., Ramalingam C wrote: >>> On 2019-09-09 at 15:54:50 +0000, Lakha, Bhawanpreet wrote: >>>> Hi all, >>>> >>>> This is regarding the recent hdcp content type patch that was merged into >>>> drm-misc. >>>> (https://patchwork.freedesktop.org/patch/320958/?series=57233&rev=11) >>>> >>>> There are displays on the market that advertise HDCP 2.2 support and will >>>> pass authentication and encryption but will then show a >>>> corrupted/blue/black screen (the driver cannot detect this). These >>>> displays work with HDCP 1.4 without any issues. Due to the large number of >>>> HDCP-supporting devices on the market we might not be able to catch them >>>> with a blacklist. >>>> >>>> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same >>>> thing. Meaning that this interface doesn't allow us to force the hdcp >>>> version. Due to the problems mentioned above we might want to expose the >>>> ability for a user to force an HDCP downgrade to a certain level (e.g. >>>> 1.4) in case they experience problems. >>>> >>>> What are your thoughts? and what would be a good way to deal with it? >>> Hi, >>> >>> As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel >>> supposed to exercise the highest version of HDCP supported on panel and >>> platform. >>> >>> As we implement the HDCP spec support, if a device is non-compliant with >>> HDCP spec after completing the HDCP authentication, I dont think we need >>> to worry about it. >>> >> >> Tell that to our (or your) customers. > > Agreed, let's rather not. > >> In this case an enduser might plug in a bad monitor or TV and be unable >> to play protected content. >> >> What if we add a new enum value to the content_type property that says >> "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? > > In general, I think if the fix is to teach the user to jump through > hoops in case the output is not working, it is really not a fix. > > Would, say, a set top box or a Blu-ray player have a setting to force > HDCP 1.4, and a troubleshooting item in the manual to select that if the > display does not work? Or would OS X have that? >
Not sure. AFAIU on other OS we're currently dealing with this through monitor quirks. We can probably pull the same quirks to DRM. > If broken HDCP 2.2 sink support is a widespread problem (is it?), what > do other HDCP sources do? If it's a Linux issue, what are we doing wrong > or different? Not a Linux issue and not overly widespread. Looks like a handful of receivers are problematic. Harry > > > BR, > Jani. > > > >> >> Harry >> >>> In case if you want to track and implement a quirk for it, like not to >>> project the HDCP2.2 capability, you can use the receiver id of that panel >>> to track it. >>> >>> Thanks, >>> -Ram >>>> >>>> >>>> Thanks, >>>> >>>> Bhawan >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
