Wayland content-protection extension

Fri Jun 29 12:38:37 UTC 2018

On Sat, 16 Jun 2018 16:03:20 +0530
Ramalingam C <ramalingam.c at intel.com> wrote:

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

Hi Ram,

thanks for writing this up.

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

By the way, will you be using a future Weston implementation as the
prooving vehicle for the kernel UABI?

If so, we need to make sure the Weston implementation is not only a toy
example.

> 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:

Oh, they have not landed yet in a non-rebasing kernel tree, have they?

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

Just curious, what userspace did you use to prove items 1 and 2?

I'm a little surprised you use the same property for input and
output, which means it's not possible to directly read back what was
written there. I assume that ENABLED implies DESIRED, and UNDESIRED
cannot result in ENABLED, but still.

> 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 +).

Ugh, timeouts. Was there really no other way?

What if the HDCP negotiation takes longer than that? Is there a maximum
time defined?

Also, I suppose the display is not showing content while the HDCP
negotiation is on-going, so how will a Wayland compositor now when the
picture becomes visible again? Will the KMS pageflip event be not
delivered until negotiation ends in success or failure?

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

Ugh, polling.

I'm really baffled why sending a kernel event for "content protection"
changes was denied. Was it the very idea, or just implementation
details? Lack of infrastructure for events other than pageflip and
hotplug?

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

Not only at this stage, but continuously on every frame the compositor
outputs.

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

Let's discuss the SRM separately, I wrote quite lengthily about in the
other email just before this one. I understand it needs to be set
before any protection is attempted, which makes it suitable to do
during app start as early as possible.

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

This could also be done:

- for all connectors, not just those where the window is showing
  initially, since it can migrate

- unconditionally at compositor start-up and hotplug so that there is
  no app start-up delay for HDCP negotiation

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

This is the thing that has to be done at runtime and continuously
(because the kernel requires polling). Otherwise it would be enough to
do it on hotplug events and when the weston_surface output mask changes.

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

If there is a 5 second timeout to realize the content won't be
protected as asked, that's going to take a lot of time.

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

Right.

Could the app start playing artifically blurred 4k stream even before
it knows if the protection succeeded? Since we build be protocol based
on the assumption that the protection status may change arbitarily at
runtime, it would make sense for the player to keep on playing but
adjust the quality on the fly. If there is a possibility that
protection could allow 4k, use the 4k stream but downgrade artificially
when not actually protected enough.

Or are protection status changes during playback thought to be
exceptional events which can warrant e.g. player pausing?
I.e. is seamless transition between protection levels a goal or a
non-goal?

I've been assuming that enabling seamless transitions if the player
wants to is a goal.

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

You imply that the compositor would wait for the app. This is generally
not acceptable. Also, if you demand it for hotplug, you demand it also
when the window is moved. If the compositor has to wait for an app
before it can draw anything, that results in a glitch we do not want
with Wayland.

I see two possibilities: either there is a race that an unprotected
output may show a few frames of content that requires protection, or
the compositor itself is required to censor the content until the app
responds (requires specific protocol added). How exactly to censor the
content could be a problem.

Hotplug-in is simpler to deal with, since there is no previous content
showing on it, and making the "compositor wait" is feasible - it's just
little more delay in activating the output. The harder case is window
moving onto an output where it wasn't already, since there the
compositor cannot stall on any output.

Can you see any acceptable solution here?

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

I re-wrapped it to make it a little more readable, but I'd appreciate
observing a reasonable maximum line length.

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180629/39a8189c/attachment.sig>