[RFC v4] drm/hdcp: drm enum property for CP State
Ramalingam C
ramalingam.c at intel.com
Sat Aug 5 15:51:34 UTC 2017
Hi all,
As we discussed in this review thread before, "UNSUPPORTED" state is
added to the HDCP property to indicate a situation when HDCP is not
possible, though hdcp property is attached to connector obj. In such
case I would prefer to detach the hdcp property from connector, which
would have been clear indication of no support. Since that is not
possible at present in our kernel, I have added this state in the property.
In v4 of the uAPI RFC, "UNSUPPORTED" state of Enum is assigned with
"-1", so that it doesn't alter the existing CrOS user space HDCP uAPI
states {UNDESIRED=0, DESIRED=1, ENABLED=2}. Current CrOS User space need
not change anything to use proposed uAPI. v4 of this uAPI RFC posted
should be compatible for downstream uAPI of CrOS. So in current state of
CrOS user space, as usual it can set the property for DESIRED for
enabling the HDCP. But it will be rejected as no HDCP is possible in the
platform. Please share if there is any concern. This can be removed as
it is not a compulsory state for functionality.
Multiple questions are asked in off line discussions, on why can't we
make uAPI as HDCP version agnostic. Sharing the reasoning with
community, so that we all can be on same page.
For first phase of HDCP2.2 development, uAPI proposed is version
agnostic. Thats the reason we are able to use the CrOS's HDCP1.4 support
as user space consumer for Phase 1. But in Phase 2 when we enable
complete HDCP2.2 spec in kernel along with required user space consumer,
uAPI will be extended to support required interface. Such uAPI extension
will expose the platforms HDCP v2.2 capability to the user, and in some
cases, allows the users to mandate the HDCP v2.2 encryption only for
their content. I am bringing this up as we need community agreement for
this second phase of uAPI also. Reasoning for such extension is as follow:
HDCPv2.2 Spec provides an option to the content provider, to tag a
stream, such that it will be given to HDCP2.2(or latest) compliant
devices only through out the distribution chain. This tagging is nothing
but calling the stream as Type 1. In Other words, Type 1 streams are
always encrypted with HDCPv2.2. This stream type info will be passed to
the All HDCP2.2 sinks as part of authentication. So that sinks such as
repeaters/converters wont be transmitting the received encrypted stream
to the HDCP device which is non-compliant with HDCP V2.2.
If a stream can be distributed to HDCP1.4 compliant devices also, that
is tagged as Type 0. Refer the below diagram for pictorial
representation for flow of encrypted stream tagged as Type 0 and 1.
+-----------+ HDCP v2.2 protected
| HDCP v2.2 | Type 0
Content Type 1 Content
|Transmitter| flow
path flow path
+-----+-----+
| | |
| v2.2 link | |
v v v
+----+----+ | |
|HDCP v2.2| | |
| Repeater| | |
+--+---+--+ | |
| | +-+-+ +-+
v2.2 link | | v1.4 link |
| |
+------+ +-------+ +------+ +-------+
+------+
| | | | |
v v v v v
+----+----+ +----+----+
|HDCP v2.2| |HDCP v1.4|
| Panel | | Panel |
+---------+ +---------+
Note: none of the protected content streams Type0/1 will be shared to
panels which are non HDCP compliant.
We need uAPI to pass the type of stream from user space to kernel because:
1. When Digital Right Management(DRM) wants HDCP2.2 encryption, it will
tag the stream as Type 0/1.
2. One of the parameter for encryption formula of HDCP v2.2 is this
Type info. So Type classification of stream defined by DRM should be
passed to kernel.
3. Many content providers(DRM) want their content to be encrypted only
in V2.2, as v1.4 is already compromised. To fulfill such
requirement, we need to expose the capability of HDCP v2.2 to user
space and also interface to set such requirement to kernel. Adding
option to set type info of stream clears both requirements.
Option 1: All of the above requirements can be fulfilled just by adding
a property state to a existing hdcp property to represent the type info
of the stream. such as {UNDESIRED, DESIRED, ENABLED, TYPE1_DESIRED,
TYPE1_ENABLED}.
Option 2: Assume still we prefer HDCP version agnostic uAPI, as Enum
property with {UNDESIRED, DESIRED, ENABLED}. For HDCP enable request,
latest HDCP version supported will be invoked for encryption. When the
latest version capable is v2.2, still we have to pass the type info
along with version agnostic enable request, through separate HDCP
ver2.2+ specific Enum property as {TYPE0, TYPE1}.
Bottom line is For HDCP v2.2 either way we need to pass the Type info
from user space to kernel.
If there is a concern or doubt about this interface requirement please
express it here.
Example of protected content provider, who mandates the HDCP v2.2
encryption only is Netflix. It imposes that 4k content can be played
only on HDCP2.2 HDMI monitors.
On Wednesday 02 August 2017 09:23 PM, Ramalingam C wrote:
> Default connector property called "Content Protection" is added to
> represent the content protection state of a connector and to
> configure the same.
>
> Userspace can request for enable or disable of content protection
> on a connector. Set "DESIRED" for Enable and "UNDESIRED" for disable.
>
> Content protection states defined:
> DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED - Unsupported
> DRM_MODE_CONTENT_PROTECTION_UNDESIRED - Undesired
> DRM_MODE_CONTENT_PROTECTION_DESIRED - Desired
> DRM_MODE_CONTENT_PROTECTION_ENABLED - Enabled
>
> v2: Redesigned the property to match with CP needs of CrOS [Sean].
> v3: Renamed the state names. Header is removed [Sean].
> v4: Aligned with existing userspace(CrOS's usage) [Sean].
>
> Signed-off-by: Ramalingam C <ramalingam.c at intel.com>
> ---
> drivers/gpu/drm/drm_connector.c | 24 ++++++++++++++++++++++++
> include/drm/drm_mode_config.h | 5 +++++
> include/uapi/drm/drm_mode.h | 7 +++++++
> 3 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8072e6e4c62c..f4ce0af63ad3 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -617,6 +617,14 @@ 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_cp_enum_list[] = {
> + { DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED, "Unsupported" },
> + { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
> + { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> + { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
> +
> /**
> * drm_display_info_set_bus_formats - set the supported bus formats
> * @info: display info to store bus formats in
> @@ -741,6 +749,15 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
> * value of link-status is "GOOD". If something fails during or after modeset,
> * the kernel driver may set this to "BAD" and issue a hotplug uevent. Drivers
> * should update this value using drm_mode_connector_set_link_status_property().
> + * Content Protection:
> + * Connector Content Protection property to indicate the content protection
> + * status of a connector. Default value is "UNDESIRED". Kernel will set
> + * to "UNSUPPORTED" if there is no common HDCP ver supported between Src
> + * and Sink. User space could set this to "DESIRED" to enabled the content
> + * protection on the connector. If content protection setup process is
> + * success, kernel will set this property to "ENABLED". To Disable the
> + * content protection on the connector userspace could set this property to
> + * "UNDESIRED".
> *
> * Connectors also have one standardized atomic property:
> *
> @@ -789,6 +806,13 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
> return -ENOMEM;
> dev->mode_config.link_status_property = prop;
>
> + prop = drm_property_create_enum(dev, 0, "Content Protection",
> + drm_cp_enum_list,
> + ARRAY_SIZE(drm_cp_enum_list));
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.cp_property = prop;
> +
> return 0;
> }
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 42981711189b..72e2b4e6d51d 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -538,6 +538,11 @@ struct drm_mode_config {
> */
> struct drm_property *link_status_property;
> /**
> + * @cp_property: Default connector property for content protection
> + * status of a connector
> + */
> + struct drm_property *cp_property;
> + /**
> * @plane_type_property: Default plane property to differentiate
> * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
> */
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 403339f98a92..61685a64cd6a 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -173,6 +173,13 @@ extern "C" {
> DRM_MODE_REFLECT_X | \
> DRM_MODE_REFLECT_Y)
>
> +/* Content Protection options */
> +enum cp_state {
> + DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED = -1,
> + DRM_MODE_CONTENT_PROTECTION_UNDESIRED,
> + DRM_MODE_CONTENT_PROTECTION_DESIRED,
> + DRM_MODE_CONTENT_PROTECTION_ENABLED,
> +};
>
> struct drm_mode_modeinfo {
> __u32 clock;
--
Regards,
--Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170805/e74a1456/attachment-0001.html>
More information about the dri-devel
mailing list