[RFC,wayland-protocols] Add secure output protocol

Submitted by Scott Anderson on Nov. 19, 2018, 3:21 a.m.

Details

Message ID 20181119032140.19952-1-scott.anderson@collabora.com
State New
Series "Add secure output protocol"
Headers show

Commit Message

Scott Anderson Nov. 19, 2018, 3:21 a.m.
From: Scott Anderson <scott.anderson@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@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

 Makefile.am                                   |   1 +
 unstable/secure-output/README                 |   4 +
 .../secure-output-unstable-v1.xml             | 119 ++++++++++++++++++
 3 files changed, 124 insertions(+)
 create mode 100644 unstable/secure-output/README
 create mode 100644 unstable/secure-output/secure-output-unstable-v1.xml

Patch hide | download patch | download mbox

diff --git a/Makefile.am b/Makefile.am
index 345ae6a..4d94747 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/secure-output/secure-output-unstable-v1.xml		\
 	$(NULL)
 
 stable_protocols =								\
diff --git a/unstable/secure-output/README b/unstable/secure-output/README
new file mode 100644
index 0000000..3251af9
--- /dev/null
+++ b/unstable/secure-output/README
@@ -0,0 +1,4 @@ 
+Secure output protocol
+
+Maintainers:
+David Reveman <reveman@chromium.org>
diff --git a/unstable/secure-output/secure-output-unstable-v1.xml b/unstable/secure-output/secure-output-unstable-v1.xml
new file mode 100644
index 0000000..63a2cdf
--- /dev/null
+++ b/unstable/secure-output/secure-output-unstable-v1.xml
@@ -0,0 +1,119 @@ 
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="secure_output_unstable_v1">
+
+  <copyright>
+    Copyright 2016 The Chromium Authors.
+    Copyright 2018 Collabora, Ltd.
+
+    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>
+
+  <description summary="Protocol for providing secure output">
+    This protocol specifies a set of interfaces used to prevent surface
+    contents from appearing in screenshots or from being visible on non-secure
+    outputs.
+
+    In order to prevent surface contents from appearing in screenshots or from
+    being visible on non-secure outputs, a client must first bind the global
+    interface "wp_secure_output" which, if a compositor supports secure output,
+    is exposed by the registry. Using the bound global object, the client uses
+    the "get_security" request to instantiate an interface extension for a
+    wl_surface object. This extended interface will then allow surfaces
+    to be marked as only visible on secure outputs.
+
+    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>
+
+  <interface name="zwp_secure_output_v1" version="1">
+    <description summary="secure output">
+      The global interface exposing secure output capabilities is used
+      to instantiate an interface extension for a wl_surface object.
+      This extended interface will then allow surfaces to be marked as
+      as only visible on secure outputs.
+    </description>
+
+    <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. This does not affect any other objects,
+	security objects included.
+      </description>
+    </request>
+
+    <enum name="error">
+      <entry name="security_exists" value="0"
+	     summary="the surface already has a security object associated"/>
+    </enum>
+
+    <request name="get_security">
+      <description summary="extend surface interface for security">
+	Instantiate an interface extension for the given wl_surface to
+	provide surface security. If the given wl_surface already has
+	a security object associated, the security_exists protocol error
+	is raised.
+      </description>
+
+      <arg name="id" type="new_id" interface="zwp_security_v1"
+	   summary="the new security interface id"/>
+      <arg name="surface" type="object" interface="wl_surface"
+	   summary="the surface"/>
+    </request>
+  </interface>
+
+  <interface name="zwp_security_v1" version="1">
+    <description summary="security interface to a wl_surface">
+      An additional interface to a wl_surface object, which allows the
+      client to specify that a surface should not appear in screenshots
+      or be visible on non-secure outputs.
+
+      If the wl_surface associated with the security object is destroyed,
+      the security object becomes inert.
+
+      If the security object is destroyed, the security state is removed
+      from the wl_surface. The change will be applied on the next
+      wl_surface.commit.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="remove security from the surface">
+	The associated wl_surface's security state is removed.
+	The change is applied on the next wl_surface.commit.
+      </description>
+    </request>
+
+    <request name="only_visible_on_secure_output">
+      <description summary="set the only visible on secure output state">
+	Constrain visibility of wl_surface contents to secure outputs.
+	See wp_secure_output for the description.
+
+	The only visible on secure output state is double-buffered state,
+	and will be applied on the next wl_surface.commit.
+      </description>
+    </request>
+  </interface>
+
+</protocol>

