Re: Inter-client surface embedding

2014-02-17 Thread Pekka Paalanen
On Mon, 17 Feb 2014 22:59:11 + (GMT) Mark Thomas wrote: > On Mon, 17 Feb 2014, Pekka Paalanen wrote: > > > On Mon, 17 Feb 2014 00:04:19 + (GMT) > > Mark Thomas wrote: > > > >>- The subsurface has separate focus from the main window surface. For > >> the usual use cases of embedding

[PATCH libinput 1/2] Hook up libevdev as backend

2014-02-17 Thread Peter Hutterer
libevdev wraps the various peculiarities of the evdev kernel API into a type-safe API. It also buffers the device so checking for specific features at a later time is easier than re-issuing the ioctls. Plus, it gives us almost free support for SYN_DROPPED events (in the following patch). This patc

[PATCH libinput 2/2] Hook up event processing to libevdev

2014-02-17 Thread Peter Hutterer
This gives us the ability to handle SYN_DROPPED transparently to the caller. Signed-off-by: Peter Hutterer --- src/evdev.c | 90 +++-- 1 file changed, 58 insertions(+), 32 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index ba28fc6..

Re: [RFC v4] Fullscreen shell protocol

2014-02-17 Thread Jason Ekstrand
I just added an implementation of RFCv4 which can be found here: https://github.com/jekstrand/weston/tree/fullscreen-shell-RFCv4 Thanks, --Jason Ekstrand On Sat, Feb 15, 2014 at 1:12 AM, Pekka Paalanen wrote: > On Fri, 14 Feb 2014 11:11:33 -0600 > Jason Ekstrand wrote: > > > Hi Pekka! Thank

Re: [PATCH libinput] evdev: fix device_transform_ functions

2014-02-17 Thread Peter Hutterer
On Mon, Feb 17, 2014 at 01:42:52PM -0500, Benjamin Tissoires wrote: > X and Y are li_fixed_t, which is 24.8 fixed point real number. > li_fixed_t max is thus ~8388607. > > On a touchscreen with a range of 32767 values (like a 3M sensor), and > mapped on monitor with a resolution of 1920x1080, we c

Re: [PATCH] connection: Use wl_log to report errors

2014-02-17 Thread Jason Ekstrand
Yeah, I've wanted to do that for a while. Reviewed-By: Jason Ekstrand On Feb 17, 2014 6:04 PM, "Jasper St. Pierre" wrote: > In some cases, like Xwayland, stdout and stderr are redirected to > /dev/null, losing us valuable information, while wl_log can be > overridden, allowing us to send it to

Re: Inter-client surface embedding

2014-02-17 Thread Bill Spitzak
Mark Thomas wrote: I've pushed some doc updates to the protocol.xml file my git repo. But in terms of Jonas Ã…dahl's proposal, my protocol works the other way round: A creates a main surface A creates a "hole" on that surface and sets its position and size A gets the uid (handle) from the

[PATCH] connection: Use wl_log to report errors

2014-02-17 Thread Jasper St. Pierre
In some cases, like Xwayland, stdout and stderr are redirected to /dev/null, losing us valuable information, while wl_log can be overridden, allowing us to send it to a log file instead. This can help debugging immensely. --- src/connection.c | 36 ++-- 1 file chang

Re: Inter-client surface embedding

2014-02-17 Thread Jasper St. Pierre
GtkPlug and GtkSocket are really implemented in terms of XEmbed. As we've found, XEmbed has a surprising number of problems in real-world use cases, so it's considered deprecated. Building something special-case for panels seems much better than trying to implement something generic like WaylandEm

Re: Inter-client surface embedding

2014-02-17 Thread Mark Thomas
On Mon, 17 Feb 2014, Pekka Paalanen wrote: On Mon, 17 Feb 2014 00:04:19 + (GMT) Mark Thomas wrote: - The subsurface has separate focus from the main window surface. For the usual use cases of embedding like this, you'd prefer the parent surface to remain focused (or at least, appear f

[PATCH] wayland-client: Set a proper errno

2014-02-17 Thread Jasper St. Pierre
errno is supposed to be positive, not negative. It seems that everything else that calls display_fatal_error() calls it with a positive error code, so do it here as well. --- src/wayland-client.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/wayland-client.c b/src/w

[PATCH libinput] evdev: fix device_transform_ functions

2014-02-17 Thread Benjamin Tissoires
X and Y are li_fixed_t, which is 24.8 fixed point real number. li_fixed_t max is thus ~8388607. On a touchscreen with a range of 32767 values (like a 3M sensor), and mapped on monitor with a resolution of 1920x1080, we currently have: (x - li_fixed_from_int(device->abs.min_x)) * width == 62912640

Re: Core protocol change; [RFC v2] Wayland presentation extension

2014-02-17 Thread Jason Ekstrand
On Feb 17, 2014 2:35 AM, "Pekka Paalanen" wrote: > > Hi, > > there is one important thing in the below spec I really need to > highlight! See further below. > > > On Thu, 30 Jan 2014 17:35:17 +0200 > Pekka Paalanen wrote: > > > Hi, > > > > it's time for a take two on the Wayland presentation exte

Re: [RFC v2] Wayland presentation extension (video protocol)

2014-02-17 Thread Pekka Paalanen
On Mon, 17 Feb 2014 01:25:07 +0100 Mario Kleiner wrote: > Hello Pekka, > > i'm not yet subscribed to wayland-devel, and a bit short on time atm., > so i'll take a shortcut via direct e-mail for some quick feedback for > your Wayland presentation extension v2. Hi Mario, I'm very happy to hear

Core protocol change; [RFC v2] Wayland presentation extension

2014-02-17 Thread Pekka Paalanen
Hi, there is one important thing in the below spec I really need to highlight! See further below. On Thu, 30 Jan 2014 17:35:17 +0200 Pekka Paalanen wrote: > Hi, > > it's time for a take two on the Wayland presentation extension. > > > 1. Introduction > > The v1 proposal is he

Re: [RFC v2] Wayland presentation extension (video protocol)

2014-02-17 Thread Pekka Paalanen
On Mon, 17 Feb 2014 03:23:40 + "Zhang, Xiong Y" wrote: > On Thu, 2014-01-30 at 17:35 +0200, Pekka Paalanen wrote: > > Hi, > > > > it's time for a take two on the Wayland presentation extension. > > > > > > 1. Introduction > > > > The v1 proposal is here: > > http://lists.freed

Re: [PATCH weston 1/2] toytoolkit: avoid unnecessary redraws when focus changes

2014-02-17 Thread Emilio Pozuelo Monfort
On 12/02/14 15:55, Jasper St. Pierre wrote: > What reschedules the frame being drawn when focused is gained / lost, then? I'm not sure what reschedules it, but it does happen: twice when the window is focused, twice when it is unfocused (maybe something to optimize, why are we redrawing twice?).