<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote: </div> <blockquote type="cite" cite="mid:CAKMK7uHX1ddhyOMzx6eWtZut7m3Fthm_ZKqbRxHzpeimw9QHzA@mail.gmail.com"> <pre wrap="">On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C <a class="moz-txt-link-rfc2396E" href="mailto:ramalingam.c@intel.com"><ramalingam.c@intel.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote: On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <a class="moz-txt-link-rfc2396E" href="mailto:seanpaul@chromium.org"><seanpaul@chromium.org></a> wrote: Why all these intermediate steps and different failure modes? Either hdcp works, or it doesnt (and we can split up with the type 0 or type 1 if needed), but I don't know what userspace would do with all the other stuff? enum values HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with kobj-uevent for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2 configuration. And without Type info it is not possible for HDCP2.2. I've had requests from chrome team to expose HDCP version, so I don't think this is too contentious. I think it'd still be easier if we start out with the current content protection props that CrOS is using, and then figure out how to layer the exact version/standard on top? One thing at a time and all that. -Daniel I understand the approach. But Only problem is current upstreaming effort is for HDCP2.2 support at DRM with a design which can easily accommodate other versions too. So we need to stretch current CrOS property a bit with ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all. </pre> </blockquote> <pre wrap=""> Yeah, but if we just go with enable (without specifying the type) we could still enable the highest hdcp level (so 2.2 for our case). At least I don't see a reason why we need to already have the enable_type1 thing. Can you pls explain why you think this is necessary? There seems to be a need to force type1, but I think it's easier to do that as an extension. Of course we need to keep it in mind meanwhile.</pre> </blockquote> Background for this need of Type info in HDCP2.2 implementation is as follows: HDCP2.2 Spec classify the protected content as Type 0 and Type 1. For Example lets say - A HDCP2.2 Src is connected to HDCP repeater - that repeater is connected to a HDCP2.2 panel - that same repeater is also connected to a HDCP1.4 panel. In this topology, as part of Repeater authentication: - HDCP2.2 Source will mention the Content Type to HDCP2.2 Repeater - Repeater can transmit this Type 1 content to HDCP2.2 compliant sink only (which is HDCP 2.2 panel here). - Repeater can transmit any type0 content to any other devices (like HDCP1.4 panel here). - Device with no HDCP support will get Neither of Type 0 or Type 1. So if we implement HDCP2.2 with HDCP_ENABLE state alone there is no way for Userspace to request for HDCP2.2 protection only. In this case we wont know the content type classification. Even if we force Content type to Type1, in above topology Type 0 content that could be rendered to HDCP1.4 compliant panel wont be rendered as that has been forcibly classified as Type 1 by KMD. Forcing type 1 content to Type 0 will break the association of type1 content to HDCP2.2 devices only. More than that Devices with our indented DRM HDCP2.2 support wont pass the HDCP2.2 compliance. Considering we could extend the CrOS Userspace for HDCP2.2, I would prefer to go ahead with HDCP_ENABLE_TYPE1 along with HDCP_ENABLE. --Ram <blockquote type="cite" cite="mid:CAKMK7uHX1ddhyOMzx6eWtZut7m3Fthm_ZKqbRxHzpeimw9QHzA@mail.gmail.com"> <pre wrap=""> -Daniel </pre> </blockquote> </body> </html>