Comments

Simon Ser Nov. 19, 2018, 7:21 a.m.
On Monday, November 19, 2018 4:21 AM, <scott.anderson@collabora.com> wrote:
> From: Scott Anderson <scott.anderson@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@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
Nautiyal, Ankit K Nov. 19, 2018, 8:58 a.m.
On 11/19/2018 12:51 PM, Simon Ser wrote:
> On Monday, November 19, 2018 4:21 AM, <scott.anderson@collabora.com> wrote:
>> From: Scott Anderson <scott.anderson@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@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.
Thanks Scott, for going through the proposed protocol [2] which I had 
sent couple of week back, for content-protection support in wayland/weston.
I do agree that some thing from both of the proposed solutions can be 
taken and we get a generalized protocol, provided they provide similar 
support.

The proposed protocol [2] is surely being written with HDCP in mind, but 
does not necessarily tied to HDCP.

There were a couple of discussions on #wayland IRC and mails around this:

https://lists.freedesktop.org/archives/wayland-devel/2018-June/038446.html
https://lists.freedesktop.org/archives/wayland-devel/2018-June/038511.html

In general for any such content-protection, the key things to consider 
here are:

The protection level can be more than one, depending on the 
content-type. Suppose there are categories of contents say - premium, 
deluxe, standard.
that might need different type of protections on the wire. The "premium" 
perhaps can be UHD content, supported on Very high end displays,
;deluxe with HD content, supported on somewhat next level of displays, 
and standard on most displays.

Suppose an application wants to show, the content-with highest 
resolution, but the connected displays do not have sufficient capability 
for "on the wire protection"
it might want to try to show a lower resolution which perhaps can be 
protected with not with the highest protection, but still acceptable 
protection.
Suppose even that is not possible, the client still can try to show some 
content, perhaps even lower resolution, to the unprotected displays.

Bottom line - clients should be able to tell the compositor, what is the 
type of content is, based on that, the level of protection can be chosen 
by the compositor.
In the proposed solution, the names are taken from Type-0 and Type-1 
which come from HDCP specification, but there can be generic names.

>>
>> 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 client does not need to know:
- the protocol used for content-protection
- the individual support each of the connected display provides.

But what it might be interested to know is:
-whether the protection level is reasonable for the content it want to show.
-run time changes in the overall level of protection.
In case of hotunplug of a High end display, supporting, some level of 
security, and hotplug of an unprotected display,
the client needs to know, that the protection status, it can then take a 
call whether to downgrade the content or keep on
showing same content.
The compositor should not be burdened about any policies here.

>> 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.
The protection here is display-level.
As per earlier discussions, there might be many displays connected with 
different levels of security.
Since the app surface, should be free to dragged from one display to 
another, there has to be the minimum level of protection
supported by all the displays.
Not sure, how the surfaces can ask for individual levels of protection. 
Perhaps I might be missing something.

Thanks & Regards,
Ankit

[2] https://gitlab.freedesktop.org/wayland/weston/blob/bb546cbbaaf6257ce018e7392747cc0fbdc1639f/protocol/content-protection.xml




