Hi Scott,
I am working on enabling the HDCP1.4 and 2.2 in kernel and Weston from
Intel. Would like to share some points here.
On 11/21/2018 7:35 AM, Scott Anderson wrote:
Hi,
As far as I understand, the different types and versions of protection
a client would want is based on the resolution of the content, rather
than anything about what the content actually is. Is there any
particular reason a client would care if their content is being used
on a higher HDCP version than is necessary? e.g. would a client with
720p content care about using HDCP 2.2?
If that's the case, I think it would make sense for the compositor to
always try to negotitate the strongest level of protection that it can
(or a lower level if set by some policy), and report to the client the
largest resolution that it can support securely. With that, the client
can then make the decision about what content it can provide.
<interface name="...">
<event name="secure_resolution">
<arg name="width", type="int">
<arg name="height", type="int">
<arg name="refresh", type="int">
</event>
</interface>
This would remove a lot of the back-and-forth between the client and
the compositor, where the client says what content it has, and the
compositor saying if it can securely display it.
But the problem is HDCP2.2 spec leave the content type classification(type 0
and Type 1) to the content provider (in our case client).
As you mentioned these type classifications just mandates the minimum HDCP spec
that they need to be authenticated with.
Like Type 0 content can be transmitted to HDCP1.4 /2.2 authenticated digital
sink but where as Type 1
has to be transmitted the HDCP2.2 authenticated digital sink.
Considering this we can see that type of content should come from content
providers (clients). And as pekka mentioned in runtime
any surfaces can be dragged to any output, compositor/hdcp protocol server will
make sure all the required sinks are
authenticated with minimum required HDCP spec. And clients trust the
compositors on the status events generated.
These HDCP protection status prone to break incase of new hotplug. So
compositor needs to give the status as
whether content protection status has met the type requirement from client or
not.
In this way IMHO we need not tag the surface whether protected or not and
filter them on outputs based on their content protection status.
Based on the compositor events let the surface provider (client) decide whether
required HDCP status is met to render the protected surface or not.
This makes the design simple and to the requirement. Please point me out if
something is missed in this approach.
Thanks,
--Ram
This event could also be re-emitted when the protection status
changes. There could also be the special case of 0x0, where the
compositor failed to negotiate any secure connection, and no
resolution is secure.
A compositor may also choose to emit this signal based on what output
the client is set to display on, but that would probably be left up to
the compositor policy. It's possible that wl_output could be
integrated into this somehow, but I haven't thought too much about how
yet.
Scott
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
