wayland-protocols: Add content-protection protocol

Submitted by Nautiyal, Ankit K on Jan. 28, 2019, 10:55 a.m.

Details

Message ID 1548672943-1207-1-git-send-email-ankit.k.nautiyal@intel.com
State New
Headers show
Series "wayland-protocols: Add content-protection protocol" ( rev: 1 ) in Wayland

Not browsing as part of any series.

Commit Message

Nautiyal, Ankit K Jan. 28, 2019, 10:55 a.m.
From: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

This patch adds the protocol for providing content-protection to a
client application. The content-protection here refers to the 'on the
wire protection' e.g. HDCP1.4 HDCP2.2.
The client application can request for the content-protection,
specifying the type of the content: TYPE-0 and TYPE-1 as defined in
HDCP specification. If all the connected hotpluggable displays support
the rquested content-type, the server sends an event for
content-protection status as "ON". Once the application receives this
event it can show the requested type of content.
In case if there is failure of content-protection for a given content-
type, the server sends content-protection status changed event as
"OFF". On receiving this event, the application can stop showing the
protected content.

The impelementation of this protocol is given in Merge-request:
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
where the protocol is added as weston-protocol along with a
client-application.

A similar protocol is suggested by Scot Anderson for secure-output
https://patchwork.freedesktop.org/patch/265174/

The main difference between being:
1. In content-protection protocol, client takes the call about what
should be visible on the surface. Compositor merely sets the
protection and send events if there is change in protection.
2. The content-protection property is at connector level.
If all connectors support a particular type of content, only then
the protection can be provided.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
---
 Makefile.am                                        |   1 +
 .../content-protection-unstable-v1.xml             | 130 +++++++++++++++++++++
 2 files changed, 131 insertions(+)
 create mode 100644 unstable/content-protection/content-protection-unstable-v1.xml

Patch hide | download patch | download mbox

diff --git a/Makefile.am b/Makefile.am
index 345ae6a..3ebddf4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,6 +23,7 @@  unstable_protocols =								\
 	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\
 	unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \
 	unstable/primary-selection/primary-selection-unstable-v1.xml		\
+	unstable/content-protection/content-protection-unstable-v1.xml		\
 	$(NULL)
 
 stable_protocols =								\
diff --git a/unstable/content-protection/content-protection-unstable-v1.xml b/unstable/content-protection/content-protection-unstable-v1.xml
new file mode 100644
index 0000000..52786cb
--- /dev/null
+++ b/unstable/content-protection/content-protection-unstable-v1.xml
@@ -0,0 +1,130 @@ 
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="content_protection_unstable_v1">
+	<copyright>
+	Copyright © 2019-2020 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.
+	</copyright>
+	<interface name="zwp_protected_surface_v1" version="1">
+		<description summary="interface to get content-protection object for a surface">
+		This protocol can be used to provide content-protection to a client
+		application. The content-protection here refers to the 'on the
+		wire protection' e.g. HDCP1.4 HDCP2.2. The client application
+		can request for the content-protection, specifying the type of
+		the content: TYPE-0 and TYPE-1 as defined in HDCP spec. If all the
+		connected hotpluggable displays support the rquested content-type,
+		the server sends an event for content-protection status as "ON".
+		Once the application receives this event it can show the requested
+		type of content. In case if there is failure of content-protection
+		for a given content-type, the server sends content-protection
+		status changed event as "OFF". On receiving this event, the
+		application can stop showing the protected content.
+
+		The interface protected_surface lets the client request for a
+		content-protection interface object, which is used for requesting
+		protection according to the type of content.
+
+		Warning! The protocol described in this file is experimental and
+		backward incompatible changes may be made. Backward compatible changes
+		may be added together with the corresponding interface version bump.
+		Backward incompatible changes are done by bumping the version number in
+		the protocol and interface names and resetting the interface version.
+		Once the protocol is to be declared stable, the 'z' prefix and the
+		version number in the protocol and interface names are removed and the
+		interface version number is reset.
+		</description>
+		<enum name="error">
+			<entry name="DUPLICATE_SURFACE" value="-1" summary="Protection object already assigned for this surface"/>
+		</enum>
+		<request name="destroy" type="destructor">
+			<description summary="destroy the object of protected surface interface">
+			Request to server to destroy the server side protected surface interface
+			objects.
+			</description>
+		</request>
+		<request name="get_protection">
+			<description summary="gets the surface content protection object">
+			For a given surface, creates a content-protection interface.
+			</description>
+			<arg name="id" type="new_id" interface="zwp_content_protection_v1"
+				summary="the new content_protection interface id"/>
+			<arg name="surface" type="object" interface="wl_surface"
+				summary="the surface"/>
+		</request>
+	</interface>
+
+	<interface name="zwp_content_protection_v1" version="1">
+		<description summary="application interface to enable/disable content protection">
+		This interface provides the clients a mechanism to request for content-protection.
+		The clients need to inform the server, about the content-type, according to which
+		they can control the access of content.
+		Currently two Content type categories are defined as per HDCP2.2 specification, but
+		in general there can be different categories of content.
+
+		For example, for "Premium content", the client should give as type-1 as the content type.
+		the server transfers this request to the driver for each of the active connectors.
+		If each of the connector does support the security level for the content, an event is
+		sent to the client, signifying the protection is on.
+		In case, the necessary protection for premium content is not available, the client
+		can ask for a lower type, say "HD-content", by making a request for type-0 content.
+		In case if the protection level cannot be set for HD-Content, the client can still
+		go for still lower "SD-content" without requesting for any protection.
+
+		If there are multiple clients requesting protection with different content-types,
+		the one with higher content-type, is taken into account.
+		</description>
+		<enum name="type">
+			<entry name="UNPROTECTED" value="-1" summary="Unprotected"/>
+			<entry name="0" value="0" summary="Type-0"/>
+			<entry name="1" value="1" summary="Type-1"/>
+		</enum>
+		<request name="destroy" type="destructor">
+			<description summary="unbind from the secure output interface">
+			Informs the server that the client will not be using this
+			protocol object anymore.
+			</description>
+		</request>
+
+		<request name="desired">
+			<description summary="content protection is desired">
+				Content Protection is required by the application, for a
+				given surface.
+			</description>
+			<arg name="content_type" type="int"/>
+		</request>
+		<request name="disable">
+			<description summary="disable content protection">
+				This disables the content-protection.
+			</description>
+		</request>
+		<event name="status_changed">
+			<description summary="An event to tell the client that there is a change in protection status">
+				This event is sent whenever there is a change in content protection.
+				The content protection status can be ON or OFF.
+				ON in case of the desired protection type is accepted on all connectors,
+				and Off in case of any of the connector content-protection property is
+				changed from "enabled".
+				For example in case of authentication failure, or in case of a
+				new hotplugged display, the event for change in protection status can be
+				sent to the client to take a call, according to its policy.
+			</description>
+			<arg name="status" type="int"/>
+		</event>
+	</interface>
+</protocol>

