Re: [PATCH libinput] touchpad: fix double/multitap timeouts

On 05/01/2015 03:23 PM, Peter Hutterer wrote: On 2/05/2015 04:21 , Bill Spitzak wrote: Are you saying the first event is delayed until it knows whether it is double-tap or not? That is not going to work, it will introduce a huge annoying latency to interaction. I suspect I am misunderstanding

Re: [PATCH libinput] touchpad: fix double/multitap timeouts

On 2/05/2015 04:21 , Bill Spitzak wrote: Are you saying the first event is delayed until it knows whether it is double-tap or not? That is not going to work, it will introduce a huge annoying latency to interaction. I suspect I am misunderstanding this and an event is sent, but want to make sure

[PATCH weston] tests: fix typo

Signed-off-by: Derek Foreman --- tests/devices-test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/devices-test.c b/tests/devices-test.c index c04d9c5..7278cff 100644 --- a/tests/devices-test.c +++ b/tests/devices-test.c @@ -296,7 +296,7 @@ TEST(get_device_after_destr

Delay in alpha release

We're scheduled for doing the next alpha release today, but I'm going to delay it until at least Wednesday next week (May 6th). Subsequent releases will proceed as originally planned. I'm at a conference all this week and unfortunately while I thought I'd be able to handle the packaging work betw

Re: [PATCH libinput v3 0/5] touchpad gestures support

Hey Hans :), On Wed, Apr 29, 2015 at 2:18 PM, Hans de Goede wrote: > Hi All, > > Here is v3 of my touchpad gestures support patch series. > > Changes since v2: > - For pinch gestures instead of reporting finger distance deltas report a > scale > value which is relative to the initial finger di

Re: [PATCH libinput] touchpad: fix double/multitap timeouts

Are you saying the first event is delayed until it knows whether it is double-tap or not? That is not going to work, it will introduce a huge annoying latency to interaction. I suspect I am misunderstanding this and an event is sent, but want to make sure. On 04/30/2015 09:46 PM, Peter Hutte

[PATCH weston] launcher-util: Force all weston_launcher_open()s to use O_CLOEXEC

Really, there's pretty much no time we'd ever want O_CLOEXEC unset, as it will likely result in leaking fds to processes that aren't interested in them or shouldn't have them. This also removes the (now unused) code from weston_logind_open() that could drop O_CLOEXEC. Signed-off-by: Derek Foreman

[PATCH weston] compositor-drm: Open drm device with CLOEXEC

Signed-off-by: Derek Foreman --- src/compositor-drm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/compositor-drm.c b/src/compositor-drm.c index 43197a8..6a2dbd9 100644 --- a/src/compositor-drm.c +++ b/src/compositor-drm.c @@ -1329,7 +1329,8 @@ init_drm(struct drm_com

Re: [PATCH weston 1/2] data-device: add a function to send the selection to a client

Hi, On 1 May 2015 at 10:59, Giulio Camuffo wrote: > This commit adds a new exported function, weston_seat_send_selection(), > which sends the current selection to a specified client. This is > useful e.g. to implement a clipboard manager as a special client. There is one behaviour change here, w

Re: [PATCH weston] touch: Make weston_touch_set_focus() take a touch instead of a seat

On 30 April 2015 at 22:45, Derek Foreman wrote: > The other set_focus() functions take the relevant type instead of a seat > already, so this is consistent. > > Signed-off-by: Derek Foreman R-b, pushed: ca79076..4c93c08 master -> master Cheers, Daniel ___

[PATCH weston 1/2] data-device: add a function to send the selection to a client

This commit adds a new exported function, weston_seat_send_selection(), which sends the current selection to a specified client. This is useful e.g. to implement a clipboard manager as a special client. --- src/compositor.h | 3 +++ src/data-device.c | 54

[PATCH weston 2/2] data-device: send the selection to all the wl_data_device resources of a client

As we do for the input interfaces such as wl_pointer, we must send the selection event to all the wl_data_device resources the client created for a specified seat. --- src/data-device.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/src/data-device.c b/src

Re: [PATCH libinput] touchpad: increase drag timeout

Hi, On 01-05-15 10:15, Peter Hutterer wrote: From: Velimir Lisec libinput supports lifting a finger during dragging and setting it back down again to continue the drag. Curently the drag timeout is set to DEFAULT_TAP_TIMEOUT. That is to short, when we're dragging the finger needs to have enoug

Re: [PATCH libinput] touchpad: fix double/multitap timeouts

Hi, On 01-05-15 06:46, Peter Hutterer wrote: The current doubletap timeout was incorrect, it gave the user only 180ms to touch, release, touch, release to recognise a doubletap. But it would also set a timeout on the second release, delaying the button events by 180ms. Instead, re-arm the timer

Re: [PATCH 2/2] touchpad: don't apply tap config until all fingers are up

Hi, On 01-05-15 04:48, Peter Hutterer wrote: On Thu, Apr 30, 2015 at 10:01:55AM +0200, Hans de Goede wrote: Hi, On 30-04-15 08:00, Peter Hutterer wrote: If tapping is enabled while at least one finger is down, we underrun tp->tap.tap_finger_count on touch release. Avoid this by only switching

Re: [PATCH 1/2] touchpad: when clearing the touchpad state, release fake touches too

Hi, On 01-05-15 04:48, Peter Hutterer wrote: On Thu, Apr 30, 2015 at 09:49:30AM +0200, Hans de Goede wrote: Hi, On 30-04-15 07:59, Peter Hutterer wrote: Causes an error message in the device_disable_release_tap_n_drag test. When the touchpad is suspended, all touches are ended in tp_clear_sta

[PATCH libinput] touchpad: increase drag timeout

From: Velimir Lisec libinput supports lifting a finger during dragging and setting it back down again to continue the drag. Curently the drag timeout is set to DEFAULT_TAP_TIMEOUT. That is to short, when we're dragging the finger needs to have enough time to move from one edge of the touchpad to