From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ramalingam C Subject: Re: [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors Date: Thu, 13 Jul 2017 18:29:33 +0530 Message-ID: References: <1499848144-8456-1-git-send-email-ramalingam.c@intel.com> <1499848144-8456-2-git-send-email-ramalingam.c@intel.com> <20170712095444.7x6msswrmrfvkas6@phenom.ffwll.local> <20170712191022.rgrpra5ni6n2vqx5@art_vandelay> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1807465404==" Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Daniel Vetter , intel-gfx , dri-devel List-Id: dri-devel@lists.freedesktop.org This is a multi-part message in MIME format. --===============1807465404== Content-Type: multipart/alternative; boundary="------------828C8FEE9DAE5D5C98C5D168" Content-Language: en-US This is a multi-part message in MIME format. --------------828C8FEE9DAE5D5C98C5D168 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On Thursday 13 July 2017 04:06 PM, Daniel Vetter wrote: > On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C wrote: >> >> On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote: >> >> On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C >> wrote: >> >> On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote: >> >> On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul 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. >> >> 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. >> >> Background for this need of Type info in HDCP2.2 implementation is as >> follows: > Aside: You're quoting is broken for inline quoting. Either fix the > quoting or top-quote (there's no difference between your text and > mine, mine should be indented with > or | or similar). Sorry for the inconvenience. Hope now it is fine. Just reset the settings on thunderbird > >> 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. > Yes, that is the case, but also the point of gradual enabling. Atm > (with the current CrOS usersapce) userspace can ask for "pls give me > content protection, I don't care what level/type". That itself is > already useful, and a good step forward. Allowing to ask for a > specific type is something on top. Ok. When i think over it, that sounds as a good idea to go gradually for enabling HDCP2.2. > >> 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. > Why? HDCP_ENABLE would just give you the "best" HDCP, so we'd fall > back to type 0 (if that's available). I think i misinterpreted. We could enable the HDCP2.2(if supported on panel) for the Type 0 content. No issue on that >> Forcing type 1 content to Type 0 will break the association of type1 content >> to HDCP2.2 devices only. > I didn't propose to force type1 everywhere. Why do you think this is needed. >> 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. > Yes, it's only hdcp1.4, and getting to full hdcp2.2 will take more > work. You can do all of that in one go, but my experience with > upstreaming new uabi is that usually that's not the most effective way > to go about things. But in the end, that's your choice. Agreed. We will go gradually about enabling HDCP2.2. 1. Enable HDCP2.2 for HDCP_ENABLE with Content type as 0. 2. Enable HDCP2.2 for Type 1 content with Enum value HDCP_ENABLE_TYPE1 3. Making HDCP2.2 support as HDCP2.2 spec compliant. But I think i will just add another enum value HDCP_UNSUPPORTED to mark the no HDCP supported on the setup. I hope that is fine. > -Daniel --------------828C8FEE9DAE5D5C98C5D168 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On Thursday 13 July 2017 04:06 PM, Daniel Vetter wrote:
On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C <ramalingam.c@intel.com> wrote:


On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote:

On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C <ramalingam.c@intel.com>
wrote:

On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:

On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <seanpaul@chromium.org> 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.

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.

Background for this need of Type info in HDCP2.2 implementation is as
follows:

Aside: You're quoting is broken for inline quoting. Either fix the
quoting or top-quote (there's no difference between your text and
mine, mine should be indented with > or | or similar).
Sorry for the inconvenience. Hope now it is fine. Just reset the settings on thunderbird


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.

Yes, that is the case, but also the point of gradual enabling. Atm
(with the current CrOS usersapce) userspace can ask for "pls give me
content protection, I don't care what level/type". That itself is
already useful, and a good step forward. Allowing to ask for a
specific type is something on top.
Ok. When i think over it, that sounds as a  good idea to go gradually for enabling HDCP2.2.


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.

Why? HDCP_ENABLE would just give you the "best" HDCP, so we'd fall
back to type 0 (if that's available).
I think i misinterpreted. We could enable the HDCP2.2(if supported on panel) for the Type 0 content. No issue on that  

      

        
Forcing type 1 content to Type 0 will break the association of type1 content
to HDCP2.2 devices only.


      

      
I didn't propose to force type1 everywhere. Why do you think this is needed. 


    

    

    

      

        
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.


      

      
Yes, it's only hdcp1.4, and getting to full hdcp2.2 will take more
work. You can do all of that in one go, but my experience with
upstreaming new uabi is that usually that's not the most effective way
to go about things. But in the end, that's your choice.

    

    Agreed. We will go gradually about enabling HDCP2.2.

          1. Enable HDCP2.2 for HDCP_ENABLE with Content type as 0.

          2. Enable HDCP2.2 for Type 1 content with Enum value
      HDCP_ENABLE_TYPE1

          3. Making HDCP2.2 support as HDCP2.2 spec compliant.

       

      But I think i will just add another enum value HDCP_UNSUPPORTED to
      mark the no HDCP supported on the setup.

      I hope that is fine.

    
    

      
-Daniel


    

    

  


--------------828C8FEE9DAE5D5C98C5D168--

--===============1807465404==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4
IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg==

--===============1807465404==--