[PATCH RFC wayland-protocols] Add secure output protocol

Simon Ser contact at emersion.fr
Mon Nov 19 07:21:46 UTC 2018

On Monday, November 19, 2018 4:21 AM, <scott.anderson at collabora.com> wrote:
> From: Scott Anderson <scott.anderson at collabora.com>
> This protocol allows a client to ask the compositor to only allow it to
> be displayed on a "secure" output (e.g. HDCP).
> This is based on a chromium protocol of the same name [1].
> This protocol is mostly useful for closed systems, 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
> protocol deliberately doesn't define what a "secure output" is, and the
> compositor would be free to lie to the client anyway.
> Signed-off-by: Scott Anderson <scott.anderson at collabora.com>
> [1] https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml
> ---
> Intel has proposed a similar protocol as a Weston merge request [2].
> I believe these two protocols should be compared and merged to try and
> come up with a general solution that everybody is happy with.
> While this protocol is currently intended for using HDCP, I don't
> believe it should be tied to HDCP in any way. If any other similar
> technology is developed, it would be nice to not need to define a new
> protocol or modify this one.
> I don't think it's necessary for the client to know what type of
> protection the compositor is providingi or if the protection status of
> an output changes. It's up to the compositor to choose and negotiate
> what kind of protection is required, and all the client needs to do is
> trust that the compositor is putting their content on a secure output.
> Clients should have no control or knowledge of how/where they're
> presented.
> The protocol also should be per wl_surface, instead of any type of
> global client state. A client can have multiple surfaces, and they could
> need to be treated differently. For example, one surface may be the
> protected content which uses this interface, and the other may be a
> dialog box which could be placed anywhere.
> [2] https://gitlab.freedesktop.org/wayland/weston/blob/bb546cbbaaf6257ce018e7392747cc0fbdc1639f/protocol/content-protection.xml


Thanks for your patch. However, I don't think it belongs to wayland-protocols.
wayland-protocols isn't designed for all common Wayland protocols. For instance,
the IVI shell isn't there, and has a similar use-case (although not limited to
closed systems). Also some other protocols like layer-shell have been rejected.

I think a Weston patch in protocols/ would be better suited. This would allow
protocol consumers to share the protocol while not including it in a repository
where it won't be used because a large majority of wayland-protocols users don't
have closed systems.

That said, wayland-protocols' scope is ill-defined, so it's not like it's easy
to decide whether it belongs here or not.


Simon Ser

More information about the wayland-devel mailing list