Wayland content-protection extension

[Ramalingam C]

On Monday 18 June 2018 07:48 PM, Pekka Paalanen wrote:
> On Mon, 18 Jun 2018 08:58:28 -0500
> Matt Hoosier <matt.hoosier at gmail.com> wrote:
>
>> On Mon, Jun 18, 2018 at 8:54 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>>
>>> Hi Matt,
>>>
>>> did you intend to reply on list? Please CC if you did.
>>>
>>> On Mon, 18 Jun 2018 08:35:56 -0500
>>> Matt Hoosier <matt.hoosier at gmail.com> wrote:
>>>   
>>>> On Mon, Jun 18, 2018 at 3:59 AM Pekka Paalanen <ppaalanen at gmail.com>
>>> 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. :-(
>>>>>   
>>>> I get what you mean here, but maybe it's not actually that bad. The HDCP
>>>> runtime failure polling would really only be needed during times when at
>>>> least one video stream is actually using it, right? If that's true, then
>>>> the compositor is regularly waking up as the clients submit successive
>>>> buffers anyway. Can the HDCP connector status polling get folded into
>>> that
>>>> wakeup cycle?
>>> Sure, but you are assuming the protected content is video. I'm thinking
>>> of still images.
>>>   
>> Yeah, that's a fair point. Still probably covers the dominant use-case
>> though? Just curious, are you referring to the still images that result
>> from pausing a video stream, or first-class static images (maybe photos or
>> something) covered by content protection too?
> Anything that can actually sit still on the screen.
Though current HDCP usecase is for video playback, I would prefer the HDCP
design to consider any digital content(still fb or video protection) on 
wire.

Thanks
Ram
>
>
> Thanks,
> pq