Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

On Friday 14 July 2017 12:32 AM, Daniel Vetter wrote:

On Thu, Jul 13, 2017 at 06:29:33PM +0530, Ramalingam C wrote:


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

Yes, looks good now.


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 

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

On Thu, Jul 13, 2017 at 06:29:33PM +0530, Ramalingam C wrote:
> 
> 
> 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

Yes, looks good now.

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

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

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


___
dri-devel mailing 

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

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).

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

> 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).

> 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.
-Daniel
-- 
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

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

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:


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

-Daniel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

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.
-Daniel
-- 
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

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

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.

--Ram

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

On Thursday 13 July 2017 12:40 AM, Sean Paul wrote:

On Wed, Jul 12, 2017 at 08:26:02PM +0530, Ramalingam C wrote:

Daniel,

Thank you for reviewing the patch in short time. My views are below.


On Wednesday 12 July 2017 03:24 PM, Daniel Vetter wrote:

On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote:

DRM connector property is created as bitmask to receive
HDCP enable/disable request along with content type.

And also there are Read only status bits for
1. HDCP spec capability of the connector + panel
2. HDCP encryption status of the connector

Hi Ram,
Thank you for posting this set! I'll do some code review in a separate
pass.

Sean, Thank you for reviewing the code.




Signed-off-by: Ramalingam C 
---
   drivers/gpu/drm/drm_connector.c | 30 +
   include/drm/drm_hdcp.h  | 58 
+
   include/drm/drm_mode_config.h   |  5 
   3 files changed, 93 insertions(+)
   create mode 100644 include/drm/drm_hdcp.h

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8072e6e..04f8cf8 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -24,6 +24,7 @@
   #include 
   #include 
   #include 
+#include 
   #include "drm_crtc_internal.h"
   #include "drm_internal.h"
@@ -617,6 +618,28 @@ static const struct drm_prop_enum_list 
drm_link_status_enum_list[] = {
   };
   DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+static const struct drm_prop_enum_list drm_hdcp_enum_list[] = {
+   { __builtin_ffs(DRM_HDCP_ENABLE) - 1,
+   "Enable HDCP Encryption" },
+   { __builtin_ffs(DRM_HDCP_TYPE_BIT0) - 1,
+   "HDCP Content type bit0" },
+   { __builtin_ffs(DRM_HDCP_TYPE_BIT1) - 1,
+   "HDCP Content type bit1" },
+   { __builtin_ffs(DRM_HDCP1_SUPPORTED) - 1,
+   "HDCP1.x Supported" },
+   { __builtin_ffs(DRM_HDCP2_SUPPORTED) - 1,
+   "HDCP2.x Supported" },
+   { __builtin_ffs(DRM_HDCP_WIP) - 1,
+   "HDCP work in progress" },
+   { __builtin_ffs(DRM_HDCP_AUTH_FAILED) - 1,
+   "HDCP Authentication Failed" },
+   { __builtin_ffs(DRM_HDCP_LINK_INTEGRITY_FAILED) - 1,
+   "HDCP Link Integrity Failed" },
+   { __builtin_ffs(DRM_HDCP_REAUTH_REQUESTED) - 1,
+   "HDCP Reauthentication Requested" },

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.
Nice. So we could consider that we both need interface for HDCP1.4 and 
also HDCP2.2


Note that I've tried to use "content protection" instead of HDCP. My original
thinking was that since HDCP 1.x was broken, there was probably going to be
something else coming along. It's probably best to continue to keep the means of
protection vague, since you never know what will happen with HDCP 2.2 and what
will come after it.

Sure that will help in long run. Even I will name it as CP instead of HDCP




But to inform whether both HDCP source and Sink support HDCP1.4/2.2/None I
wanted to add
the capability bits. These capability flags could be avoided if the presence
of the drm_hdcp_property
on connector, assures the corresponding HDCP version support on both HDCP
src and sink.
But for that we need a way to detach/alter the DRM_property of connector
based on HDCP
sink's hdcp version capability. Need to explore on that direction if that is
allowed.

Meh, just change the content protection type to UNSUPPORTED or whatever.
Just thinking: In that case UNSUPPORTED will stand for not supporting 
any common HDCP ver

on the combination of HDCP src and sink?

In that case if HDCP src and sink combo doesn't support one of V1.4 and 
V2.2, then we wont

set the property state to UNSUPPORTED and
We will return error code -EINVAL for the request (atomic ioctl) of not 
supported version.

Does it sound good enough?



Once HDCP protection is enabled link protection might break for many reasons
including hot unplug. So Other Error
flags are just to give more information to UMD on that scenario. But we can
avoid them by setting the state
as HDCP_DISABLE and notifying the UMD through Kobj-uevent for HDCP state
change.

I can't think of a scenario where this info is worth 

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

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

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Sean Paul]

