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