On Monday 02 July 2018 07:26 PM, Pekka Paalanen wrote:
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.
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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
