On Fri, 29 Jun 2018 22:49:56 +0530 Ramalingam C <ramalinga...@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 <ramalinga...@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
pgpe72s4vAUtu.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
