Wayland content-protection extension

[Ramalingam C]

Hello all,

I am trying to call out the complete sequence that we are aiming to achieve. Please correct me if something is missed out.
I am hoping that with this sequence and interface we could get the functionalities of HDCP what Arnaud and pekka also wants.

As we discussed Each protected content providers have the same content in different quality.
And they want to play each quality in a particular environment only. I am just leaving all other
requirement except the HDCP protection for facilitating the discussion on HDCP support for weston.

Before going further I would like to clarify that any content those needs to be protected against the copy over wire,
can utilize the HDCP encryption. This could be a list of passwords as pekka mentioend or valuable high quality movie.
The owner of those content can classify the content Type as 0/1 based on the HDCP version they want to use.
As of now HDCP version 1.4 and 2.2 supports are getting added to Linux kernel.

And as per HDCP specification, Type 0 content can be rendered with HDCP1.4 or HDCP2.2. But Type 1 content can be rendered only with HDCP2.2 protection.
As a system(Player + compositor + Kernel) we need to mandate this requirement to comply with HDCP specification.

In kernel we are working on adding below connector properties:

1. Enum property "content protection" {UNDESIRED, DESIRED, ENABLED} - Merged
2. Enum property "content type" {TYPE_0, TYPE_1}            - Will be upstreamed after current ongoing HDCP2.2 effort. Can only be merged along with userspace changes.
3. Blob property "srm"                                      - Will be upstreamed after current ongoing HDCP2.2 effort. Can only be merged along with userspace changes.

Here,
	property "content protection" and property "srm" will be added to a connector only if the connector supports atleast one HDCP version.
	property "content type" will be added to a connector only if the connector supports Type 1 protection (HDCP2.2)
This is the means of identifying the HDCP capability of a connector from userspace.

When userspace wants to request for the HDCP protection, First it needs to pass the SRM table as a blob to kernel,
which is received from the content provider or from non-volatile storage.
Then userspace can set the "content type" to desired value "0/1", along with "content protection" to "DESIRED".
As soon as DESIRED is set, kernel will start the authentication for the content type mentioned.
On success, kernel will update the content_protection to "ENABLED". In case of failure Property wont have any change.
Userspace can identify the HDCP failure based on the timeout(5Sec +).

And the kernel will be keep checking the link protection status, incase of the runtime HDCP failure, "content protection" will be set to "DESIRED"
Hence after the success of HDCP authentication,  userspace has to continuously poll the "content protection" state in a required frequency for detecting the runtime failures.

Setting "content protection" to UNDESIRED will stop the HDCP protection on a connector.

Now we know, HDCP services from kernel. So lets discuss how content provider's hdcp protection requirement could be met in a system with weston compositor.

1. Lets assume APP is a protected movie player.
2. Lets APP has different level of content quality 4k, FullHD, HD. And APP is willing to render 4k content only on HDCP2.2 protected external displays,
	FullHD content only on HDCP(1.4/2.2) protected external displays and HD content on any display.
3. So APP will classify the content as below:
	4K 	- Type 1 protected content
	Full HD	- Type 0 protected content
	HD	- Unprotected content.
	Disclaimer: Content owner can classify any content as type 0/1 based on its sensitive nature.
4. When the APP starts it will render the preview of the movies or some other unprotected content to the compositor to display it on connectors
5. At this stage, based on the system mode (Extended/Mirror) connectors for that surface will be decided I guess.
6. Now when a user selects the Type 1 protected content for playing, APP1 will request the weston to create the protected
  	wl_surface with Type 1 requirement mentioned. And also provides the latest SRM to compositor.
7. Now compositor will check whether all intended HDMI and DP connectors for protected surface, have the capability of HDCP with Type1.
8. If Type 1 HDCP is capable on all connectors,  HDCP with Type 1 is requested on all the external connectors with SRM by compositor and wait
	for the ENABLED state on "content protection" with required timeout to decide the status of the HDCP authentication.
9. Logical AND of all the results of  HDCP type1 requests from the connectors are communicated to the APP.
	This will indicate to the APP that whether all the connectors are HDCP Type 1 protected or not.
10. If APP got the required HDCP Type 1 protection it will render the  4K content, else will will downgrade content quality
	and try for the required level of HDCP protection in the above steps.
11. Incase HDCP Type 1 is in place, 4k playing will start. Compositor will be keep monitoring all the connectors for the runtime link failures.
	If HDCP is down on any one connector, compositor will trigger the event immediately to intimate the same to the actively listening APP.
12. Incase if there is a hot plug-out compositor can ignore it. But if there is a new hot plug-in on a connector, which is a sink for
	protected surface, then before rendering the data compositor needs to intimate the APP that HDCP protection is down.
	So that APP can decide about rendering the protected surface further.
	But compositor will try to start the HDCP on the newly added connector, until the the protected surface is on.

I hope I have captured required details in the sequence. Lets discuss further based on the questions.
Sorry about the length and formatting.

Thanks and Regards,
Ram