Wayland content-protection extension

[Ramalingam C]

On Monday 02 July 2018 07:30 PM, Pekka Paalanen wrote:
> On Mon, 2 Jul 2018 16:25:28 +0300
> Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
>> On Fri, 29 Jun 2018 21:41:33 +0530
>> Ramalingam C <ramalingam.c at intel.com> wrote:
>>
>> The idea here was that set_srm_table() is a simple API we can easily
>> maintain upstream. The external plugin would check the SRM table dates
>> and signatures and if they pass, call set_srm_table(). The external
>> plugin would also offer the client interface, whether it is Wayland,
>> DBus, or something else, to the video players. I believe this is a
>> design we could the very least agree to in upstream Weston, provided
>> there is a way to test set_srm_table() by feeding a sample SRM table
>> e.g. through a small test plugin in upstream.
>>
>> Oh, and if saving the latest SRM table to persistent memory is needed,
>> the external plugin could do that as well.
> I forgot to note, the Wayland protocol implementation would be in
> Weston upstream. There should be no reason to push that out to an
> external plugin. So Weston upstream would not only offer
> set_srm_table() but also take care of tracking the protection status,
> enabling HDCP on Wayland client request and reporting the status to the
> client.
That sounds good!
>
> It is only the SRM table management that I am concerned about. And the
> topology thing, but I know nothing about that yet.
At least for SRM handling we have some clarity now.

Topology info will be a structure as a blob from kernel. Compositor is
expected to pass that to client.

We need an API lets say get_hdcp_topology() similar to set_srm_table for
passing the downstream topology. Plugin will read it and pass it to clients
for their consumption.

Thanks,
Ram.
>
>
> Thanks,
> pq