Wayland content-protection extension

[Ramalingam C]

On Monday 18 June 2018 02:23 PM, Pekka Paalanen wrote:
> On Mon, 18 Jun 2018 13:38:09 +0530
> Ramalingam C <ramalingam.c at intel.com> wrote:
>
>> On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote:
>>> On Sat, 16 Jun 2018 12:50:52 +0530
>>> Ramalingam C <ramalingam.c at intel.com> wrote:
>>>   
>>> How does the kernel signal to userspace that the HDCP status has
>>> changed? Do you piggyback on the hotplug event?
>>>
>>> Anything that would require userspace to repeatedly re-read properties
>>> without any events triggering it is bad design. If nothing is
>>> happening, the compositor needs to be able to stay asleep.
>> Pekka,
>>
>> We proposed a uevent from kernel for indicating the HDCP status change.
>> But that didn't fly. Right now the merged interface expects compositor
>> to poll
>> the property state for the runtime failures.
> Ugh. :-(
>
>>> The SRM table smells very much like compositor configuration,
>>> especially because a) it is global state: you cannot program two
>>> different tables to the same connector, and b) the compositor is
>>> required to save it and use it later for all clients(?). One can also
>>> envision a security issue, if a system allows third party apps: an app
>>> could install a fake SRM table with a fake date.
>> Compositor is expected to store the latest SRM in the non-volatile and
>> update with only newest versions.
>> And it will supply the latest version to kernel(irrespective of what
>> version is provided by app). This caching is not per connector.
>> SRM table itself provides the version of it. and The validity of an SRM
>> is established by verifying the integrity of its
>> signature with the Digital Content Protection LLC public key, which is
>> specified by the Digital
>> Content Protection LLC. So no fake SRM will be accepted.
> Right, so I would propose to make that completely separate.
Ok. So how that should be implemented? As another protocol extension?

Thanks,
Ram.
>
>
> Thanks,
> pq