|
Hi all, 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: 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
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:
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@xxxxxxxxx> --- 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. |
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
