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/
As per the IRC discussion on #wayland about content protection extension for Wayland (yesterday, 12th June 2018) , please find below the agreed points: 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. 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. 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. * 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. 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. 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. * Downstream topology handling by the compositor, in case of, HDCP repeaters. Thanks & Regards, Ankit
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
