Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1

On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote: > From: Lyude > > This primary selection is similar in spirit to the eponimous > in X11, allowing a quick "select text + middle click" shortcut > to copying and pasting. > > It's otherwise very similar to it

[PATCH wayland] tests: Test creating a shm pool with 0 size

Add a test case that tests the servers behaviour when creating a pool of size 0. The test suite will do the memory and fd leak check for us, so the test case is only a triggerer. Signed-off-by: Jonas Ådahl --- Makefile.am | 5 ++- tests/shm-test.c | 108

[PATCH wayland] client: Don't segfault when receiving error on destroyed object

If an error is received on a destroyed object, we'd get NULL passed to display_handle_error() instead of a pointer to a valid wl_proxy. The logging is changed to report [unknown interface] and [unknown id] instead of the actual interface name and id. The wl_display_get_protocol_error()

Re: [PATCH] server: Fix shm_create_pool size fail path fd leak

On Fri, Feb 19, 2016 at 11:13:25AM +0100, xerpi wrote: > I was just reading the source when I found it (no valgrind involved). So > as wl_connection_destroy() already takes care of that, my patch is > pointless. I was wrong. Your patch is correct, and we do actually leak it. The fd list that is

[PATCH v3 wayland 3/3] doc: generate doxygen html output from the scanner

This switches the scanner to generate doxygen-compatible tags for the generated protocol headers, and hooks up the doxygen build to generate server and client-side API documentation. Each protocol is a separate doxygen @page, with each interface a @subpage. Wayland only has one protocol,

[PATCH weston v0] refactor configuration API of wayland-backend

Hello, Here is my proposal to update the configuration API of wayland-backend. I did not tried to mimic the old configuration behaviors but instead I guessed it. If someone can help me and describe the desired behaviors, I will be happy to update the patch accordingly. Currently the behaviors is

Re: [RFC libinput] Add dial input device support

> remember that libinput is a low-level library and doesn't know about how a > specific device is being used by the layers above it. Hence a value in > degrees isn't any less useful than a value in miscellaneous units which is > what the _discrete() API bit is for. If the caller cares about units,