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
