Re: HDCP Content Type Interface

From: Jani Nikula <jani.nikula@linux.intel.com>
To: Harry Wentland <hwentlan@amd.com>,
	Ramalingam C <ramalingam.c@intel.com>,
	"Lakha, Bhawanpreet" <Bhawanpreet.Lakha@amd.com>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: HDCP Content Type Interface
Date: Thu, 12 Sep 2019 17:57:37 +0300	[thread overview]
Message-ID: <87ftl1zhni.fsf@intel.com> (raw)
In-Reply-To: <57b94728-9dd5-a794-8a76-1a40dd857381@amd.com>

On Thu, 12 Sep 2019, Harry Wentland <hwentlan@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?

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?

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

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel