[RDP compositor] set RDP output enabled by default (stable 1.2)

[Hardening]

This patch fixes a bug found by Marek Romanowic: the RDP peer output must
be enabled by default, or we have to unfocus/focus the RDP client window to
have disable/enable output messages sent (and finally receive updates).
---
 src/compositor-rdp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index 33ec77d..99dc487 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -572,7 +572,7 @@ static void
 rdp_peer_context_new(freerdp_peer* client, RdpPeerContext* context)
 {
context->item.peer = client;
-   context->item.flags = 0;
+   context->item.flags = RDP_PEER_OUTPUT_ENABLED;
 
context->rfx_context = rfx_context_new();
context->rfx_context->mode = RLGR3;
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v3] Fixes CJK wide character display

[David Herrmann]

Hi

On Wed, Aug 14, 2013 at 2:30 AM, Kristian Høgsberg  wrote:
> On Thu, Aug 01, 2013 at 01:49:03PM +0800, Peng Wu wrote:
>> By jumping two columns when wide character prints,
>> and draw wide cursor under wide character.
>
> Hi Peng,
>
> I do want this feature in weston-terminal, but there's still a few
> issues to address - see below.
>
>> ---
>>  clients/Makefile.am |  2 +-
>>  clients/terminal.c  | 26 --
>>  2 files changed, 25 insertions(+), 3 deletions(-)
>>
>> diff --git a/clients/Makefile.am b/clients/Makefile.am
>> index 09963cc..e7c0ece 100644
>> --- a/clients/Makefile.am
>> +++ b/clients/Makefile.am
>> @@ -113,7 +113,7 @@ weston_screenshooter_SOURCES =\
>>  weston_screenshooter_LDADD = libtoytoolkit.la
>>
>>  weston_terminal_SOURCES = terminal.c
>> -weston_terminal_LDADD = libtoytoolkit.la -lutil
>> +weston_terminal_LDADD = libtoytoolkit.la -lutil $(PANGO_LIBS)
>
> Again, I don't want to link to pango or glib... remember, the only
> reason for weston-terminal to exist is that it doesn't have any
> dependencies except cairo and the wayland libraries.
>
>>  weston_image_SOURCES = image.c
>>  weston_image_LDADD = libtoytoolkit.la
>> diff --git a/clients/terminal.c b/clients/terminal.c
>> index 0d4f726..dc56745 100644
>> --- a/clients/terminal.c
>> +++ b/clients/terminal.c
>> @@ -33,6 +33,10 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#define __USE_XOPEN
>> +#include 
>> +#include 
>>
>>  #include 
>>
>> @@ -93,6 +97,11 @@ union utf8_char {
>>   uint32_t ch;
>>  };
>>
>> +static bool is_wide(union utf8_char utf8){
>> + gunichar unichar = g_utf8_get_char((const char*) utf8.byte);
>> + return wcwidth(unichar) > 1;
>> +}
>
> ... but I just committed a patch to make the utf-8 state machine
> assemble the unicode value from the utf-8, so you can now use
> get_unicode() instead of g_utf8_get_char().
>
> Please follow the coding conventions and leave 'static int' on it's
> own line and put the opening '{' of the function on it's own line.
>
>>  enum utf8_state {
>>   utf8state_start,
>>   utf8state_accept,
>> @@ -942,6 +951,7 @@ redraw_handler(struct widget *widget, void *data)
>>   struct glyph_run run;
>>   cairo_font_extents_t extents;
>>   double average_width;
>> + double unichar_width;
>>
>>   surface = window_get_surface(terminal->window);
>>   widget_get_allocation(terminal->widget, &allocation);
>> @@ -967,6 +977,7 @@ redraw_handler(struct widget *widget, void *data)
>>   allocation.y + top_margin);
>>   /* paint the background */
>>   for (row = 0; row < terminal->height; row++) {
>> + p_row = terminal_get_row(terminal, row);
>>   for (col = 0; col < terminal->width; col++) {
>>   /* get the attributes for this character cell */
>>   terminal_decode_attr(terminal, row, col, &attr);
>> @@ -974,12 +985,17 @@ redraw_handler(struct widget *widget, void *data)
>>   if (attr.attr.bg == terminal->color_scheme->border)
>>   continue;
>>
>> + if(is_wide(p_row[col]))
>> + unichar_width = 2 * average_width;
>> + else
>> + unichar_width = average_width;
>> +
>>   terminal_set_color(terminal, cr, attr.attr.bg);
>>   cairo_move_to(cr, col * average_width,
>> row * extents.height);
>> - cairo_rel_line_to(cr, average_width, 0);
>> + cairo_rel_line_to(cr, unichar_width, 0);
>>   cairo_rel_line_to(cr, 0, extents.height);
>> - cairo_rel_line_to(cr, -average_width, 0);
>> + cairo_rel_line_to(cr, -unichar_width, 0);
>>   cairo_close_path(cr);
>>   cairo_fill(cr);
>>   }
>> @@ -1871,6 +1887,10 @@ handle_char(struct terminal *terminal, union 
>> utf8_char utf8)
>>   row[terminal->column] = utf8;
>>   attr_row[terminal->column++] = terminal->curr_attr;
>>
>> + /* cursor jump for wide character. */
>> + if (is_wide(utf8))
>> + row[terminal->column++].ch = 0;
>
> Inserting this 0 here confuses the selection logic which thinks 0
> means "end of line".  I think we can use an invalid utf-8 character
> instead to indicate that this cell is a wide-char filler.  We then
> also need to handle that in terminal_send_selection(), where we must
> ignore those filler cells when writing the selection to the fd.
>
>
>>   if (utf8.ch != terminal->last_char.ch)
>>   terminal->last_char = utf8;
>>  }
>> @@ -2711,6 +2731,8 @@ int main(int argc, char *argv[])
>>   struct terminal *terminal;
>>   int config_fd;
>>
>> + setlocale(LC_ALL, "");
>
> What is this for?

This is to work around the horrible glibc API. wcwidth() depend

Re: [PATCH v2 wayland] pkg-config: scanner isn't arch-independent

[Daniel Stone]

Hi,

On 16 August 2013 15:50, David Herrmann  wrote:
> On Fri, Aug 16, 2013 at 2:26 PM, Daniel Stone  wrote:
>> $(datadir) rather than $(libdir), is for architecture-independent data.
>> pkg-config files should only be installed there if they're shareable
>> across architectures, e.g. headers/data only, which wayland-scanner is
>> not.  Move it to $(libdir) with the other pkg-config files.
>
> Yepp, we should definitely use pkgconfig_DATA.
> Reviewed-by: David Herrmann 

Of course, this all becomes irrelevant if the patch to drop
wayland-scanner.{m4,mk,pc} gets dropped.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 wayland] pkg-config: scanner isn't arch-independent

[David Herrmann]

Hi

On Fri, Aug 16, 2013 at 2:26 PM, Daniel Stone  wrote:
> $(datadir) rather than $(libdir), is for architecture-independent data.
> pkg-config files should only be installed there if they're shareable
> across architectures, e.g. headers/data only, which wayland-scanner is
> not.  Move it to $(libdir) with the other pkg-config files.
>
> Signed-off-by: Daniel Stone 
> ---
>
> v2: Oops, wasn't looking when I pulled this over from my other tree.
> Fix = vs. +=.
>
>  src/Makefile.am | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 4226f63..efdfaf4 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -58,8 +58,7 @@ wayland_scanner_LDADD = $(EXPAT_LIBS) libwayland-util.la
>
>  $(BUILT_SOURCES) : wayland-scanner
>
> -scannerpkgconfigdir = $(datadir)/pkgconfig
> -scannerpkgconfig_DATA = wayland-scanner.pc
> +pkgconfig_DATA += wayland-scanner.pc

Yepp, we should definitely use pkgconfig_DATA.
Reviewed-by: David Herrmann 

Cheers
David

>  endif
>
>  BUILT_SOURCES =\
> --
> 1.8.3.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] autotools: Don't use wayland-scanner.m4

[Daiki Ueno]

---
As Kristian pointed in:

wayland-scanner.m4 is not so beneficial compared to copying a few
lines of autoconf/makefile snippets around.  After this,
wayland-scanner.{pc,m4,mk} could be dropped from wayland.

 clients/Makefile.am  |  8 +++-
 configure.ac |  5 ++---
 src/Makefile.am  |  8 +++-
 src/xwayland/Makefile.am |  8 +++-
 tests/Makefile.am| 11 ++-
 5 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/clients/Makefile.am b/clients/Makefile.am
index 1f7d9dc..afd93b3 100644
--- a/clients/Makefile.am
+++ b/clients/Makefile.am
@@ -254,7 +254,13 @@ endif
 
 endif
 
-@wayland_scanner_rules@
+wayland_protocoldir = $(top_srcdir)/protocol
+
+%-protocol.c : $(wayland_protocoldir)/%.xml
+   $(AM_V_GEN)$(wayland_scanner) code < $< > $@
+
+%-client-protocol.h : $(wayland_protocoldir)/%.xml
+   $(AM_V_GEN)$(wayland_scanner) client-header < $< > $@
 
 if HAVE_POPPLER
 poppler_programs = weston-view
diff --git a/configure.ac b/configure.ac
index fab0b48..e305ab0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -423,9 +423,8 @@ if test "x$have_lcms" = xyes; then
 fi
 AM_CONDITIONAL(HAVE_LCMS, [test "x$have_lcms" = xyes])
 
-m4_ifndef([WAYLAND_SCANNER_RULES],
- [m4_fatal([WAYLAND_SCANNER_RULES not found. Point ACLOCAL to 
wayland-scanner.m4 before running autoconf/autogen])])
-WAYLAND_SCANNER_RULES(['$(top_srcdir)/protocol'])
+AC_PATH_PROG([wayland_scanner], [wayland-scanner],
+[AC_MSG_ERROR("wayland-scanner is needed to compile weston")])
 
 AC_CONFIG_FILES([Makefile
 shared/Makefile
diff --git a/src/Makefile.am b/src/Makefile.am
index 929de31..3f3b4c4 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -314,4 +314,10 @@ BUILT_SOURCES =\
 
 CLEANFILES = $(BUILT_SOURCES)
 
-@wayland_scanner_rules@
+wayland_protocoldir = $(top_srcdir)/protocol
+
+%-protocol.c : $(wayland_protocoldir)/%.xml
+   $(AM_V_GEN)$(wayland_scanner) code < $< > $@
+
+%-server-protocol.h : $(wayland_protocoldir)/%.xml
+   $(AM_V_GEN)$(wayland_scanner) server-header < $< > $@
diff --git a/src/xwayland/Makefile.am b/src/xwayland/Makefile.am
index 82ad53d..68cbabb 100644
--- a/src/xwayland/Makefile.am
+++ b/src/xwayland/Makefile.am
@@ -35,4 +35,10 @@ BUILT_SOURCES =  \
 
 CLEANFILES = $(BUILT_SOURCES)
 
-@wayland_scanner_rules@
+wayland_protocoldir = $(top_srcdir)/protocol
+
+%-protocol.c : $(wayland_protocoldir)/%.xml
+   $(AM_V_GEN)$(wayland_scanner) code < $< > $@
+
+%-server-protocol.h : $(wayland_protocoldir)/%.xml
+   $(AM_V_GEN)$(wayland_scanner) server-header < $< > $@
diff --git a/tests/Makefile.am b/tests/Makefile.am
index d4aa909..7d1d928 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -139,4 +139,13 @@ BUILT_SOURCES =\
 
 CLEANFILES = $(BUILT_SOURCES)
 
-@wayland_scanner_rules@
+wayland_protocoldir = $(top_srcdir)/protocol
+
+%-protocol.c : $(wayland_protocoldir)/%.xml
+   $(AM_V_GEN)$(wayland_scanner) code < $< > $@
+
+%-server-protocol.h : $(wayland_protocoldir)/%.xml
+   $(AM_V_GEN)$(wayland_scanner) server-header < $< > $@
+
+%-client-protocol.h : $(wayland_protocoldir)/%.xml
+   $(AM_V_GEN)$(wayland_scanner) client-header < $< > $@
-- 
1.8.3.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] protocol: Extend wayland seat with interfaces for sensor inputs.

[Stefan Schmidt]

Hello.

Sorry for the delay. Got sick in between.
Thanks for taking the time to review this.

On 08/12/2013 05:14 PM, Thomas Daede wrote:

On Thu, Aug 1, 2013 at 3:39 AM, Stefan Schmidt 
wrote:


+
+  
sensor">

+   Updated sensor data available from compass
+  
+  
+  
+  
+


These events don't have any units, and there isn't any particular
information about the sensor passed either. Is this supposed to be
read out of band? Presuming the motion integration happens in the
client. it's very important for a coordinate system to be defined
between the accelerometer, gyroscope, and compass, and information
like sensor bandwidth is also important.


I added units as well as a coordinate system description now. Please see 
the attachment for the current version and let me know if that covers 
it. Going to send it out next week and would be happy about more 
feedback. :)



Sensors that combine all three of the above with an integral IMU
processor are also becoming more and more common - that's at least one
more type that we will need. I definitely think the interface should
be designed - the abstraction has to be somewhere, and I'd prefer it


Did you miss to finish the sentence? My parser fails on it. :)


here rather than every client accessing the devices directly - but I
want to make sure that this is possible with all sorts of devices in
the future.


What exactly are you missing? I started small here on purpose. But based 
on some real needs this can be extended. Nothing set in stone.



There a number of other devices that I'd like to see implemented in
this manner - for example, 3D mice. In this case, unlike the motion
sensors, window focus does matter.


What would you propose to handle these?

regards
Stefan Schmidt

>From 77b19aeff0b1c65625a4aa3b41821c61afa9ea6e Mon Sep 17 00:00:00 2001
From: Stefan Schmidt 
Date: Tue, 9 Jul 2013 15:36:41 +0100
Subject: [PATCH] protocol: Extend wayland seat with interfaces for sensor
 inputs.

Treating some specific sensors as input devices. In particular
adding support for wl_compass, wl_gyroscope and wl_accelerometer here.

Using these sensor as input for apps and games. Not covering any
background apps or services with this protocol.

We have requests to start and stop sensor event receiving as well as
events to receive the different axis values for these sensors.

V2:
o Add units to event arguments
o Define coordinate system

Signed-off-by: Stefan Schmidt 
---
 protocol/wayland.xml |  142 ++
 1 file changed, 142 insertions(+)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index d79..ee295a1 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1251,6 +1251,9 @@
   
   
   
+  
+  
+  
 
 
 
@@ -1297,6 +1300,39 @@
 
 
 
+
+  
+The ID provided will be initialized to the wl_compass interface
+	for this seat.
+
+This request only takes effect if the seat has the compass
+capability.
+  
+  
+
+
+
+  
+The ID provided will be initialized to the wl_gyroscope interface
+	for this seat.
+
+This request only takes effect if the seat has the gyroscope
+capability.
+  
+  
+
+
+
+  
+The ID provided will be initialized to the wl_accelerometer interface
+	for this seat.
+
+This request only takes effect if the seat has the accelerometer
+capability.
+  
+  
+
+
 
   
 	In a multiseat configuration this can be used by the client to help
@@ -1605,6 +1641,112 @@
 
   
 
+  
+
+  The wl_compass interface represents a compass
+  associated with a seat.
+
+
+
+  
+	Sent to enable event receiving for the compass sensor.
+  
+
+
+
+  
+	Sent to disable event receiving for the compass sensor.
+  
+
+
+
+  
+	Updated sensor data available from compass
+
+	Measurement of the ambient magnetic field in the X, Y and Z axis.
+
+	Coordinate system (device in portrait mode with screen facing upwards):
+	X axis goes from the left to the right side of the device
+	Y axis goes from the bottom of the screen to the top
+	Z axis goes from the back of the screen to the front of the screen
+ 
+  
+  
+  
+
+  
+
+  
+
+  The wl_gyroscope interface represents a gyroscope
+  associated with a seat.
+
+
+
+  
+	Sent to enable event receiving for the gyroscope sensor.
+  
+
+
+
+  
+	Sent to disable event receiving for the gyroscope sensor.
+  
+
+
+
+  
+	Updated sensor data available from gyroscope
+
+	Measurement of the rate of rotation around X, Y and Z axis in degree per second.
+	Values are observed in positive notation in the counter-clockwise direction.
+
+	Coordinate system (device in portrait mode with screen facing upwards):
+	X axis goes from the left to the right side of the devi

Re: [RFC] protocol: Extend wayland seat with interfaces for sensor inputs.

[Stefan Schmidt]

Hello.

Sorry for the late reply. Got sick in between.
First of all thanks for taking the time to review this and provide feedback.

On 08/12/2013 04:54 PM, David Herrmann wrote:

On Thu, Aug 1, 2013 at 10:39 AM, Stefan Schmidt 
wrote:

Treating some specific sensors as input devices. In particular
adding support for wl_compass, wl_gyroscope and wl_accelerometer here.

We have requests to start and stop sensor event receiving as well as
events to receive the different axis values for these sensors.

Signed-off-by: Stefan Schmidt 
---
  protocol/wayland.xml |  123

++

  1 file changed, 123 insertions(+)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 3cfa953..066a718 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1251,6 +1251,9 @@

devices"/>


more keyboards"/>


devices"/>

+  
devices"/>

+  
gyroscope devices"/>

+  
accelerometer devices"/>

If we add all kinds of devices here, we will very soon run out of
space for 32bit bitfields (which I think wayland uses for "uint"). I
don't have a solution, but we should keep this in mind.


Lets hope for now we don't have more than 26 different device types 
coming up.



  

  
@@ -1297,6 +1300,39 @@

  

+
+  
+The ID provided will be initialized to the wl_compass interface
+   for this seat.
+
+This request only takes effect if the seat has the compass
+capability.
+  
+  
+
+
+
+  
+The ID provided will be initialized to the wl_gyroscope

