<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Exchange Server">  <style></style> </head> <body> <font face="Calibri" size="2"><span style="font-size:11pt;"> <div>Hi All, </div> <div style="padding-left:50.5pt;"> </div> <div>I am working on wayland content-protection protocol extension, to enable content-protection (HDCP1.4, HDCP2.2) in wayland.</div> <div>DRM layer already has support for HDCP1.4 and patches for HDCP2.2 are in review : <a href="https://patchwork.freedesktop.org/series/39596/"><font color="#0563C1"><u>https://patchwork.freedesktop.org/series/39596/</u></font></a> </div> <div> </div> <div>As per the IRC discussion on #wayland about content protection extension for Wayland (yesterday, 12<font size="1"><span style="font-size:7.3pt;"><sup>th</sup></span></font> June 2018) , please find below the agreed points:</div> <div> </div> <div><b>On exposing connector info to the clients:</b></div> <ul style="margin:0;padding-left:23.5pt;"> <li>The Client cannot request for content protection on a specific connector.</li><li>Wayland does not expose connector information to the clients. Client cannot put a window on a specific connector.</li><li>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.</li></ul> <div style="padding-left:50.5pt;"> </div> <div><b>On encryption of the content:</b></div> <ul style="margin:0;padding-left:23.5pt;"> <li>The client will provide unencrypted data to the compositor. The Kernel encrypts the content just before transmitting through the wire.</li><li>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.</li></ul> <div style="padding-left:50.5pt;"> </div> <div><b>Level of protection required by a client, depends on the type of content sent by the client to the compositor:</b></div> <ul style="margin:0;padding-left:23.5pt;"> <li>The Content sent by a client app can be :</li></ul> <div style="padding-left:23.5pt;">Type 0 : Supported by HDCP1.4, and HDCP2.2</div> <div style="padding-left:23.5pt;">Type 1: Supported by only HDCP2.2</div> <ul style="margin:0;padding-left:23.5pt;"> <li>Clients just request for content protection and provide the content type ie Type-0 or Type-1 to the compositor.</li><li>The compositor will check through all connectors of the intended surface receivers and make sure all connectors support the given content type.</li></ul> <div style="text-indent:5.5pt;">In case if some connector/s do not support a given content type, there are multiple strategy the compositor can follow:</div> <ul style="margin:0;padding-left:68.5pt;"> <li>do not show the protected content on any of the connector, return "content_protection failure" to the client.</li><li>show protected content on the supporting connectors, reduce image quality on unprotected connectors, and return "content_protection_success" to the client.</li></ul> <ul style="margin:0;padding-left:23.5pt;"> <li>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.</li></ul> <div style="padding-left:50.5pt;"> </div> <div><b>Scope of the protocol extension:</b></div> <ul style="margin:0;padding-left:23.5pt;"> <li>The protocol helps client to request for content protection. The client needs to provide the content type.</li><li>It provides the client with events for successful/unsuccessful content protection enablement.</li><li>Helps client to disable the content protection, and provide with success/ fail events.</li><li>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.</li></ul> <div style="text-indent:23.5pt;">At best it can provide some guidelines/ specifications, but there’s no way to ensure that.</div> <div style="padding-left:50.5pt;"> </div> <div style="padding-left:50.5pt;"> </div> <div><b>Note:</b> Some things that are still open, but will be discussed later: </div> <ul style="margin:0;padding-left:23.5pt;"> <li>SRM table (list of backlisted Monitors/Sinks) which need to be sent from the client side.</li><li>Downstream topology handling by the compositor, in case of, HDCP repeaters.</li></ul> <div> </div> <div> </div> <div>Thanks & Regards,</div> <div>Ankit</div> <div> </div> </span></font> </body> </html>