Wayland content-protection extension

[Ramalingam C]

On Friday 15 June 2018 05:10 PM, Pekka Paalanen wrote:
> On Fri, 15 Jun 2018 16:16:26 +0530
> "Nautiyal, Ankit K" <ankit.k.nautiyal at intel.com> wrote:
>
>> Hi Pekka,
>>
>> Thanks for the suggestions. Please find my responses inline:
>>
>> On 6/15/2018 1:16 PM, Pekka Paalanen wrote:
>>> On Wed, 13 Jun 2018 10:34:45 +0000
>>> "Nautiyal, Ankit K" <ankit.k.nautiyal at intel.com> wrote:
>>>   
>>>> Hi All,
>>>>
>>>> I am working on wayland content-protection protocol extension, to
>>>> enable content-protection (HDCP1.4, HDCP2.2) in wayland. DRM layer
>>>> already has support for HDCP1.4 and patches for HDCP2.2 are in
>>>> review : https://patchwork.freedesktop.org/series/39596/
>>>> Note: Some things that are still open, but will be discussed later:
>>>> *       SRM table (list of backlisted Monitors/Sinks) which need to
>>>> be sent from the client side.
>>> That list could be big, right? I mean more than, say, 1 kB. If yes, you
>>> would want to use a shared memory buffer.
>>>
>>> Why does the client have to send it? Can it not be just compositor
>>> configuration?
>> The revocation list will be big can be maximum of 5K.
>>
>> As I understand the SRM messages will be delivered with content, to the
>> kernel.
>> There is a separate Connector proprty of type blob for this.
>> SRM can be transmitted with a cable TV signal. It might be keep on
>> getting updated as more devices, keep on adding to the table.
> Is that only because of the possibility of repeaters?
>
> I.e. you give a repeater the blacklist and then that will check if it
> forwards the content to its downstream devices or not?
>
> Not for a display to refuse itself if it finds itself on the list?
Repeaters and receivers provide the list of HDCP receiver IDs to the 
HDCP transmitter as part of authentication protocol.
Revocation(blacklist) is verified against the receiver ids by the HDCP 
transmitter.

>
>>>> *       Downstream topology handling by the compositor, in case of,
>>>> HDCP repeaters.
>>> Why would that be an issue affecting the protocol?
>> The topology information needs to be sent to client, in case of repeater.
> But why?
>
> What if the compositor uses non-HDCP ways that still comply with the
> content type requirements to show the content?
>
> How do you describe that the compositor is showing the content one
> protected output and another unprotected output but blurred?
>
> Suddenly this got much much more complicated, I doubt I'll have time
> for that.
 From our prior discussions, we are clear that compositor will apply the 
HDCP requirement to all the connectors that will render the protected 
content. And the AND of the HDCP status on those connectors will be 
communicated to content player(weston client here). Now it is content 
player's decision whether to render the protected content on such 
protection level achieved by kernel and reported and reported.

I am seeing that requirement could be met with our interface agreed till 
now just by adding another interface from where Client can read the 
lists of HDCP authenticated devices from each connectors. Kernel will 
provide a blob property for each connector for this purpose.

--Ram
>
>
> Thanks,
> pq
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180616/76be42f8/attachment.html>