Re: wl_tablet draft v2

On Thu, Jul 17, 2014 at 11:48:03AM -0700, Bill Spitzak wrote: > On 07/13/2014 12:17 PM, Lyude wrote: > > > - proximity_out > > Sent whenever the tool leaves the proximity of the tablet or moves > > out of the client surface. When the tool goes out of proximity, > > button rel

Re: libinput returns multiple keyboards that do not generate events

On Thu, Jul 17, 2014 at 03:37:41PM +0200, Stefanos A. wrote: > 2014-07-17 14:57 GMT+02:00 Jasper St. Pierre : > > > I don't see a benefit for running directly on a Linux console. > > > > I don't have any examples of using udev on me at the moment, but Weston > > should have a few. > > > > Thanks

Re: libinput returns multiple keyboards that do not generate events

On Thu, Jul 17, 2014 at 02:43:59PM +0200, Stefanos A. wrote: > 2014-07-17 14:39 GMT+02:00 Jasper St. Pierre : > > > In that case, yes, the two keyboards should be on different seats. You can > > use udev to determine the different seats. > > > > Is there any documentation for this? Every sample I

Re: wl_tablet draft v2

On 07/17/2014 12:58 PM, Lyude wrote: On Thu, 2014-07-17 at 11:48 -0700, Bill Spitzak wrote: A button count could definitely be added. But for clarification, are you suggesting this somehow replace the frame event we have right now? What I am trying to fix is the need for all the code modules

[PATCH weston] xdg-shell: Make stable

We've gone through enough churn of xdg-shell that we're now feeling confident enough to commit to this much. Let's do it. The major version number is bumped to 2 because unfortunately we need to remove the use_unstable_version API. --- clients/simple-damage.c | 9 +-- clients/simple-egl.c

Re: wl_tablet draft v2

On Thu, 2014-07-17 at 11:48 -0700, Bill Spitzak wrote: > On 07/13/2014 12:17 PM, Lyude wrote: > > > - proximity_out > > Sent whenever the tool leaves the proximity of the tablet or moves > > out of the client surface. When the tool goes out of proximity, > > button release ev

Re: wl_tablet draft v2

On 07/13/2014 12:17 PM, Lyude wrote: - proximity_out Sent whenever the tool leaves the proximity of the tablet or moves out of the client surface. When the tool goes out of proximity, button release events are sent before the initial proximity_out

[PATCH weston] compositor: Use libwayland to find a good default display for us

--- src/compositor.c | 67 1 file changed, 38 insertions(+), 29 deletions(-) diff --git a/src/compositor.c b/src/compositor.c index 17fce8d..5eb8ac8 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -4153,7 +4153,7 @@ int main(int arg

[PATCH wayland 1/6] server: Clean up socket destruction

The code here is wrong, leaky, and inconsistent. We don't free, unlink or clean up things when we should in every error path. Centralize the data destruction so it's easier to keep track of and easier to bug fix. --- src/wayland-server.c | 49 - 1 f

[PATCH wayland 2/6] server: Create the socket FD after taking the lock

We're going to split out the lock-taking to another function so we can repetitively try locks. --- src/wayland-server.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/wayland-server.c b/src/wayland-server.c index 3e0fb25..d919eb2 100644 --- a/src/wayland-serve

[PATCH wayland 3/6] server: Split out code to initialize the socket address for a display name

We'll use this to autodetect a good socket to open on. --- src/wayland-server.c | 41 ++--- 1 file changed, 26 insertions(+), 15 deletions(-) diff --git a/src/wayland-server.c b/src/wayland-server.c index d919eb2..3350751 100644 --- a/src/wayland-server.c +++ b

[PATCH wayland 4/6] server: Make get_socket_lock operate directly on the socket's lock_fd

--- src/wayland-server.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/src/wayland-server.c b/src/wayland-server.c index 3350751..5c0e84f 100644 --- a/src/wayland-server.c +++ b/src/wayland-server.c @@ -1021,27 +1021,27 @@ socket_data(int fd, uint32_t

[PATCH wayland 6/6] server: Add a simple API to find a good default display

This allows compositors to easily select a good display to listen on. --- src/wayland-server.c | 97 ++-- src/wayland-server.h | 1 + 2 files changed, 73 insertions(+), 25 deletions(-) diff --git a/src/wayland-server.c b/src/wayland-server.c index

[PATCH wayland 5/6] server: Save the display name in the wl_socket

This allows us to return the display name to the client in a new API. --- src/wayland-server.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/wayland-server.c b/src/wayland-server.c index 5c0e84f..55b3e25 100644 --- a/src/wayland-server.c +++ b/src/wayland-server.c @@ -63,6 +63,7 @@ st

[PATCH wayland 0/6] Introduce API to automatically find a good default display

This patch series introduces a new API to find an open Wayland display so that compositors don't need to reimplement all this code. This way, the code searching for an appropriate socket can be shared between all compositors. Jasper St. Pierre (6): server: Clean up socket destruction server: C

Re: Threading in Wayland

On 25/06/2014 15:04, Marek Chalupa wrote: Hi, I was recently discovering/playing with threading in Wayland. Here are some notes and questions I gathered: * display_thread variable in struct wl_display (wayland-client.c) is not used anywhere * pthread_cont_t cond in wl_event_queue is broadcas

[PATCH] client: drop unused event queue cond and list variables

The wl_event_queue cond variable has been replaced by the wl_display reader_cond variable (commit 3c7e8bfbb4745315b7bcbf69fa746c3d6718c305). This cond variable is never waited for anymore, just signaled/broadcasted, and thus can be safely removed. The wl_display event_queue_list can be removed as

Re: libinput returns multiple keyboards that do not generate events

2014-07-17 14:57 GMT+02:00 Jasper St. Pierre : > I don't see a benefit for running directly on a Linux console. > > I don't have any examples of using udev on me at the moment, but Weston > should have a few. > Thanks for your help so far. The benefit applies to applications running on limited h

Re: libinput returns multiple keyboards that do not generate events

I don't see a benefit for running directly on a Linux console. I don't have any examples of using udev on me at the moment, but Weston should have a few. On Thu, Jul 17, 2014 at 8:43 AM, Stefanos A. wrote: > 2014-07-17 14:39 GMT+02:00 Jasper St. Pierre : > > In that case, yes, the two keyboard

Re: libinput returns multiple keyboards that do not generate events

2014-07-17 14:39 GMT+02:00 Jasper St. Pierre : > In that case, yes, the two keyboards should be on different seats. You can > use udev to determine the different seats. > Is there any documentation for this? Every sample I have been able to find so far creates a single seat. > > Are you sure yo

Re: libinput returns multiple keyboards that do not generate events

In that case, yes, the two keyboards should be on different seats. You can use udev to determine the different seats. Are you sure you don't want to use Wayland or another protocol where the compositor will already do all this logic for you? On Thu, Jul 17, 2014 at 8:38 AM, Stefanos A. wrote:

Re: libinput returns multiple keyboards that do not generate events

2014-07-17 14:20 GMT+02:00 Jasper St. Pierre : > Why do you need to know which one is the "real" keyboard? Just listen to > events from all of them. On my laptop, I also have six keyboards. They are: > > Power Button > Video Bus > Sleep Button > Integrated Camera > AT Translat

Re: libinput returns multiple keyboards that do not generate events

Why do you need to know which one is the "real" keyboard? Just listen to events from all of them. On my laptop, I also have six keyboards. They are: Power Button Video Bus Sleep Button Integrated Camera AT Translated Set 2 keyboard (this is the actual "keyboard" keyboard) T

libinput returns multiple keyboards that do not generate events

I have come across a strange issue while implementing a libinput backend for OpenTK . When testing on my laptop, libinput detects six keyboard devices. Out of these, only the last one actually sends keyboard events - the rest remain idle no matter which button I pr

Re: [PATCH libinput 1/7] test: drop sideways-component in two-finger scroll test

Hi, On 07/16/2014 07:18 AM, Peter Hutterer wrote: > This breaks when we have a device resolution set on the test devices, > specificially on the T440. The current tests use a delta of 1% of the device > which with the resulution set results in an effective delta of 3 - above the > scroll threshold