Wayland content-protection extension

[Ramalingam C]

Hi Pekka,

Thanks a lot for making time for reviewing this proposal.

On Friday 29 June 2018 06:08 PM, Pekka Paalanen wrote:
> 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?
Yes.
>
> If so, we need to make sure the Weston implementation is not only a toy
> example.
Absolutely no. We have few designs in infotainment domain using the weston
compositor where we need HDCP support.
>
>> 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?
First property in the below list is already landed into upstream kernel 
as part of HDCP1.4.
All other interfaces needed for HDCP2.2. which is getting enabled in 
kernel in phases.
>
>> 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?
Second property is not proven yet. First one is used by chrome systems.
>
> 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.
Its this way:
   - UNDESIRED will force HDCP off
   - DESIRED will start the authentication. If DESIRED is not transitioned
         into ENABLED after the Timeout say 6Sec, Authentication is failed.
   - ENABLED indicates the success of authentication. On runtime failure,
         ENABLED will be transitioned into DESIRED.
>
>
>> 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?
If we prefer the events for Weston, we could propose the same
as part of HDCP2.2.

I believe that shouldn't break the existing chrome
user space stack as that is looking for timeout and property state only.
>
> What if the HDCP negotiation takes longer than that? Is there a maximum
> time defined?
In the HDCP spec max time allowed is defined for each spec. Ex 6Sec for 
HDCP2.2.
>
> 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?
nope. HDCP authentication doesn't stop the rendering. Unprotected 
content(Low value)
like a frame mentioning that HDCP negotiation is in progress or similar 
stuff
should be rendered by Application until it's HDCP requirements are met.

In fact that will provide the reason for delay(time required for 
negotiation) in playing the
protected content.
>
>> 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?
That time existing HDCP consumer(chrome) was happy without the events.
Now since we feel the need of it as a new consumer we could propose once 
again.
>
>> 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
This is completely agreeable.
>
> - unconditionally at compositor start-up and hotplug so that there is
>    no app start-up delay for HDCP negotiation
No. I disagree here. As HDCP should be on demand due to its extra
operations at kernel for maintaining the HDCP link.

All the HDCP consumer APPs expected to
know that HDCP spec takes required time for negotiation.
So they should inform and entertain the viewers with some Frame.
>
>> 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.
I believe, as a design we should work towards immediate information
of the HDCP state change to app.

Let the app to take the call whether to downgrade the content quality
or not to play. Compositor will be keep rendering until surface is provided.
Hope that sounds good.
>
> 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?
As you proposed above, for protected surafce, if we negotiate the
HDCP on all the connectors, moving the surface across connectors
are handled already with no flicker.

for hotplug-in, as soon as new unprotected connector detected,
just inform the app that HDCP protection state is not as per the request.

Let the app to react.
Compositor can keep proceeding with its policy. No change required.
>
>> 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.
Thank you!

Ram
>
>
> Thanks,
> pq