Wayland content-protection extension

[Pekka Paalanen]

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.


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/20180702/98aaccd0/attachment-0001.sig>