Re: [PATCH libinput] evdev: don't return a width/height if we faked the resolution

Hi, On 08/04/2014 03:51 AM, Peter Hutterer wrote: Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Looks good: Reviewed-by: Hans de Goede hdego...@redhat.com Regards, Hans --- src/evdev.c | 7 ++- src/evdev.h | 3 ++- 2 files changed, 8 insertions(+), 2 deletions(-) diff

[PATCH] client: clarify wl_display_prepare_read() semantics

From the doc comment I get the feeling, that after successfull call to wl_display_prepare_read(), the thread gains exclusive access to the fd. That is not true. It only ensures that _one_ of the threads, that called this function, will read from the fd and there will be no race. Here's slice of

Re: [PATCH 3/3] tests: test posting errors

ping tests for the patch that were pushed few days ago ( 886b09c9a3a9d8672039f09fe7eaf3f2b2b012ca http://cgit.freedesktop.org/wayland/wayland/commit/?id=886b09c9a3a9d8672039f09fe7eaf3f2b2b012ca ) On 26 May 2014 17:04, Marek Chalupa mchqwe...@gmail.com wrote: Test posting errors to one and

Re: Protocol (scanner) proposals

As discussed in IRC, nevermind this. I misread the header files. On 4 August 2014 01:12, Auke Booij a...@tulcod.com wrote: On 30 July 2014 20:27, Pekka Paalanen ppaala...@gmail.com wrote: Actually no. Binding writers are expected to write their own code generator for their language, like

[PATCH weston 2/2] window: Don't use the frame's geometry when fullscreen

When fullscreen, we don't actually update the frame's geometry, so we can't query it for there. --- clients/window.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/clients/window.c b/clients/window.c index 1700cf9..85e5de8 100644 --- a/clients/window.c +++

[PATCH weston 1/2] input: Send key-repeat

--- src/input.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/input.c b/src/input.c index 4aa8ca7..aaa2223 100644 --- a/src/input.c +++ b/src/input.c @@ -1721,6 +1721,9 @@ seat_get_keyboard(struct wl_client *client, struct wl_resource *resource,

Tiling window manager implementation questions

Hi, I'd like to bring up two open questions about the implementation of a tiling compositor. First, how should the initial size negotiation work between the compositor and a client? In swc/velox, I have been sending configure events to clients as soon as the wl_shell_surface/xdg_shell_surface

Re: Tiling window manager implementation questions

On Mon, Aug 4, 2014 at 8:16 PM, Michael Forney mfor...@mforney.org wrote: Hi, I'd like to bring up two open questions about the implementation of a tiling compositor. First, how should the initial size negotiation work between the compositor and a client? In swc/velox, I have been sending

Fwd: Tiling window manager implementation questions

On Mon, Aug 4, 2014 at 5:29 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: Second, how should the compositor deal with a window manager which wants to change the size and position of a window rapidly in succession (for example, the window is moved from one monitor to another, and then to

Re: Tiling window manager implementation questions

On Mon, Aug 4, 2014 at 8:36 PM, Michael Forney mfor...@mforney.org wrote: On Mon, Aug 4, 2014 at 5:29 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: Second, how should the compositor deal with a window manager which wants to change the size and position of a window rapidly in succession

Re: [PATCH weston 1/2] input: Send key-repeat

Both of these look good to me. I'll get around to pushing them soon. --Jason On Mon, Aug 4, 2014 at 10:43 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: --- src/input.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/input.c b/src/input.c index