Re: [PATCH v11 1/6] drm: Add Content protection type property
On 2019-08-01 at 13:05:02 +0300, Pekka Paalanen wrote:
> On Mon, 29 Jul 2019 15:03:16 +0530
> Ramalingam C wrote:
>
> > On 2019-07-29 at 17:20:40 +0300, Pekka Paalanen wrote:
> > > On Sun, 14 Jul 2019 16:30:08 +0530
> > > Ramalingam C wrote:
> > >
> > > > This patch adds a DRM ENUM property to the selected connectors.
> > > > This property is used for mentioning the protected content's type
> > > > from userspace to kernel HDCP authentication.
> > > >
> > > > Type of the stream is decided by the protected content providers.
> > > > Type 0 content can be rendered on any HDCP protected display wires.
> > > > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> > > >
> > > > So when a userspace sets this property to Type 1 and starts the HDCP
> > > > enable, kernel will honour it only if HDCP2.2 authentication is through
> > > > for type 1. Else HDCP enable will be failed.
> > > >
> > > > Need ACK for this new conenctor property from userspace consumer.
> > > >
> > > > v2:
> > > > cp_content_type is replaced with content_protection_type [daniel]
> > > > check at atomic_set_property is removed [Maarten]
> > > > v3:
> > > > %s/content_protection_type/hdcp_content_type [Pekka]
> > > > v4:
> > > > property is created for the first requested connector and then reused.
> > > > [Danvet]
> > > > v5:
> > > > kernel doc nits addressed [Daniel]
> > > > Rebased as part of patch reordering.
> > > > v6:
> > > > Kernel docs are modified [pekka]
> > > > v7:
> > > > More details in Kernel docs. [pekka]
> > > > v8:
> > > > Few more clarification into kernel doc of content type [pekka]
> > > > v9:
> > > > Small fixes in coding style.
> > > >
> > > > Signed-off-by: Ramalingam C
> > > > Reviewed-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> > > > drivers/gpu/drm/drm_connector.c | 51 +++
> > > > drivers/gpu/drm/drm_hdcp.c| 36 +++-
> > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 4 +-
> > > > include/drm/drm_connector.h | 7
> > > > include/drm/drm_hdcp.h| 2 +-
> > > > include/drm/drm_mode_config.h | 6 +++
> > > > include/uapi/drm/drm_mode.h | 4 ++
> > > > 8 files changed, 111 insertions(+), 3 deletions(-)
> > >
> > >
> > > Snip - sorry, gmail simply refuses to deliver my mail without trimming
> > > it hard.
> > >
> > > >
> > > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > > index 5ab331e5dc23..5c954394093f 100644
> > > > --- a/include/uapi/drm/drm_mode.h
> > > > +++ b/include/uapi/drm/drm_mode.h
> > > > @@ -218,6 +218,10 @@ extern "C" {
> > > > #define DRM_MODE_CONTENT_PROTECTION_DESIRED 1
> > > > #define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
> > > >
> > > > +/* Content Type classification for HDCP2.2 vs others */
> > > > +#define DRM_MODE_HDCP_CONTENT_TYPE00
> > > > +#define DRM_MODE_HDCP_CONTENT_TYPE11
> > >
> > > Hi,
> > >
> > > I still believe that these definitions do not belong in the uapi
> > > header. Userspace must use the string names instead.
> > >
> > > Otherwise the patch looks fine, though my Weston review is still
> > > on-going.
> >
> > I assume that still we need to wait for the weston review completion.
> >
> > Hence I request you to respond here once you are comfortable with this new
> > uAPI.
>
> Hi,
>
> yes.
>
> I have completed the Weston DRM-backend review in
> https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and
> the UAPI for HDCP 2.2 looks good. That Weston MR has some other
> not-UAPI-related bits I need to read through still, but they have
> no impact on the UAPI. The userspace is accepted in Weston.
>
> I am also happy with the documentation in these kernel patches.
>
> Therefore, with DRM_MODE_HDCP_CONTENT_TYPE0 and
> DRM_MODE_HDCP_CONTENT_TYPE1 removed from the kernel UAPI headers,
> for the kernel documentation and userspace consumer in Weston I
> give for these HDCP 2.2 Phase II kernel patches:
>
> Acked-by: Pekka Paalanen
Thank you pq.
I will remove those macros from uAPI header as weston dont need it.
And use your Acked-by for all the patches in the series.
BR,
-Ram
>
> Let me know, preferably as a comment in the Weston MR, when the
> kernel patches have landed in the appropriate git tree to unblock
> merging in Weston, please.
>
>
> Thanks,
> pq
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 1/6] drm: Add Content protection type property
On Mon, 29 Jul 2019 15:03:16 +0530
Ramalingam C wrote:
> On 2019-07-29 at 17:20:40 +0300, Pekka Paalanen wrote:
> > On Sun, 14 Jul 2019 16:30:08 +0530
> > Ramalingam C wrote:
> >
> > > This patch adds a DRM ENUM property to the selected connectors.
> > > This property is used for mentioning the protected content's type
> > > from userspace to kernel HDCP authentication.
> > >
> > > Type of the stream is decided by the protected content providers.
> > > Type 0 content can be rendered on any HDCP protected display wires.
> > > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> > >
> > > So when a userspace sets this property to Type 1 and starts the HDCP
> > > enable, kernel will honour it only if HDCP2.2 authentication is through
> > > for type 1. Else HDCP enable will be failed.
> > >
> > > Need ACK for this new conenctor property from userspace consumer.
> > >
> > > v2:
> > > cp_content_type is replaced with content_protection_type [daniel]
> > > check at atomic_set_property is removed [Maarten]
> > > v3:
> > > %s/content_protection_type/hdcp_content_type [Pekka]
> > > v4:
> > > property is created for the first requested connector and then reused.
> > > [Danvet]
> > > v5:
> > > kernel doc nits addressed [Daniel]
> > > Rebased as part of patch reordering.
> > > v6:
> > > Kernel docs are modified [pekka]
> > > v7:
> > > More details in Kernel docs. [pekka]
> > > v8:
> > > Few more clarification into kernel doc of content type [pekka]
> > > v9:
> > > Small fixes in coding style.
> > >
> > > Signed-off-by: Ramalingam C
> > > Reviewed-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> > > drivers/gpu/drm/drm_connector.c | 51 +++
> > > drivers/gpu/drm/drm_hdcp.c| 36 +++-
> > > drivers/gpu/drm/i915/display/intel_hdcp.c | 4 +-
> > > include/drm/drm_connector.h | 7
> > > include/drm/drm_hdcp.h| 2 +-
> > > include/drm/drm_mode_config.h | 6 +++
> > > include/uapi/drm/drm_mode.h | 4 ++
> > > 8 files changed, 111 insertions(+), 3 deletions(-)
> >
> >
> > Snip - sorry, gmail simply refuses to deliver my mail without trimming
> > it hard.
> >
> > >
> > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > index 5ab331e5dc23..5c954394093f 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -218,6 +218,10 @@ extern "C" {
> > > #define DRM_MODE_CONTENT_PROTECTION_DESIRED 1
> > > #define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
> > >
> > > +/* Content Type classification for HDCP2.2 vs others */
> > > +#define DRM_MODE_HDCP_CONTENT_TYPE0 0
> > > +#define DRM_MODE_HDCP_CONTENT_TYPE1 1
> >
> > Hi,
> >
> > I still believe that these definitions do not belong in the uapi
> > header. Userspace must use the string names instead.
> >
> > Otherwise the patch looks fine, though my Weston review is still
> > on-going.
>
> I assume that still we need to wait for the weston review completion.
>
> Hence I request you to respond here once you are comfortable with this new
> uAPI.
Hi,
yes.
I have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and
the UAPI for HDCP 2.2 looks good. That Weston MR has some other
not-UAPI-related bits I need to read through still, but they have
no impact on the UAPI. The userspace is accepted in Weston.
I am also happy with the documentation in these kernel patches.
Therefore, with DRM_MODE_HDCP_CONTENT_TYPE0 and
DRM_MODE_HDCP_CONTENT_TYPE1 removed from the kernel UAPI headers,
for the kernel documentation and userspace consumer in Weston I
give for these HDCP 2.2 Phase II kernel patches:
Acked-by: Pekka Paalanen
Let me know, preferably as a comment in the Weston MR, when the
kernel patches have landed in the appropriate git tree to unblock
merging in Weston, please.
Thanks,
pq
pgpDiJaw19XIU.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 1/6] drm: Add Content protection type property
On 2019-07-29 at 17:20:40 +0300, Pekka Paalanen wrote:
> On Sun, 14 Jul 2019 16:30:08 +0530
> Ramalingam C wrote:
>
> > This patch adds a DRM ENUM property to the selected connectors.
> > This property is used for mentioning the protected content's type
> > from userspace to kernel HDCP authentication.
> >
> > Type of the stream is decided by the protected content providers.
> > Type 0 content can be rendered on any HDCP protected display wires.
> > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> >
> > So when a userspace sets this property to Type 1 and starts the HDCP
> > enable, kernel will honour it only if HDCP2.2 authentication is through
> > for type 1. Else HDCP enable will be failed.
> >
> > Need ACK for this new conenctor property from userspace consumer.
> >
> > v2:
> > cp_content_type is replaced with content_protection_type [daniel]
> > check at atomic_set_property is removed [Maarten]
> > v3:
> > %s/content_protection_type/hdcp_content_type [Pekka]
> > v4:
> > property is created for the first requested connector and then reused.
> > [Danvet]
> > v5:
> > kernel doc nits addressed [Daniel]
> > Rebased as part of patch reordering.
> > v6:
> > Kernel docs are modified [pekka]
> > v7:
> > More details in Kernel docs. [pekka]
> > v8:
> > Few more clarification into kernel doc of content type [pekka]
> > v9:
> > Small fixes in coding style.
> >
> > Signed-off-by: Ramalingam C
> > Reviewed-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> > drivers/gpu/drm/drm_connector.c | 51 +++
> > drivers/gpu/drm/drm_hdcp.c| 36 +++-
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 4 +-
> > include/drm/drm_connector.h | 7
> > include/drm/drm_hdcp.h| 2 +-
> > include/drm/drm_mode_config.h | 6 +++
> > include/uapi/drm/drm_mode.h | 4 ++
> > 8 files changed, 111 insertions(+), 3 deletions(-)
>
>
> Snip - sorry, gmail simply refuses to deliver my mail without trimming
> it hard.
>
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 5ab331e5dc23..5c954394093f 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -218,6 +218,10 @@ extern "C" {
> > #define DRM_MODE_CONTENT_PROTECTION_DESIRED 1
> > #define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
> >
> > +/* Content Type classification for HDCP2.2 vs others */
> > +#define DRM_MODE_HDCP_CONTENT_TYPE00
> > +#define DRM_MODE_HDCP_CONTENT_TYPE11
>
> Hi,
>
> I still believe that these definitions do not belong in the uapi
> header. Userspace must use the string names instead.
>
> Otherwise the patch looks fine, though my Weston review is still
> on-going.
I assume that still we need to wait for the weston review completion.
Hence I request you to respond here once you are comfortable with this new uAPI.
Thanks,
- Ram
>
>
> Thanks,
> pq
>
> > +
> > struct drm_mode_modeinfo {
> > __u32 clock;
> > __u16 hdisplay;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 1/6] drm: Add Content protection type property
On Sun, 14 Jul 2019 16:30:08 +0530
Ramalingam C wrote:
> This patch adds a DRM ENUM property to the selected connectors.
> This property is used for mentioning the protected content's type
> from userspace to kernel HDCP authentication.
>
> Type of the stream is decided by the protected content providers.
> Type 0 content can be rendered on any HDCP protected display wires.
> But Type 1 content can be rendered only on HDCP2.2 protected paths.
>
> So when a userspace sets this property to Type 1 and starts the HDCP
> enable, kernel will honour it only if HDCP2.2 authentication is through
> for type 1. Else HDCP enable will be failed.
>
> Need ACK for this new conenctor property from userspace consumer.
>
> v2:
> cp_content_type is replaced with content_protection_type [daniel]
> check at atomic_set_property is removed [Maarten]
> v3:
> %s/content_protection_type/hdcp_content_type [Pekka]
> v4:
> property is created for the first requested connector and then reused.
> [Danvet]
> v5:
> kernel doc nits addressed [Daniel]
> Rebased as part of patch reordering.
> v6:
> Kernel docs are modified [pekka]
> v7:
> More details in Kernel docs. [pekka]
> v8:
> Few more clarification into kernel doc of content type [pekka]
> v9:
> Small fixes in coding style.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> drivers/gpu/drm/drm_connector.c | 51 +++
> drivers/gpu/drm/drm_hdcp.c| 36 +++-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 4 +-
> include/drm/drm_connector.h | 7
> include/drm/drm_hdcp.h| 2 +-
> include/drm/drm_mode_config.h | 6 +++
> include/uapi/drm/drm_mode.h | 4 ++
> 8 files changed, 111 insertions(+), 3 deletions(-)
Snip - sorry, gmail simply refuses to deliver my mail without trimming
it hard.
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 5ab331e5dc23..5c954394093f 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -218,6 +218,10 @@ extern "C" {
> #define DRM_MODE_CONTENT_PROTECTION_DESIRED 1
> #define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
>
> +/* Content Type classification for HDCP2.2 vs others */
> +#define DRM_MODE_HDCP_CONTENT_TYPE0 0
> +#define DRM_MODE_HDCP_CONTENT_TYPE1 1
Hi,
I still believe that these definitions do not belong in the uapi
header. Userspace must use the string names instead.
Otherwise the patch looks fine, though my Weston review is still
on-going.
Thanks,
pq
> +
> struct drm_mode_modeinfo {
> __u32 clock;
> __u16 hdisplay;
pgpspMXuSVXmG.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 1/6] drm: Add Content protection type property
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
Need ACK for this new conenctor property from userspace consumer.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
v5:
kernel doc nits addressed [Daniel]
Rebased as part of patch reordering.
v6:
Kernel docs are modified [pekka]
v7:
More details in Kernel docs. [pekka]
v8:
Few more clarification into kernel doc of content type [pekka]
v9:
Small fixes in coding style.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 51 +++
drivers/gpu/drm/drm_hdcp.c| 36 +++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 4 +-
include/drm/drm_connector.h | 7
include/drm/drm_hdcp.h| 2 +-
include/drm/drm_mode_config.h | 6 +++
include/uapi/drm/drm_mode.h | 4 ++
8 files changed, 111 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index abe38bdf85ae..19ae119f1a5d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -747,6 +747,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == config->hdcp_content_type_property) {
+ state->hdcp_content_type = val;
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
@@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
state->hdr_output_metadata->base.id : 0;
} else if (property == config->content_protection_property) {
*val = state->content_protection;
+ } else if (property == config->hdcp_content_type_property) {
+ *val = state->hdcp_content_type;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 068d4b05f1be..1dea923badd3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -952,6 +952,57 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
* is no longer protected and userspace should take appropriate action
* (whatever that might be).
*
+ * HDCP Content Type:
+ * This Enum property is used by the userspace to declare the content type
+ * of the display stream, to kernel. Here display stream stands for any
+ * display content that userspace intended to display through HDCP
+ * encryption.
+ *
+ * Content Type of a stream is decided by the owner of the stream, as
+ * "HDCP Type0" or "HDCP Type1".
+ *
+ * The value of the property can be one of the below:
+ * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
+ * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1
+ *
+ * When kernel starts the HDCP authentication (see "Content Protection"
+ * for details), it uses the content type in "HDCP Content Type"
+ * for performing the HDCP authentication with the display sink.
+ *
+ * Please note in HDCP spec versions, a link can be authenticated with
+ * HDCP 2.2 for Content Type 0/Content Type 1. Where as a link can be
+ * authenticated with HDCP1.4 only for Content Type 0(though it is implicit
+ * in nature. As there is no reference for Content Type in HDCP1.4).
+ *
+ * HDCP2.2 authentication protocol itself takes the "Content Type" as a
+ * parameter, which is a input for the DP HDCP2.2 encryption algo.
+ *
+ * In case of Type 0 content protection request, kernel driver can choose
+ * either of HDCP spec versions 1.4 and 2.2. When HDCP2.2 is used for
+ * "HDCP Type 0", a HDCP 2.2 capable repeater in the downstream can send
+ * that content to a HDCP 1.4 authenticated HDCP sink (Type0 link).
+ * But if the content is classified as