interface

+   for this seat.
+
+This request only takes effect if the seat has the gyroscope
+capability.
+  
+  
+
+
+
+  
+The ID provided will be initialized to the wl_accelerometer

interface

+   for this seat.
+
+This request only takes effect if the seat has the

accelerometer

+capability.
+  
+  
+
+


This interface limits each seat to one device of each. For keyboards
or mouse we internally merge these into a single virtual device, but
we cannot do this for accelerometers or gyros. We had a discussion
about that recently, I am not sure about the conclusion, though. If
there was one, please include it in the commit message.


You answered that yourself below. We should allow to cope with more then 
one sensor device per type. I really want to avoid doing that right now 
though. Having the protocol to allow for it but not doing it right now.



Besides, why are these devices bound to seats? Where are these devices
supposed to be? An accelerometer can be attached to an input device,
an HDD, a laptop, a tablet, ... If you look at this from a
smartphone/tablet view, it is obvious. But for desktops it really
isn't clear whose data an accelerometer device reports.


Indeed phones and tablets are my main focus right now but it should work 
for desktops and laptops as well. It should be a sensor that is really 
meant for input though. An accelerometer inside your harddisk might be 
used for that (played games with it on an older Thinkpad) but is not the 
use case here. Neither are background apps or services.


I would like to reduce this proposal to real input for apps and games. 
The wayland protocol should not define sensor access for the whole system.



I guess these devices are meant to be attached to the input device
that this seat/user uses. In this case it makes sense to allow only a
single device and bind them to seats. But please clarify this in the
description. No one cares if the description is 1000 words long, so
feel free to be verbose.


Next version will be more verbose. Means another chance to spot what I 
missed. :)



  

 In a multiseat configuration this can be used by the client to

help

@@ -1605,6 +1641,93 @@
  


+  
+
+  The wl_compass interface represents a compass
+  associated with a seat.
+
+
+
+  
+   Sent to enable event receiving for the compass sensor.
+  
+
+
+
+  
+   Sent to disable event receiving for the compass sensor.
+  
+


So this is a shared device. Please note that down. A compositor has to
broadcast events to all interested clients, otherwise this API doesn't
work (or is inconsistent). Did you think of the implications of that?
Might be fine, but I don't see any discussion, so please elaborate.
What are the reasons to allow background applications to access
compass/accelerometer/gyro? That is, why didn't you follow the
enter/leave API?

I don't want change your API, but the short descriptions give me the
impression that you didn't think about these implications so I'd like
to see some explanations. And the longer the descriptions, the less
bikeshed you get.. as usual.


I thought about them in the beginning but did not took them into account 
when actually writing the protocol changes. So you have a point here. :)


Shou

[PATCH v2 wayland] pkg-config: scanner isn't arch-independent

[Daniel Stone]

$(datadir) rather than $(libdir), is for architecture-independent data.
pkg-config files should only be installed there if they're shareable
across architectures, e.g. headers/data only, which wayland-scanner is
not.  Move it to $(libdir) with the other pkg-config files.

Signed-off-by: Daniel Stone 
---

v2: Oops, wasn't looking when I pulled this over from my other tree.
Fix = vs. +=.

 src/Makefile.am | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 4226f63..efdfaf4 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -58,8 +58,7 @@ wayland_scanner_LDADD = $(EXPAT_LIBS) libwayland-util.la
 
 $(BUILT_SOURCES) : wayland-scanner
 
-scannerpkgconfigdir = $(datadir)/pkgconfig
-scannerpkgconfig_DATA = wayland-scanner.pc
+pkgconfig_DATA += wayland-scanner.pc
 endif
 
 BUILT_SOURCES =\
-- 
1.8.3.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland] pkg-config: scanner isn't arch-independent

[Daniel Stone]

$(datadir) rather than $(libdir), is for architecture-independent data.
pkg-config files should only be installed there if they're shareable
across architectures, e.g. headers/data only, which wayland-scanner is
not.  Move it to $(libdir) with the other pkg-config files.

Signed-off-by: Daniel Stone 
---
 src/Makefile.am | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 4226f63..4211b59 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -58,8 +58,7 @@ wayland_scanner_LDADD = $(EXPAT_LIBS) libwayland-util.la
 
 $(BUILT_SOURCES) : wayland-scanner
 
-scannerpkgconfigdir = $(datadir)/pkgconfig
-scannerpkgconfig_DATA = wayland-scanner.pc
+pkgconfig_DATA = wayland-scanner.pc
 endif
 
 BUILT_SOURCES =\
-- 
1.8.3.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel