<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <p>Hi Pekka,<o:p></o:p></p> <p>Thanks for the suggestions. Please find my responses inline:<o:p></o:p></p> <meta name="ProgId" content="Word.Document"> <meta name="Generator" content="Microsoft Word 15"> <meta name="Originator" content="Microsoft Word 15"> <link rel="File-List" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml">  <link rel="themeData" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"> <link rel="colorSchemeMapping" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">  <style>  </style> <div class="moz-cite-prefix">On 6/15/2018 1:16 PM, Pekka Paalanen wrote:<br> </div> <blockquote cite="mid:20180615104633.04a3cbb5@eldfell" 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"><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/">https://patchwork.freedesktop.org/series/39596/</a> As per the IRC discussion on #wayland about content protection extension for Wayland (yesterday, 12th June 2018) , please find below the agreed points: </pre> </blockquote> <pre wrap=""> Hi Ankit, very good to summarize the discussion. </pre> <blockquote type="cite"> <pre wrap=""> On exposing connector info to the clients: * The Client cannot request for content protection on a specific connector. * Wayland does not expose connector information to the clients. Client cannot put a window on a specific connector. * Compositor always decides where the surfaces are to be shown. There is no way for a client to audit that the compositor is doing the right thing, compositor is trusted to begin with and there's no reason to inspect it. </pre> </blockquote> <pre wrap=""> Yes. </pre> <blockquote type="cite"> <pre wrap="">On encryption of the content: * The client will provide unencrypted data to the compositor. The Kernel encrypts the content just before transmitting through the wire. * Once the Sink (the monitor), is authenticated to be HDCP compliant, the display engine will encrypt the data and send to the sink, where it will be decrypted. </pre> </blockquote> <pre wrap=""> Right. This was a fundamental point to know in designing the extension. This would be good to explain in the introduction of the actual protocol extension XML to set up expectations. Because the compositor will always receive unencrypted content, the compositor must always be a trusted component, including all the libraries it uses and the hardware drivers. </pre> <blockquote type="cite"> <pre wrap="">Level of protection required by a client, depends on the type of content sent by the client to the compositor: * The Content sent by a client app can be : Type 0 : Supported by HDCP1.4, and HDCP2.2 Type 1: Supported by only HDCP2.2 * Clients just request for content protection and provide the content type ie Type-0 or Type-1 to the compositor. * The compositor will check through all connectors of the intended surface receivers and make sure all connectors support the given content type. In case if some connector/s do not support a given content type, there are multiple strategy the compositor can follow: o do not show the protected content on any of the connector, return "content_protection failure" to the client. o show protected content on the supporting connectors, reduce image quality on unprotected connectors, and return "content_protection_success" to the client. </pre> </blockquote> <pre wrap=""> Rather than protection failed/success, I would word the events more like protection on/off, because I envision that a surface can change the status at runtime. It would be weird to first fail, then succeed, then fail again. The state would change according to where and how the surface is shown at times. The compositor will have a great freedom in deciding on the policy on how to handle protected content. If someone is developing a closed system, they can very well build in assumptions like "the state does not change after mapping" into their compositor and apps. But, I would prefer to leave such requirements out of the protocol specification. >From what I heard, the hardware will continuously or periodically confirm the protection status of the display data stream on the wire, and it is possible that the hardware status will change at runtime. The very least hotplug is a thing. </pre> </blockquote> <br> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <span style="font-size:12.0pt;font-family:"Times New Roman",serif; mso-fareast-font-family:"Times New Roman";color:black;mso-ansi-language:EN-US; mso-fareast-language:EN-US;mso-bidi-language:AR-SA">Yes agreed. The app will have a listener to content protection status.<br> It makes sense to have the even named as on/off. <br> </span> <meta name="ProgId" content="Word.Document"> <meta name="Generator" content="Microsoft Word 15"> <meta name="Originator" content="Microsoft Word 15"> <link rel="File-List" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml">  <link rel="themeData" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"> <link rel="colorSchemeMapping" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">  <style>  </style><br> <blockquote cite="mid:20180615104633.04a3cbb5@eldfell" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">* The display driver will take the call for providing best possible protection for a given content type. It will never provide information to the compositor, about which content protection protocol is used, i.e. compositor will only know if the connector supports a particular content-type, it would never know if HDCP1.4 or 2.2 is employed. </pre> </blockquote> <pre wrap=""> Right, this confused me at first, but this is your DRM UAPI design. </pre> <blockquote type="cite"> <pre wrap="">Scope of the protocol extension: * The protocol helps client to request for content protection. The client needs to provide the content type. * It provides the client with events for successful/unsuccessful content protection enablement. * Helps client to disable the content protection, and provide with success/ fail events. * The policy for showing the protected content with low quality, or stop showing the content on unprotected connectors is out of scope for the protocol. At best it can provide some guidelines/ specifications, but there's no way to ensure that. </pre> </blockquote> <pre wrap=""> Sounds good. I would formulate the protocol like this: - a global interface with a request to create a protection object; has arguments wl_surface and content type - the protection object interface has events for protection on/off, initially protection being off; it has a destructor, which will remove the requirement for protection </pre> </blockquote> <br> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <span style="font-size:12.0pt;font-family:"Times New Roman",serif; mso-fareast-font-family:"Times New Roman";color:black;mso-ansi-language:EN-US; mso-fareast-language:EN-US;mso-bidi-language:AR-SA">Really appreciate the given direction.<br> Will come up with first version of the protocol xml based on this.</span> <meta name="ProgId" content="Word.Document"> <meta name="Generator" content="Microsoft Word 15"> <meta name="Originator" content="Microsoft Word 15"> <link rel="File-List" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml">  <link rel="themeData" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"> <link rel="colorSchemeMapping" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">  <style>  </style><br> <blockquote cite="mid:20180615104633.04a3cbb5@eldfell" type="cite"> <pre wrap=""> </pre> <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? Is the use case something like a TV set-top-box with apps from different content providers and those each having different blacklists for example? After all, the whole design relies on the compositor being a trusted component. If the compositor is not trusted, it can simply ignore any blacklists. </pre> </blockquote> <br> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <p class="MsoNormal"><span style="mso-fareast-font-family:"Times New Roman"">The revocation list will be big can be maximum of 5K.<o:p></o:p></span></p> <p class="MsoNormal"><span style="mso-fareast-font-family:"Times New Roman"">As I understand the SRM messages will be delivered with content, to the kernel.<br> There is a separate Connector proprty of type blob for this.<br> 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.<o:p></o:p></span></p> <meta name="ProgId" content="Word.Document"> <meta name="Generator" content="Microsoft Word 15"> <meta name="Originator" content="Microsoft Word 15"> <link rel="File-List" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml">  <link rel="themeData" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"> <link rel="colorSchemeMapping" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">  <style>  </style><br> <blockquote cite="mid:20180615104633.04a3cbb5@eldfell" type="cite"> <pre wrap=""> </pre> <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> <br> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <pre><span style="font-size:12.0pt;font-family:"Times New Roman",serif; mso-fareast-font-family:"Times New Roman"">The topology information needs to be sent to client, in case of repeater. <o:p></o:p></span></pre> <pre><span style="font-size:12.0pt;font-family:"Times New Roman",serif;mso-fareast-font-family: "Times New Roman"">I thin Ram can shed more light on it.<o:p></o:p></span></pre> <meta name="ProgId" content="Word.Document"> <meta name="Generator" content="Microsoft Word 15"> <meta name="Originator" content="Microsoft Word 15"> <link rel="File-List" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml">  <link rel="themeData" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"> <link rel="colorSchemeMapping" href="file:///C:%5CUsers%5CAKNAUTIY%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">  <style>  </style><br> <blockquote cite="mid:20180615104633.04a3cbb5@eldfell" type="cite"> <pre wrap=""> Thanks, pq </pre> </blockquote> <br> </body> </html>