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.
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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
