From 06aeb0eae092c8637b3b7c76dc1d2232cb790af0 Mon Sep 17 00:00:00 2001 From: Scott Anderson Date: Mon, 4 Feb 2019 21:34:56 +1300 Subject: [PATCH] protocol: Add content-protection protocol This protocol allows a client to ask the compositor to only allow it to be displayed on a "secure" output. This initial version of the protocol supports HDCP. This is loosely based on the chromium secure-output protocol [1]. This protocol is mostly useful for closed system, where the client can trust the compositor, such as set-top boxes. This is not a way to implement any kind of Digital Rights Management on desktops. The compositor would be free to lie to the client, anyway. Signed-off-by: Scott Anderson Signed-off-by: Ankit Nautiyal [1] https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml --- protocol/meson.build | 1 + protocol/weston-content-protection.xml | 251 +++++++++++++++++++++++++ 2 files changed, 252 insertions(+) create mode 100644 protocol/weston-content-protection.xml diff --git a/protocol/meson.build b/protocol/meson.build index 34026ff9..f27413dc 100644 --- a/protocol/meson.build +++ b/protocol/meson.build @@ -32,6 +32,7 @@ generated_protocols = [ [ 'weston-debug', 'internal' ], [ 'weston-desktop-shell', 'internal' ], [ 'weston-screenshooter', 'internal' ], + [ 'weston-content-protection', 'internal' ], [ 'weston-test', 'internal' ], [ 'weston-touch-calibration', 'internal' ], [ 'xdg-output', 'v1' ], diff --git a/protocol/weston-content-protection.xml b/protocol/weston-content-protection.xml new file mode 100644 index 00000000..6fdbb95b --- /dev/null +++ b/protocol/weston-content-protection.xml @@ -0,0 +1,251 @@ + + + + + Copyright 2016 The Chromium Authors. + Copyright 2018-2019 Collabora, Ltd. + Copyright © 2018-2019 Intel Corporation. + + Permission is hereby granted, free of charge, to any person obtaining a + copy of this software and associated documentation files (the "Software"), + to deal in the Software without restriction, including without limitation + the rights to use, copy, modify, merge, publish, distribute, sublicense, + and/or sell copies of the Software, and to permit persons to whom the + Software is furnished to do so, subject to the following conditions: + + The above copyright notice and this permission notice (including the next + paragraph) shall be included in all copies or substantial portions of the + Software. + + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + DEALINGS IN THE SOFTWARE. + + + + This protocol specifies a set of interfaces used to provide + content-protection for e.g. HDCP, and protect surface contents on the + secured outputs and prevent from appearing in screenshots or from being + visible on non-secure outputs. + + A secure-output is defined as an output that is secured by some + content-protection mechanism e.g. HDCP, and meets at least the minimum + required content-protection level requested by a client. + + The term content-protection is defined in terms of HDCP type 0 and + HDCP type 1, but this may be extended in future. + + This protocol is not intended for implementing Digital Rights Management on + general (e.g. Desktop) systems, and would only be useful for closed systems. + As the server is the one responsible for implementing + the content-protection, the client can only trust the content-protection as + much they can trust the server. + + In order to protect the content and prevent surface contents from appearing + in screenshots or from being visible on non-secure outputs, a client must + first bind the global interface "weston_content_protection" which, if a + compositor supports secure output, is exposed by the registry. + Using the bound global object, the client uses the "get_protection" request + to instantiate an interface extension for a wl_surface object. + This extended interface will then allow surfaces to request for + content-protection, and also to censor the visibility of the surface on + non-secure outputs. Client applications should not wait for the protection + to change, as it might never change in case the content-protection cannot be + achieved. Alternatively, clients can use a timeout and start showing the + content in lower quality. + + Censored visibility is defined as the compositor censoring the protected + content on non-secure outputs. Censoring may include artificially reducing + image quality or replacing the protected content completely with + placeholder graphics. + + Censored visibility is controlled by protection mode, set by the client. + In "relax" mode, the compositor may show protected content on non-secure + outputs. It will be up to the client to adapt to secure and non-secure + presentation. In "enforce" mode, the compositor will censor the parts of + protected content that would otherwise show on non-secure outputs. + + + + + The global interface weston_content_protection is used for exposing the + content protection capabilities to a client. It provides a way for clients + to request their wl_surface contents to not be displayed on an output + below their required level of content-protection. + Using this interface clients can request for a weston_protected_surface + which is an extension to the wl_surface to provide content-protection, and + set the censored-visibility on the non-secured-outputs. + + + + + Informs the server that the client will not be using this + protocol object anymore. This does not affect any other objects, + protected_surface objects included. + + + + + + + + + + Instantiate an interface extension for the given wl_surface to + provide surface protection. If the given wl_surface already has + a weston_protected_surface associated, the surface_exists protocol + error is raised. + + + + + + + + + An additional interface to a wl_surface object, which allows a client to + request the minimum level of content-protection, request to change the + visibility of their contents, and receive notifications about changes in + content-protection. + + A protected surface has a 'status' associated with it, that indicates + what type of protection it is currently providing, specified by + content-type. Updates to this status are sent to the client + via the 'status' event. Before the first status event is sent, the client + should assume that the status is 'unprotected'. + + A client can request a content protection level to be the minimum for an + output to be considered secure, using the 'set_type' request. + It is responsibility of the client to monitor the actual + content-protection level achieved via the 'status' event, and make + decisions as to what content to show based on this. + + The server should make its best effort to achieve the desired + content-protection level on all of the outputs the client's contents are + being displayed on. Any changes to the content protection status should be + reported to the client, even if they are below the requested + content-protection level. If the client's contents are being displayed on + multiple outputs, the lowest content protection level achieved should be + reported. + + A client can also request that its content only be displayed on outputs + that are considered secure. The 'enforce/relax' requests can achieve this. + In enforce mode, the content is censored for non-secure outputs. + The implementation of censored-visibility is compositor-defined. + In relax mode there are no such limitation. On an attempt to show the + client on unsecured output, compositor would keep on showing the content + and send the 'status' event to the client. Client can take a call to + downgrade the content. + + If the wl_surface associated with the protected_surface is destroyed, + the protected_surface becomes inert. + + + + + + + + + Description of a particular type of content protection. + + A server may not necessarily support all of these types. + + Note that there is no ordering between enum members unless specified. + Over time, different types of content protection may be added, which + may be considered less secure than what is already here. + + + + + + + + + If the protected_surface is destroyed, the wl_surface desired protection + level returns to unprotected, as if set_type request was sent with type + as 'unprotected'. + + + + + + Informs the server about the type of content. The level of + content-protection depends upon the content-type set by the client + through this request. Initially, this is set to 'unprotected'. + + If the requested value is not a valid content_type enum value, the + 'invalid_type' protocol error is raised. It is not an error to request + a valid protection type the compositor does not implement or cannot + achieve. + + The requested content protection is double-buffered, see + wl_surface.commit. + + + + + + + Censor the visibility of the wl_surface contents on non-secure outputs. + See weston_protected_surface for the description. + + The force constrain mode is double-buffered, see wl_surface.commit + + + + + + Do not enforce censored-visibility of the wl_surface contents on + non-secure-outputs. See weston_protected_surface for the description. + + The relax mode is selected by default, if no explicit request is made + for enforcing the censored-visibility. + + The relax mode is double-buffered, see wl_surface.commit + + + + + + This event is sent to the client to inform about the actual protection + level for its surface in the relax mode. + + The 'type' argument indicates what that current level of content + protection that the server has currently established. + + The 'status' event is first sent, when a weston_protected_surface is + created. + + Until this event is sent for the first time, the client should assume + that its contents are not secure, and the type is 'unprotected'. + + Possible reasons the content protection status can change is due to + change in censored-visibility mode from enforced to relaxed, a new + connector being added, movement of window to another output, or, + the client attaching a buffer too large for what the server may secure. + However, it is not limited to these reasons. + + A client may want to listen to this event and lower the resolution of + their content until it can successfully be shown securely. + + In case of "enforce" mode, the client will not get any status event. + If the mode is then changed to "relax", the client will receive the + status event. + + + + + +