>>
>> [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.

Simon Ser, I was initially wondering the same while sending 
merge-request for [2].
I went ahead and added the protocol in weston, to have the client and 
protocol being discussed at one place.

The next question would be, for protocols such as Scott or I have sent, 
where the server should be kept?

>
> Thanks,
>
> --
> Simon Ser
> https://emersion.fr
Scott Anderson Nov. 21, 2018, 2:05 a.m.
Hi,

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.

<interface name="...">
   <event name="secure_resolution">
     <arg name="width", type="int">
     <arg name="height", type="int">
     <arg name="refresh", type="int">
   </event>
</interface>

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.

Scott
C, Ramalingam Nov. 22, 2018, 7:31 a.m.
Hi Scott,

I am working on enabling the HDCP1.4 and 2.2 in kernel and Weston from 
Intel. Would like to share some points here.

On 11/21/2018 7:35 AM, Scott Anderson wrote:
> Hi,
>
> 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.
>
> <interface name="...">
>   <event name="secure_resolution">
>     <arg name="width", type="int">
>     <arg name="height", type="int">
>     <arg name="refresh", type="int">
>   </event>
> </interface>
>
> 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.

But the problem is HDCP2.2 spec leave the content type classification(type 0 and Type 1) to the content provider (in our case client).

As you mentioned these type classifications just mandates the minimum HDCP spec that they need to be authenticated with.
Like Type 0 content can be transmitted to HDCP1.4 /2.2 authenticated digital sink but where as Type 1
has to be transmitted the HDCP2.2 authenticated digital sink.

Considering this we can see that type of content should come from content providers (clients). And as pekka mentioned in runtime
any surfaces can be dragged to any output, compositor/hdcp protocol server will make sure all the required sinks are
authenticated with minimum required HDCP spec. And clients trust the compositors on the status events generated.

These HDCP protection status prone to break incase of new hotplug. So compositor needs to give the status as
whether content protection status has met the type requirement from client or not.

In this way IMHO we need not tag the surface whether protected or not and filter them on outputs based on their content protection status.
Based on the compositor events let the surface provider (client) decide whether required HDCP status is met to render the protected surface or not.

This makes the design simple and to the requirement. Please point me out if something is missed in this approach.

Thanks,
--Ram

>
> 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.
>
> Scott
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Nautiyal, Ankit K Nov. 22, 2018, 9:50 a.m.
On 11/22/2018 1:01 PM, C, Ramalingam wrote:
>
> Hi Scott,
>
> I am working on enabling the HDCP1.4 and 2.2 in kernel and Weston from 
> Intel. Would like to share some points here.
>
> On 11/21/2018 7:35 AM, Scott Anderson wrote:
>> Hi,
>>
>> 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?

No it does not matter to client, and it does not matter to the 
compositor as well.
The policy that which protocol to use, for the given content type rests 
with the kernel.
If HDCP2.2 is the strongest available (on all connected connectors), the 
kernel will use it, even if the content is 720p.

>>
>> 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.

In case of HDCP, A HDCP2.2 compliant sink supports Type-0 and Type-1
and HDCP1.4 supports Type-0 only.
The compositor at most can tell the client, based on the capabilities of 
the connected displays, the highest type of content that it can show 
securely.
The client can then show the content according to the suggested type or 
lower.

The problem with that is - for getting the capabilities of the connected 
displays, kernel needs to actually do full authentication on all connectors.
Which will not be useful, if the client does not have the content with 
suggested type.


>>
>> <interface name="...">
>>   <event name="secure_resolution">
>>     <arg name="width", type="int">
>>     <arg name="height", type="int">
>>     <arg name="refresh", type="int">
>>   </event>
>> </interface>
>>
>> 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.
> But the problem is HDCP2.2 spec leave the content type classification(type 0 and Type 1) to the content provider (in our case client).

Yes right, mostly the content-provider, if one considers services like 
Netflix, Amazon prime etc, divide the type of content as UHD, FHD, SD 
based on stream quality.
UHD is mostly 4K which definitely will require highest protection, FHD 
that would be 1080P, would require some reasonable protection and the SD 
that will be below 1080P, in case of no-protection at all.
In that view, instead of client passing the resolution, the content-type 
or category (Type 0  and Type 1 as defined by hdmi spec) seems to be 
more in line with what content-providers would like, than the resolution.

Regards,
Ankit

> As you mentioned these type classifications just mandates the minimum HDCP spec that they need to be authenticated with.
> Like Type 0 content can be transmitted to HDCP1.4 /2.2 authenticated digital sink but where as Type 1
> has to be transmitted the HDCP2.2 authenticated digital sink.
>
> Considering this we can see that type of content should come from content providers (clients). And as pekka mentioned in runtime
> any surfaces can be dragged to any output, compositor/hdcp protocol server will make sure all the required sinks are
> authenticated with minimum required HDCP spec. And clients trust the compositors on the status events generated.
>
> These HDCP protection status prone to break incase of new hotplug. So compositor needs to give the status as
> whether content protection status has met the type requirement from client or not.
>
> In this way IMHO we need not tag the surface whether protected or not and filter them on outputs based on their content protection status.
> Based on the compositor events let the surface provider (client) decide whether required HDCP status is met to render the protected surface or not.
>
> This makes the design simple and to the requirement. Please point me out if something is missed in this approach.
>
> Thanks,
> --Ram
>>
>> 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.
>>
>> Scott
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel