[PATCH RFC wayland-protocols] Add secure output protocol
scott.anderson at collabora.com
Wed Nov 21 02:05:31 UTC 2018
As far as I understand, the different types and versions of protection a
client would want is based on the resolution of the content, rather than
anything about what the content actually is. Is there any particular
reason a client would care if their content is being used on a higher
HDCP version than is necessary? e.g. would a client with 720p content
care about using HDCP 2.2?
If that's the case, I think it would make sense for the compositor to
always try to negotitate the strongest level of protection that it can
(or a lower level if set by some policy), and report to the client the
largest resolution that it can support securely. With that, the client
can then make the decision about what content it can provide.
<arg name="width", type="int">
<arg name="height", type="int">
<arg name="refresh", type="int">
This would remove a lot of the back-and-forth between the client and the
compositor, where the client says what content it has, and the
compositor saying if it can securely display it.
This event could also be re-emitted when the protection status changes.
There could also be the special case of 0x0, where the compositor failed
to negotiate any secure connection, and no resolution is secure.
A compositor may also choose to emit this signal based on what output
the client is set to display on, but that would probably be left up to
the compositor policy. It's possible that wl_output could be integrated
into this somehow, but I haven't thought too much about how yet.
More information about the wayland-devel