Wayland content-protection extension

[Pekka Paalanen]

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?

> >> *       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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180615/ab5768f1/attachment.sig>