Re: [PATCH weston 1/3] weston: Add a specific option to load XWayland
Hi Quentin,
Am 04.07.2016 um 15:58 schrieb Quentin Glidic:
> From: Quentin Glidic
>
> Signed-off-by: Quentin Glidic
> ---
> compositor/main.c | 25 +++--
> man/weston.ini.man | 7 +--
> man/weston.man | 7 +--
> tests/weston-tests-env | 7 ---
> weston.ini.in | 3 ++-
> 5 files changed, 31 insertions(+), 18 deletions(-)
>
> diff --git a/compositor/main.c b/compositor/main.c
> index 6cf9194..4e6b7ae 100644
> --- a/compositor/main.c
> +++ b/compositor/main.c
> @@ -763,16 +763,11 @@ load_modules(struct weston_compositor *ec, const char
> *modules,
> end = strchrnul(p, ',');
> snprintf(buffer, sizeof buffer, "%.*s", (int) (end - p), p);
>
> - if (strstr(buffer, "xwayland.so")) {
> - if (wet_load_xwayland(ec) < 0)
> - return -1;
> - } else {
> - module_init = wet_load_module(buffer, "module_init");
> - if (!module_init)
> - return -1;
> - if (module_init(ec, argc, argv) < 0)
> - return -1;
> - }
> + module_init = wet_load_module(buffer, "module_init");
> + if (!module_init)
> + return -1;
> + if (module_init(ec, argc, argv) < 0)
> + return -1;
> p = end;
> while (*p == ',')
> p++;
> @@ -1564,6 +1559,7 @@ int main(int argc, char *argv[])
> int i, fd;
> char *backend = NULL;
> char *shell = NULL;
> + int32_t xwayland = 0;
> char *modules = NULL;
> char *option_modules = NULL;
> char *log = NULL;
> @@ -1586,6 +1582,7 @@ int main(int argc, char *argv[])
> { WESTON_OPTION_STRING, "shell", 0, &shell },
> { WESTON_OPTION_STRING, "socket", 'S', &socket_name },
> { WESTON_OPTION_INTEGER, "idle-time", 'i', &idle_time },
> + { WESTON_OPTION_BOOLEAN, "xwayland", 0, &xwayland },
> { WESTON_OPTION_STRING, "modules", 0, &option_modules },
> { WESTON_OPTION_STRING, "log", 0, &log },
> { WESTON_OPTION_BOOLEAN, "help", 'h', &help },
> @@ -1709,6 +1706,14 @@ int main(int argc, char *argv[])
> weston_config_section_get_string(section, "shell", &shell,
>"desktop-shell.so");
>
> + if (!xwayland)
> + weston_config_section_get_bool(section, "xwayland", &xwayland,
> +false);
> + if (xwayland) {
Can you make that the else clause?
--Michael
> + if (wet_load_xwayland(ec) < 0)
> + goto out;
> + }
> +
> if (load_modules(ec, shell, &argc, argv) < 0)
> goto out;
>
> diff --git a/man/weston.ini.man b/man/weston.ini.man
> index 7aa7810..1b1e05a 100644
> --- a/man/weston.ini.man
> +++ b/man/weston.ini.man
> @@ -106,14 +106,17 @@ directory are:
> .fi
> .RE
> .TP 7
> -.BI "modules=" xwayland.so,cms-colord.so
> +.BI "xwayland=" true
> +ask Weston to load the XWayland module (boolean).
> +.RE
> +.TP 7
> +.BI "modules=" cms-colord.so,screen-share.so
> specifies the modules to load (string). Available modules in the
> .IR "__weston_modules_dir__"
> directory are:
> .PP
> .RS 10
> .nf
> -.BR xwayland.so
> .BR cms-colord.so
> .BR screen-share.so
> .fi
> diff --git a/man/weston.man b/man/weston.man
> index 0c3e8dc..face229 100644
> --- a/man/weston.man
> +++ b/man/weston.man
> @@ -83,7 +83,7 @@ the X server. XWayland provides backwards compatibility to
> X applications in a
> Wayland stack.
>
> XWayland is activated by instructing
> -.BR weston " to load " xwayland.so " module, see " EXAMPLES .
> +.BR weston " to load the XWayland module, see " EXAMPLES .
> Weston starts listening on a new X display socket, and exports it in the
> environment variable
> .BR DISPLAY .
> @@ -143,6 +143,9 @@ Append log messages to the file
> .I file.log
> instead of writing them to stderr.
> .TP
> +\fB\-\-xwayland\fR
> +Ask Weston to load the XWayland module.
> +.TP
> \fB\-\-modules\fR=\fImodule1.so,module2.so\fR
> Load the comma-separated list of modules. Only used by the test
> suite. The file is searched for in
> @@ -326,7 +329,7 @@ http://wayland.freedesktop.org/
> .IP "Launch Weston with the DRM backend on a VT"
> weston-launch
> .IP "Launch Weston with the DRM backend and XWayland support"
> -weston-launch -- --modules=xwayland.so
> +weston-launch -- --xwayland
> .IP "Launch Weston (wayland-1) nested in another Weston instance (wayland-0)"
> WAYLAND_DISPLAY=wayland-0 weston -Swayland-1
> .IP "From an X terminal, launch Weston with the x11 backend"
> diff --git a/tests/weston-tests-env b/tests/weston-tests-env
> index 8a6447e..4159809 100755
> --- a/tests/weston-tests-env
> +++ b/tests/weston-tests-env
>
Re: [PATCH libinput] evdev: Be more careful about what we consider a joystick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
is there an acutal reason, why joysticks and/or gamepads are ignored
inside libinput. Is it just, that they are not yet implemented, or are
there some real reasons?
If the answer is that nobody has yet written the code, would someone
of the more knowledgeable persons on the list be willing to help me a
little (most likely a lot) to put some code together?
best wishes
Michael
Am 21.01.2015 um 12:04 schrieb Hans de Goede:
> After switching my main workstation over to using
> xf86-input-libinput, I noticed that the multi-media keys like
> play/pause on my keyboard no longer worked.
>
> It turns out that the second hid interface on my keyboard which has
> the multimedia-keys, also declares having: BTN_BASE6 and BTN_MODE
> which both fell into the range we were using to test for something
> being a joystick.
>
> The commit makes our joystick test mode strict, restoring
> functionality of the multi-media keys on the keyboard in question.
>
> Signed-off-by: Hans de Goede --- src/evdev.c
> | 25 - 1 file changed, 16 insertions(+), 9
> deletions(-)
>
> diff --git a/src/evdev.c b/src/evdev.c index 6edacba..b2bb2aa
> 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -1324,7 +1324,7 @@
> evdev_configure_device(struct evdev_device *device) struct libevdev
> *evdev = device->evdev; const struct input_absinfo *absinfo; int
> has_abs, has_rel, has_mt; - int has_button, has_keyboard,
> has_touch; + int has_button, has_keyboard, has_touch,
> has_joy_button; struct mt_slot *slots; int num_slots; int
> active_slot; @@ -1336,17 +1336,24 @@ evdev_configure_device(struct
> evdev_device *device) has_abs = 0; has_mt = 0; has_button = 0; +
> has_joy_button = 0; has_keyboard = 0; has_touch = 0;
>
> -for (i = BTN_JOYSTICK; i < BTN_DIGI; i++) { -
> if (libevdev_has_event_code(evdev, EV_KEY, i)) { -
> log_info(libinput, - "input device
> '%s', %s is a joystick, ignoring\n", -
> device->devname, devnode); -return -1; -
> } -} +for (i = BTN_JOYSTICK; i <= BTN_PINKIE; i++) +
> if
> (libevdev_has_event_code(evdev, EV_KEY, i)) + has_joy_button =
> 1; + +for (i = BTN_GAMEPAD; i <= BTN_TR2; i++) + if
> (libevdev_has_event_code(evdev, EV_KEY, i)) + has_joy_button =
> 1; + +if (has_joy_button) { + log_info(libinput, +
> "input
> device '%s', %s is a joystick, ignoring\n", +
> device->devname,
> devnode); + return -1; +}
>
> if (libevdev_has_event_type(evdev, EV_ABS)) {
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJUv4yzAAoJECfkpCAi2eFKOX0H/RYolCotiuoU6qWeTPQbiQ3x
RYcekI/lp94SkuUEtGwNleILrAV+FWfYQ8v49nP9BNZucSbJ5/qPuC3py+2J2pS0
XQcY8hUm9wq0FAxxMhunXO2y5qSXwjgZB/fbZe5gzVHrggSQQNlNMTh4ZPdzmpz/
2yKF1CMXIFmeLHqGAIEGx3cu+6tUhFKiMFKJPYa4FCyp3uqvQhUeGnkceUaH7FER
k9BFZ1XpNwEGZw+yT+DxNVaE/YJQPEle1xE1a20fRI1YCkbfy3q0VQA2+h1tdfMl
C1WV1sJArJnsks3PFK1iMYiOoAC0YMEJpsh4UQH2MAzrUPyY3e+9yOaVxlJFXMs=
=gymn
-END PGP SIGNATURE-
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Global shortkeys and keyboard focus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04/07/2014 16:04, schrieb Dodier-Lazaro, Steve: > Hi Michael, > >> Is there any reason global shortcuts should lie with an >> application? Wouldn't it make more sense to provide an interface >> on the compositor side, where clients can register a global >> shortcut and the compositor sends an event back in case of the >> shortcut being pressed. >> >> In that case the compositor could follow predefined rules >> switching focus etc. > > The problem is: what are the allowed global shortcuts leaking about > users? > > If it's any key that can be listened to, then we've just gotten > ourselves an API for implementing keyloggers. > > If it's any key + some modifier (Ctrl, Alt, etc) then we need to > see DE by DE what listening to all available key combinations lets > me learn about the user: I did not meant it in the way of a client listening to keys, but to events sent from the compositor. In no way an application should be allowed to listen to certain key combinations without focus. I thought more about a compositor plugin an application can register to (Authenticated through user) and only if the user allowed the application to receive a special shortcut, then the compositor sends an *event* to the application if that and only that shortcut was used. So the compositor acts as a middleman denieing some rogue application to listen to ctrl+c Best wishes > > - Can I listen to Alt+Tab or to the shortcut used to maximise > windows? If so can I learn the window layout of the user (or at > least whether a window is being displayed or not)? For instance > Martin proposed to use an "Expose" like view of the desktop as a > background for modal authentication dialogs, so that the user knows > it's a compositor (that is capable of moving windows around) that > is asking for your password. If I know that no windows are being > displayed because the user hasn't Alt+Tab'd for a while and just > Alt+F4'd then I can spoof that UI directly and steal your > password. > > - Can I learn if you're playing music? If you're browsing the Web? > If you're typing some document? Is that information alone useful to > profile your activities? > > - Can listening to Ctrl+C allow me to know when you're using the > clipboard despite it being a privileged interface? If I'm sniffing > your network traffic I may know that you've just landed on a site's > authentication page, and you're using the clipboard. You're > probably one of those users who have a password file that they use > to copy credentials from. I may now serve you an exploit on the > clipboard API or an exploit allowing me to scan your FS as I know > there's something that can be monetized. > > Generally speaking, there'll always be someone smarter and more > motivated than us to figure out how to build composite attacks from > seemingly innocuous APIs. So I'd rather lock down what is not > strictly necessary. How many apps need global shortcuts other than > the ones that have a semantic attached to them? How are the GUIs > for handling custom global shortcuts and Preferred handlers for > those semantic keys not enough? > > If we can cater for all common needs without exposing all your > keyboard shortcuts to potential malware, then we've done a great > job. > > Regards, -- Steve Dodier-Lazaro PhD student in Information > Security University College London Dept. of Computer Science Malet > Place Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP : > 1B6B1670 > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTtsEtAAoJECfkpCAi2eFKzFcIAKkKdUIAlbZ9MK7bjxsLllob EpsJgoS35PlcOvSPQj7Qnvzcx+B059pt9OAhknt8TID28l/M6S8pdGrKwAJ66mo8 g2bHkiVYckR1viJ5EAv5ECyYNdF8hdmiWOQmGN0sJgtBcUhkqXK8drF1EwSevrtm faD/8srG8YYIj6Ke2X7O7FldosIv/Rc/V+V2fMEAJ3yx8O5QUDOUTgcy1cnDF4XE rKHAkqiOJhhstcxInGYSDR1/DxNY3nY4QXU8odUbWmJs1hdjL5LC7T6pRmi9oVFI ciekFyVOiNuAOhxhSBIQzKOfeFxKoMtN/ZVEsxmSHuT7NAGMqO5vCSC3aTj4MVw= =QvR2 -END PGP SIGNATURE- 0x22D9E14A.asc Description: application/pgp-keys 0x22D9E14A.asc.sig Description: Binary data ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Global shortkeys and keyboard focus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.07.2014 12:53, Dodier-Lazaro, Steve wrote: > Hi Fabrice, > >> Hi all, This topic came up in my previous one about window >> placement, and I'd like to go further. So currently there is no >> such thing as Global shortkeys and keyboard focus, however let me >> present a typical real use-case: [...] >> >> Now, I've read some vague things about privileged clients, is it >> still being considered ? > > Note that most of the formalisation that occurred was done by > Martin Peres from Nouveau (and to a lesser extent myself; I'm not a > Wayland dev at all though). > > We're hoping to have a number of PoC demos of privileged clients > for XDC but are both really really busy with our research (both PhD > students). It's not clear if we will have implemented stuff to > demonstrate... If you want/need to work on global shortcuts in the > next weeks I can make an effort to make our latest discussions and > plans available in a concise form. > >> Would it be some Android-like capabilities that the user >> validates on installation or the first time they are required by >> the application ? What are the plans for these 2 key features ? > > We only discussed what the privileges are. Intercepting global > shortcuts is a privilege so your app would need to either: - have a > capability to register a global shortcut itself - be entitled by a > trusted third party to using a specific global shortcut > Is there any reason global shortcuts should lie with an application? Wouldn't it make more sense to provide an interface on the compositor side, where clients can register a global shortcut and the compositor sends an event back in case of the shortcut being pressed. In that case the compositor could follow predefined rules switching focus etc. Best wishes Michael > A capability should be granted to a package by a distributor, most > likely. This means distros who care about security would setup a > process to verify why app devs/packagers want a capability for > their app (whilst allowing core projects such as DEs/distro apps to > have privileges and be deployable right away). > > The second point is a bit fuzzier, especially for global shortcuts. > For some privileged interfaces once apps can be sandboxed on Linux, > [and once I've written a decently secure UI embedding protocol *], > they can be given widgets from a trusted third-party that the user > can interact with to organically grant privileges. Apps should also > have some nice APIs for opening and exporting resources in a secure > way. > > You can tell that it's hard to find out how to provide a global > shortcut UI abstraction that is unambiguous to users, especially > since I understand your app will be GUI-less. Xfce has a GUI for > assigning global shortcuts to commands, and I believe other DEs do > as well. This utility will typically be the one holding a > capability for intercepting any global shortcut. > > Your app should normally not qualify for such a privilege, so make > your event triggerable via a CLI call and get users to assign the > shortcut to your app. If DEs are willing to grant you full global > shortcut privileges without assessing who you are, what your app > does and in what ways your app can be compromised, they will > probably have security issues in the future. > > Feel free to work with distrubotrs to sketch out a process for > granting and revoking capabilities to third-party apps, etc. but I > think this problem goes well beyond the scope of Wayland privileged > interfaces! > > PS: you were the person proposing to let apps know or adjust their > position on the screen? This, typically, creates vulnerabilities > and makes trusted UI embedding much harder if not compromised. If > you have specific use-cases that need to be supported, please come > discuss them with us (#wayland-security on Freenode or this ML, I > guess) so we can think of secure ways to support your needs without > compromising the separation between clients and trusted UIs. > > Thanks,?? -- Steve Dodier-Lazaro PhD student in Information > Security University College London Dept. of Computer Science Malet > Place Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP : > 1B6B1670? > > > > > ___ wayland-devel > mailing list wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTtqnMAAoJECfkpCAi2eFKDHYH/il5ooHSHfwPHlElbOB3SbxI isa5PZ16kBcf5heh9Sjdg/SCfkLHjt9eSECuF8AnqRi5F1ykG0U4bej53cDm13t+ WLFvYlWyxa2esgPk83kMA8PmPOmTWMshhuZrGwcgMl5BXxt/fu44GH77ULXl3GLI 6GxGN2E/BWwjrF7IANRfbob4DGeesK5w24U84GDrp3u1KBpnASbz1/yUj7q8KSYW Pq5RgORUpLJ0nboV2551rgebbbttm3jFqQUgT53OLpEsb8P6MOb2K8+Z/IauE/hv JPDaSYzPRixhne68nyptE4BjJHOd63Ac0iElIN8JdGtVTR3TAuNSYZRiGenWzXQ= =JQ80 -END PGP SIGNATURE- ___
Re: [PATCH] terminal: Convert all *alloc's to x*alloc's.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
i might be dumb again, but as zalloc is a one line function, why not
just add the check to zalloc instead of searching for all uses of it?
Would there be any use case where one would not check for out of memory?
best wishes
Michael
On 29.04.2014 14:16, Pekka Paalanen wrote:
> On Mon, 28 Apr 2014 18:44:08 + "Bryce W. Harrington"
> wrote:
>
>> This ensures the allocation results are checked for NULL (out of
>> memory), and terminates the program in such a case.
>>
>> Signed-off-by: Bryce Harrington ---
>> clients/terminal.c |6 +++--- 1 file changed, 3 insertions(+),
>> 3 deletions(-)
>>
>> diff --git a/clients/terminal.c b/clients/terminal.c index
>> 5931ce2..924549e 100644 --- a/clients/terminal.c +++
>> b/clients/terminal.c @@ -772,10 +772,10 @@
>> terminal_resize_cells(struct terminal *terminal, } else {
>> terminal->max_width = width; data_pitch = width * sizeof(union
>> utf8_char); -data = zalloc(data_pitch *
>> terminal->buffer_height); + data = xzalloc(data_pitch *
>> terminal->buffer_height); attr_pitch = width * sizeof(struct
>> attr); - data_attr = malloc(attr_pitch *
>> terminal->buffer_height); - tab_ruler = zalloc(width); +
>> data_attr = xmalloc(attr_pitch * terminal->buffer_height); +
>> tab_ruler = xzalloc(width); attr_init(data_attr,
>> terminal->curr_attr, width * terminal->buffer_height);
>>
>
> Seems fine to me.
>
> Thanks, pq ___
> wayland-devel mailing list wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTX5yJAAoJECfkpCAi2eFKZFUH/2Ysnz0LUrgEHGecJcvDr7Ja
NkF4NU1ZZZ7RCP9Uy1KByojMyR5PaWTyOFkezgRDJbvzGJuOx8jzUFtVJyNlxBGf
9nQYL9K7vyjsWB5ZRz9Y4qXAVMv9kE44M0w3kg99hAsMKHhntOPCfXvoVElPA9jC
+TSbdmEkCkvtL9pLmGjIc/534395R0QV7M+nAqNtPZBEHWmUG92xZ3grc+NI0TIE
7j+f34XN9Ul5KPfwZtCuAEXH/fR+9Ux80vPbv+Y5kI3t4h0LbNsc/iZrj2D6VH4z
qV1GkpusxgdLfuepkKWOzqVlTAH84daDcI3eLKbhEdr2aWBiBcIB14Rgd8behLI=
=syQR
-END PGP SIGNATURE-
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 2/8] evdev: Avoid double touch down/up events
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I might be dumb but doesnt this require motion between clicks? In that case you would lose for example track balls which do not necessary move between clicks. Best wishes Michael On 25.03.2014 21:45, Jonas Ådahl wrote: > When the kernel sends multiple touch down or touch up for the same > slot in a row, ignore any such subsequent event ensuring libinput > always produces 1 x touch down -> [n x touch motion] -> 1 x touch > up event series. > > Signed-off-by: Jonas Ådahl --- src/evdev.c | 13 > + 1 file changed, 13 insertions(+) > > diff --git a/src/evdev.c b/src/evdev.c index ff8b27a..729e1f4 > 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -135,6 +135,9 @@ > evdev_flush_pending_event(struct evdev_device *device, uint32_t > time) if (slot >= MAX_SLOTS) break; > > + if (device->mt.slots[slot].seat_slot != -1) + > break; + > seat_slot = ffs(~seat->slot_map) - 1; > device->mt.slots[slot].seat_slot = seat_slot; > > @@ -171,6 +174,7 @@ evdev_flush_pending_event(struct evdev_device > *device, uint32_t time) break; > > seat_slot = device->mt.slots[slot].seat_slot; + > device->mt.slots[slot].seat_slot = -1; > > if (seat_slot == -1) break; @@ -183,6 +187,9 @@ > evdev_flush_pending_event(struct evdev_device *device, uint32_t > time) if (!(device->seat_caps & EVDEV_DEVICE_TOUCH)) break; > > + if (device->abs.seat_slot != -1) + break; > + seat_slot = > ffs(~seat->slot_map) - 1; device->abs.seat_slot = seat_slot; > > @@ -218,6 +225,7 @@ evdev_flush_pending_event(struct evdev_device > *device, uint32_t time) break; > > seat_slot = device->abs.seat_slot; + device->abs.seat_slot = -1; > > if (seat_slot == -1) break; @@ -655,6 +663,7 @@ > evdev_device_create(struct libinput_seat *seat, int rc; int fd; int > unhandled_device = 0; + int i; > > /* Use non-blocking mode so that we can loop on read on * > evdev_device_data() until all events on the fd are @@ -712,6 > +721,10 @@ evdev_device_create(struct libinput_seat *seat, if > (!device->source) goto err; > > + device->abs.seat_slot = -1; + for (i = 0; i < MAX_SLOTS; ++i) + > device->mt.slots[i].seat_slot = -1; + > list_insert(seat->devices_list.prev, &device->base.link); > notify_added_device(&device->base); > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTMneIAAoJECfkpCAi2eFKXz8H/1POqiyC9VllwxI9PUKqX/bp anHZinbHqXnj5275/RRxuGwtrRWhPNz/29bv/xSqZUF6gGXfaOJnoyNdpcYc59Lv CMtLh3JlIMy2brPSlw+0FOg4E+CLk/8xN2L0z0I2JnpU3rvcrpUlaKnmbILTuexB jyMWZYD8HsrlfAPlvbvIwCHSayhWzDoT7akgo0q52F9XuZ3NNCr/U1ieBZWiTK9O 3gCldrNIwq8ucdtKYbtS+Uw1pvCTRK+teEam/jn6ZkgZ42TsccnXpm9FQTuKUFAR rtg0Bv1QBu7Q08VyHJRs6TVghWd1gD6oddyIXWhPbEKJn1nyntGFT3y7yepysyc= =V1T3 -END PGP SIGNATURE- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