Comments

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
Hi Simon Ser,
Thanks for your comments.
I am also not sure about whether the protocol belongs here or not, and 
that's why I had first proposed the same in weston, along with the 
implementation and the client application -
Merge request: 
_https://gitlab.freedesktop.org/wayland/weston/merge_requests/48_
But I do think, its a good point to start the discussion.

Pekka, Daniel, I think we had some discussion about it in IRC as to 
wayland-extension. Does it make sense to have this in wayland-protocols?

Regards,
Ankit

On 1/28/2019 4:53 PM, Simon Ser wrote:
> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Mon, 28 Jan 2019 22:39:39 +0530
"Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com> wrote:

> Hi Simon Ser,
> Thanks for your comments.
> I am also not sure about whether the protocol belongs here or not, and 
> that's why I had first proposed the same in weston, along with the 
> implementation and the client application -
> Merge request: 
> _https://gitlab.freedesktop.org/wayland/weston/merge_requests/48_
> But I do think, its a good point to start the discussion.
> 
> Pekka, Daniel, I think we had some discussion about it in IRC as to 
> wayland-extension. Does it make sense to have this in wayland-protocols?

Hi Ankit,

obviously there debating about the scope of wayland-protocols, and I
think it is getting to a level where each camp just denies everyone
else's proposal. We need to have a serious discussion of the scope,
remove the extensions that don't belong there, and include those that
do.

But this thread is not for that discussion.

It is always possible to carry a protocol extension in Weston
repository and install it from there, and if it seems appropriate,
promote it to wayland-protocols at any time. The only catch here is
that extensions in Weston need to be namespaced to weston, and the names
will change when moved to wayland-protocols.

Such interface name changes are to be expected even in
wayland-protocols, because they are part of the documented process of
how extensions evolve in wayland-protocols. The final name change
happens when an extension is declared stable, even if there are no
other changes to it.

IOW, there is nothing here that would stop you or Scott from
co-operating and developing the extension and landing it in Weston.
Putting it in Weston saves the politics for later.


Thanks,
pq

> On 1/28/2019 4:53 PM, Simon Ser wrote:
> > 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
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel  
>
On 2/1/2019 6:15 PM, Pekka Paalanen wrote:
> On Mon, 28 Jan 2019 22:39:39 +0530
> "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com> wrote:
>
>> Hi Simon Ser,
>> Thanks for your comments.
>> I am also not sure about whether the protocol belongs here or not, and
>> that's why I had first proposed the same in weston, along with the
>> implementation and the client application -
>> Merge request:
>> _https://gitlab.freedesktop.org/wayland/weston/merge_requests/48_
>> But I do think, its a good point to start the discussion.
>>
>> Pekka, Daniel, I think we had some discussion about it in IRC as to
>> wayland-extension. Does it make sense to have this in wayland-protocols?
> Hi Ankit,
>
> obviously there debating about the scope of wayland-protocols, and I
> think it is getting to a level where each camp just denies everyone
> else's proposal. We need to have a serious discussion of the scope,
> remove the extensions that don't belong there, and include those that
> do.
>
> But this thread is not for that discussion.
>
> It is always possible to carry a protocol extension in Weston
> repository and install it from there, and if it seems appropriate,
> promote it to wayland-protocols at any time. The only catch here is
> that extensions in Weston need to be namespaced to weston, and the names
> will change when moved to wayland-protocols.
>
> Such interface name changes are to be expected even in
> wayland-protocols, because they are part of the documented process of
> how extensions evolve in wayland-protocols. The final name change
> happens when an extension is declared stable, even if there are no
> other changes to it.
>
> IOW, there is nothing here that would stop you or Scott from
> co-operating and developing the extension and landing it in Weston.
> Putting it in Weston saves the politics for later.

Thanks Pekka for the directions. I will take care of the name space in 
the weston merge request.
When we all agree to an acceptable design, we can debate, whether the 
protocol should be part of wayland-protocols or not.

Regards,

Ankit
>
>
> Thanks,
> pq
>
>> On 1/28/2019 4:53 PM, Simon Ser wrote:
>>> 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
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel