Wayland content-protection extension

[Ramalingam C]

On Saturday 16 June 2018 01:06 PM, Ramalingam C wrote:
>
>
>
> 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.
But IMHO discussion on this interface could wait for completion of all 
other basic design to complete. As this is not a requirement to 
implement the HDCP transmitter using intended platform.

Thanks,
--Ram
>
> --Ram
>>
>> Thanks,
>> pq
>>
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
> _______________________________________________
> 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/b2699304/attachment.html>