On Wed, Jul 12, 2017 at 08:26:02PM +0530, Ramalingam C wrote:
> Daniel,
> 
> Thank you for reviewing the patch in short time. My views are below.
> 
> 
> On Wednesday 12 July 2017 03:24 PM, Daniel Vetter wrote:
> > On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote:
> > > DRM connector property is created as bitmask to receive
> > > HDCP enable/disable request along with content type.
> > > 
> > > And also there are Read only status bits for
> > >   1. HDCP spec capability of the connector + panel
> > >   2. HDCP encryption status of the connector

Hi Ram,
Thank you for posting this set! I'll do some code review in a separate
pass.


> > > 
> > > Signed-off-by: Ramalingam C 
> > > ---
> > >   drivers/gpu/drm/drm_connector.c | 30 +
> > >   include/drm/drm_hdcp.h  | 58 
> > > +
> > >   include/drm/drm_mode_config.h   |  5 
> > >   3 files changed, 93 insertions(+)
> > >   create mode 100644 include/drm/drm_hdcp.h
> > > 
> > > diff --git a/drivers/gpu/drm/drm_connector.c 
> > > b/drivers/gpu/drm/drm_connector.c
> > > index 8072e6e..04f8cf8 100644
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -24,6 +24,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >   #include "drm_crtc_internal.h"
> > >   #include "drm_internal.h"
> > > @@ -617,6 +618,28 @@ static const struct drm_prop_enum_list 
> > > drm_link_status_enum_list[] = {
> > >   };
> > >   DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
> > > +static const struct drm_prop_enum_list drm_hdcp_enum_list[] = {
> > > + { __builtin_ffs(DRM_HDCP_ENABLE) - 1,
> > > + "Enable HDCP Encryption" },
> > > + { __builtin_ffs(DRM_HDCP_TYPE_BIT0) - 1,
> > > + "HDCP Content type bit0" },
> > > + { __builtin_ffs(DRM_HDCP_TYPE_BIT1) - 1,
> > > + "HDCP Content type bit1" },
> > > + { __builtin_ffs(DRM_HDCP1_SUPPORTED) - 1,
> > > + "HDCP1.x Supported" },
> > > + { __builtin_ffs(DRM_HDCP2_SUPPORTED) - 1,
> > > + "HDCP2.x Supported" },
> > > + { __builtin_ffs(DRM_HDCP_WIP) - 1,
> > > + "HDCP work in progress" },
> > > + { __builtin_ffs(DRM_HDCP_AUTH_FAILED) - 1,
> > > + "HDCP Authentication Failed" },
> > > + { __builtin_ffs(DRM_HDCP_LINK_INTEGRITY_FAILED) - 1,
> > > + "HDCP Link Integrity Failed" },
> > > + { __builtin_ffs(DRM_HDCP_REAUTH_REQUESTED) - 1,
> > > + "HDCP Reauthentication Requested" },
> > 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.

Note that I've tried to use "content protection" instead of HDCP. My original
thinking was that since HDCP 1.x was broken, there was probably going to be
something else coming along. It's probably best to continue to keep the means of
protection vague, since you never know what will happen with HDCP 2.2 and what
will come after it.


> 
> But to inform whether both HDCP source and Sink support HDCP1.4/2.2/None I
> wanted to add
> the capability bits. These capability flags could be avoided if the presence
> of the drm_hdcp_property
> on connector, assures the corresponding HDCP version support on both HDCP
> src and sink.
> But for that we need a way to detach/alter the DRM_property of connector
> based on HDCP
> sink's hdcp version capability. Need to explore on that direction if that is
> allowed.

Meh, just change the content protection type to UNSUPPORTED or whatever.

> 
> Once HDCP protection is enabled link protection might break for many reasons
> including hot unplug. So Other Error
> flags are just to give more information to UMD on that scenario. But we can
> avoid them by setting the state
> as HDCP_DISABLE and notifying the UMD through Kobj-uevent for HDCP state
> change.

I can't think of a scenario where this info is worth exposing to userspace. We
can just log failures for debugging purposes and we'll be fine.

> 
> But one concern remains un-addressed that is compliance requirement will
> force us to reauthenticate
> in case of failures in authentication or on HDCP enabled link. In that
> scenario UMD has to be in formed that
> reauth is in progress. If UMD wants the port to be reenabled it has to wait
> for the 

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

Daniel,

Thank you for reviewing the patch in short time. My views are below.


On Wednesday 12 July 2017 03:24 PM, Daniel Vetter wrote:

On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote:

DRM connector property is created as bitmask to receive
HDCP enable/disable request along with content type.

And also there are Read only status bits for
1. HDCP spec capability of the connector + panel
2. HDCP encryption status of the connector

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/drm_connector.c | 30 +
  include/drm/drm_hdcp.h  | 58 +
  include/drm/drm_mode_config.h   |  5 
  3 files changed, 93 insertions(+)
  create mode 100644 include/drm/drm_hdcp.h

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8072e6e..04f8cf8 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "drm_crtc_internal.h"

  #include "drm_internal.h"
@@ -617,6 +618,28 @@ static const struct drm_prop_enum_list 
drm_link_status_enum_list[] = {
  };
  DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
  
+static const struct drm_prop_enum_list drm_hdcp_enum_list[] = {

+   { __builtin_ffs(DRM_HDCP_ENABLE) - 1,
+   "Enable HDCP Encryption" },
+   { __builtin_ffs(DRM_HDCP_TYPE_BIT0) - 1,
+   "HDCP Content type bit0" },
+   { __builtin_ffs(DRM_HDCP_TYPE_BIT1) - 1,
+   "HDCP Content type bit1" },
+   { __builtin_ffs(DRM_HDCP1_SUPPORTED) - 1,
+   "HDCP1.x Supported" },
+   { __builtin_ffs(DRM_HDCP2_SUPPORTED) - 1,
+   "HDCP2.x Supported" },
+   { __builtin_ffs(DRM_HDCP_WIP) - 1,
+   "HDCP work in progress" },
+   { __builtin_ffs(DRM_HDCP_AUTH_FAILED) - 1,
+   "HDCP Authentication Failed" },
+   { __builtin_ffs(DRM_HDCP_LINK_INTEGRITY_FAILED) - 1,
+   "HDCP Link Integrity Failed" },
+   { __builtin_ffs(DRM_HDCP_REAUTH_REQUESTED) - 1,
+   "HDCP Reauthentication Requested" },

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.

But to inform whether both HDCP source and Sink support HDCP1.4/2.2/None 
I wanted to add
the capability bits. These capability flags could be avoided if the 
presence of the drm_hdcp_property
on connector, assures the corresponding HDCP version support on both 
HDCP src and sink.
But for that we need a way to detach/alter the DRM_property of connector 
based on HDCP
sink's hdcp version capability. Need to explore on that direction if 
that is allowed.


Once HDCP protection is enabled link protection might break for many 
reasons including hot unplug. So Other Error
flags are just to give more information to UMD on that scenario. But we 
can avoid them by setting the state
as HDCP_DISABLE and notifying the UMD through Kobj-uevent for HDCP state 
change.


But one concern remains un-addressed that is compliance requirement will 
force us to reauthenticate
in case of failures in authentication or on HDCP enabled link. In that 
scenario UMD has to be in formed that
reauth is in progress. If UMD wants the port to be reenabled it has to 
wait for the completion of reauth else
it has to place request for disabling the HDCP on port. We might want to 
add a enum value as HDCP_DISABLE_REAUTH.

What is your opinion on this?


This also doesn't seem to do the lockdown mode to force hdcp mode. And
afair it also doesn't match what CrOS currently uses, which means we don't
have userspace for this.
AFAIK, Either way we don't have userspace for HDCP2.2 at present, as 
CrOS interface is designed for
HDCP1.4(Need to cross check this with sean). But I will check with 
seanpaul if there is any plan for extending it for HDCP2.2 too.
If so we could enable CrOS as consumer for HDCP2.2 against planned open 
source consumer from my side.


As discussed in cover letter I am starting on a UMD library
which will be open sourced as a HDCP1.4 and 2.2 service provider for 
chromebox stack and Android.




I think the best approach would be if we simply try to upstream _exactly_
the property CrOS currently uses (not even bothering with type 0 vs type 1
if that's not required), since that is the currently only open source

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote:
> DRM connector property is created as bitmask to receive
> HDCP enable/disable request along with content type.
> 
> And also there are Read only status bits for
>   1. HDCP spec capability of the connector + panel
>   2. HDCP encryption status of the connector
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/drm_connector.c | 30 +
>  include/drm/drm_hdcp.h  | 58 
> +
>  include/drm/drm_mode_config.h   |  5 
>  3 files changed, 93 insertions(+)
>  create mode 100644 include/drm/drm_hdcp.h
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8072e6e..04f8cf8 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> @@ -617,6 +618,28 @@ static const struct drm_prop_enum_list 
> drm_link_status_enum_list[] = {
>  };
>  DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
>  
> +static const struct drm_prop_enum_list drm_hdcp_enum_list[] = {
> + { __builtin_ffs(DRM_HDCP_ENABLE) - 1,
> + "Enable HDCP Encryption" },
> + { __builtin_ffs(DRM_HDCP_TYPE_BIT0) - 1,
> + "HDCP Content type bit0" },
> + { __builtin_ffs(DRM_HDCP_TYPE_BIT1) - 1,
> + "HDCP Content type bit1" },
> + { __builtin_ffs(DRM_HDCP1_SUPPORTED) - 1,
> + "HDCP1.x Supported" },
> + { __builtin_ffs(DRM_HDCP2_SUPPORTED) - 1,
> + "HDCP2.x Supported" },
> + { __builtin_ffs(DRM_HDCP_WIP) - 1,
> + "HDCP work in progress" },
> + { __builtin_ffs(DRM_HDCP_AUTH_FAILED) - 1,
> + "HDCP Authentication Failed" },
> + { __builtin_ffs(DRM_HDCP_LINK_INTEGRITY_FAILED) - 1,
> + "HDCP Link Integrity Failed" },
> + { __builtin_ffs(DRM_HDCP_REAUTH_REQUESTED) - 1,
> + "HDCP Reauthentication Requested" },

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?

This also doesn't seem to do the lockdown mode to force hdcp mode. And
afair it also doesn't match what CrOS currently uses, which means we don't
have userspace for this.

I think the best approach would be if we simply try to upstream _exactly_
the property CrOS currently uses (not even bothering with type 0 vs type 1
if that's not required), since that is the currently only open source
userspace that asks for this. Going with a much more complicated or
different interface just because only risks a massive discussion and
subsequent long delays.
-Daniel

> +};
> +DRM_ENUM_NAME_FN(drm_get_hdcp_name, drm_hdcp_enum_list)
> +
>  /**
>   * drm_display_info_set_bus_formats - set the supported bus formats
>   * @info: display info to store bus formats in
> @@ -789,6 +812,13 @@ int drm_connector_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.link_status_property = prop;
>  
> + prop = drm_property_create_bitmask(dev, 0, "hdcp", drm_hdcp_enum_list,
> +ARRAY_SIZE(drm_hdcp_enum_list),
> +DRM_HDCP_PROP_SUPPORTED_BITS);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.hdcp_property = prop;
> +
>   return 0;
>  }
>  
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> new file mode 100644
> index 000..7cebf0f
> --- /dev/null
> +++ b/include/drm/drm_hdcp.h
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and 
> its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that 
> copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission.  The copyright holders make no representations
> + * about the suitability of this software for any purpose.  It is provided 
> "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS 
> SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR