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.
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.
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:
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.
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 +).
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.
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.
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.
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.
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.
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.
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.
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.
I hope I have captured required details in the sequence. Lets discuss further
based on the questions.
Sorry about the length and formatting.
Thanks and Regards,
Ram
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
