On Thu, Sep 12, 2019 at 9:21 PM Harry Wentland <hwent...@amd.com> wrote: > > > > 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.
Could we just mass-import that quirk list (since it seems it's not unreasonable big) and be done with this? -Daniel > 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 > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
