Wayland content-protection extension

[Ramalingam C]

On Monday 02 July 2018 07:26 PM, Pekka Paalanen wrote:
> On Fri, 29 Jun 2018 22:49:56 +0530
> Ramalingam C <ramalingam.c at intel.com> wrote:
>
>> 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.
> Excellent, that is very useful to know.
>
>
>>> 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.
> Oh, that's nice. I thought it was something like link training, which I
> presume would not allow a video signal to be transmitted until it is
> finished.
>
>> 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.
> Ok, that would be very nice. It should also reduce the latency to
> respond to losing protection as that would otherwise depend on the
> polling rate.
>
>>>   
>>>> 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.
> Ok, good, especially since a HDCP negotiation does not disrupt the
> existing video signal.
>
>
>>> 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.
> Yes.
>
>
>> 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.
> Ok, so it is acceptable to transmit protected content to a potentially
> unprotected display until the app reacts to the event. That makes
> things very simple.

Yes.

Even HDCP spec provides the tolerance of at least 1Sec for link integrity check.
As a design we should inform the link status change to the content provider as
soon as possible.

Thats all required.

Thanks,
Ram.

>
> Thanks,
> pq