[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
Hi,
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.
Thanks,
--
Simon Ser
https://emersion.fr
More information about the wayland-devel
mailing list