<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On Saturday 16 June 2018 01:06 PM, Ramalingam C wrote: </div> <blockquote type="cite" cite="mid:88224dbd-67c4-7ce9-d114-aa839ef7fe2a@intel.com"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <div class="moz-cite-prefix">On Friday 15 June 2018 05:10 PM, Pekka Paalanen wrote: </div> <blockquote type="cite" cite="mid:20180615144007.243198e1@eldfell"> <pre wrap="">On Fri, 15 Jun 2018 16:16:26 +0530 "Nautiyal, Ankit K" <a class="moz-txt-link-rfc2396E" href="mailto:ankit.k.nautiyal@intel.com" moz-do-not-send="true"><ankit.k.nautiyal@intel.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi Pekka, Thanks for the suggestions. Please find my responses inline: On 6/15/2018 1:16 PM, Pekka Paalanen wrote: </pre> <blockquote type="cite"> <pre wrap="">On Wed, 13 Jun 2018 10:34:45 +0000 "Nautiyal, Ankit K" <a class="moz-txt-link-rfc2396E" href="mailto:ankit.k.nautiyal@intel.com" moz-do-not-send="true"><ankit.k.nautiyal@intel.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">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 : <a class="moz-txt-link-freetext" href="https://patchwork.freedesktop.org/series/39596/" moz-do-not-send="true">https://patchwork.freedesktop.org/series/39596/</a> </pre> </blockquote> </blockquote> </blockquote> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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? </pre> </blockquote> </blockquote> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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?</pre> </blockquote> 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. <blockquote type="cite" cite="mid:20180615144007.243198e1@eldfell"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">* Downstream topology handling by the compositor, in case of, HDCP repeaters. </pre> </blockquote> <pre wrap="">Why would that be an issue affecting the protocol? </pre> </blockquote> <pre wrap="">The topology information needs to be sent to client, in case of repeater. </pre> </blockquote> <pre wrap="">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.</pre> </blockquote> 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. </blockquote> 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 <blockquote type="cite" cite="mid:88224dbd-67c4-7ce9-d114-aa839ef7fe2a@intel.com"> --Ram <blockquote type="cite" cite="mid:20180615144007.243198e1@eldfell"> <pre wrap=""> Thanks, pq </pre>  <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ wayland-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:wayland-devel@lists.freedesktop.org" moz-do-not-send="true">wayland-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </pre> </blockquote>  <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ wayland-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </pre> </blockquote> </body> </html>