Skip to content

Adding Content protection support in drm-backend

Ankit Nautiyal requested to merge aknautiyal/weston:content_protection into master

This RFC patch-series is an attempt to define and implement a content-protection protocol in weston to provide content-protection(HDCP1.4, HDCP2.2) to a weston client. This is inline with the earlier IRC discussions and mail chains: https://lists.freedesktop.org/archives/wayland-devel/2018-June/038446.html https://lists.freedesktop.org/archives/wayland-devel/2018-June/038511.html

The following is patch-series from Ramalingam C, for enabling HDCP2.2 in DRM layer, which is under review: https://patchwork.freedesktop.org/series/39596/

I understand, this protocol should be a part of wayland-protocols, as being suggested by the wayland community members, and I would be sending it as a part of wayland-protocols, in subsequent patch sets. I humbly request for comments on this patch series, to initiate the review of the protocol, the server, and the application at a single place.

This patch series includes:

-a protocol that defines communication between a client requesting content-protection depending on the type of content.

-modification in the drm-backend to get and set the content-protection that is exposed as a connector property from the drm layer.

-a content-protection server that can take request from a client and set the desired content-protection through drm-backend.

-a client application that opens a window and provides buttons to request for content-protection for Type-0 and Type-1 content.

Type-0 and Type-1, and unprotected contents are just made using cairo, with different color and text to distinguish from each other. The idea is to show that an application can switch from unprotected-content (perhaps low-quality video, or else an error screen) to the desired content (high definition video), if the content-protection for that type is successfully provided by the server.

V2 As suggested by Emre Ucan, moved the get and set content_protection functions in weston-drm-output-api.

V3: Used Scott Anderson's secure-output protocol modified and implemented in weston and changes as suggested by Pekka

V4: Added Meson build definitions. Fixed issues and did corrections as suggested by Scott Anderson.

V5: Addressed the various review comments regarding change in the design from Pekka and Ramalingam:

  • weston_surface has desired_protection : set by writing into surface->pending's desired_protection, in surface commit path.
  • weston_output has desired_protection : surface sets protection for all outputs on which it is shown.
  • weston_head has desired_protection : output sets protection for all heads in its list.
  • The highest protection is tried, irrespective of what the requested protection was. If in due time, there is no change in head's protection (no event received in due time from kernel), a lesser protection is tried for all such heads.
  • weston_output has current_protection, which is minimum of the protection of all hdcp_applicable heads.
  • Instread of Polling, the UEvent for a connector property is now used, if property is content-protection, the current_protection for the output which has that head is recomputed.
  • weston_surface has current_protection -> set by an idle tasks, that notifies each surface, in case of change in any of its output's current_protection.
  • In case the surface's current_protection is changed, the client with that surface is notified with an appropriate event sent to the client.
  • The code is now part of libweston, gets activated by "enable_hdcp=true" in weston.ini's core section.
  • The protocol implementation is in a separate file, in libweston. It deals with listening to client requests, and sending events to the clients.

V6: Addresses various review comments from

Pekka:

  • defining key terms in the protocol xml.
  • reorganization and restructuring the code.
  • follow repaint-cycle and avoid synchronous call.
  • movement of few functions from from compositor to drm-backend.
  • renaming few functions and documentation.

Daniel Stone:

  • removed unnecessary logs, and used asserts.

Modified the protocol xml as suggested by Scott Anderson

Rebased over TOT.

V7: Modified the handling of disable case, and updating the current protection status for weston_head.

As per the latest HDCP2.2 kernel patches, the uevent is sent only for changes in content-protection property done by the, kernel. So userspace gets the uevent after successful authentication and change in the property from the kernel side from "DESIRED" to "ENABLED", and also for any change in protection from "ENABLE" to "DESIRED" in case of abrupt failures. Userspace will not receive any uevent in case of disabling the protection.

**Tested on : **

Tested HDCP2.2 test:
*** Test '1A-02 Regular Procedure - With newly connected Receiver (Without stored km)' started ***
0000.000.001: Start test "1A-02 Regular Procedure - With newly connected Receiver (Without stored km)"
0000.000.280: [TE-Snk] [Before Starting Authentication]
0000.000.401: [TE-Snk] STEP 1A-01-1
0001.001.346: [TE-Snk]    TE transmits Receiver Connected Indication(Hot plug, CONNECTION_STATUS_NOTIFY and IRQ_HPD)
0001.001.670: [TE-Snk] [Authentication and Key Exchange]
0001.001.797: [TE-Snk] STEP 1A-01-2
0001.305.346: [TE-Snk]    WARNING. DUT sends unencrypted video
0001.305.478: [TE-Snk]    DUT initiates authentication by transmitting AKE_Init
0001.305.793: [TE-Snk] STEP 1A-02-1
0001.422.315: [TE-Snk]    TE sends AKE_Send_Cert message
0001.438.123: [TE-Snk]    DUT sends AKE_No_Stored_km message
0003.140.382: [TE-Snk]    Note. TE does not complete pairing.
0003.140.738: Test PASSED: "1A-02 Regular Procedure - With newly connected Receiver (Without stored km)"

*** Test complete -- PASSED ***

HDCP2.2_Analyser_Status_After_Enabling

UCD_Test_log.txt

weston.log

drm_log.txt

Weston_HDCP_TYPE_0

Weston_HDCP_UNPROTECTED

Edited by Ankit Nautiyal

Merge request reports