On 2019-09-12 10:49 a.m., Ramalingam C wrote:
> On 2019-09-12 at 14:23:05 +0000, Harry Wentland 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.
>>
>> 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"?
> "content type" is for defining the stream type. Adding an entry into it
> sounds like polluting it.
> 

For sure

> Separate uAPI for forcing a HDCP version might be need. Or wondering on
> using the sysfs of connector for this dirty job!?
> 

Did a bit more digging...

On other OS we got a monitor quirk for a few displays and also something
similar to a module parameter to force disable HDCP 2.x support.

It looks like there aren't too many quirky receivers so that might be an
acceptable solution. I'm still thinking a connector property might be
useful to force a certain HDCP version but maybe I'm overthinking it.

Harry

> -Ram
>>
>> 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

Reply via email to