Re: [PATCH libinput 1/6] filter: rename motion_filter_destroy to filter_destroy

Hi, On 07/08/2014 01:21 AM, Peter Hutterer wrote: > For better consistency with filter_dispatch(). And move the things around to > keep > the consumable API together. > > Signed-off-by: Peter Hutterer Looks good, you may add my Reviewed-by for patches 1-3. Regards, Hans > --- > src/evdev-

[PATCH libinput 5/5] touchpad: normalize the touchpad resolution to 400dpi, not 10 units/mm

In an attempt to bring method into the madness, normalize the touchpad deltas to those of a USB mouse with 400 dpi. This way the data we're dealing with in the acceleration code is of a known quantity. Signed-off-by: Peter Hutterer --- An extra comment on this: this changes the speed of the touch

[PATCH libinput 1/5] filter: annotate the various variables we have with units

Signed-off-by: Peter Hutterer --- src/filter.c | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/src/filter.c b/src/filter.c index 6fbd4d9..7db78ba 100644 --- a/src/filter.c +++ b/src/filter.c @@ -51,22 +51,22 @@ filter_destroy(struct m

[PATCH libinput 2/5] filter: use a separate variable for the final accel factor

velocity is in unit/ms, the threshold is in units/ms. Once we divide velocity/threshold, we're not in units/ms anymore but have a unitless factor. Use a separate variable to avoid confusion. Signed-off-by: Peter Hutterer --- src/filter.c | 9 + 1 file changed, 5 insertions(+), 4 deletion

[PATCH libinput 3/5] filter: drop constant acceleration

This just moves a decimal point around, at the expense of making the approach harder to understand. The only time the const acceleration matters is when applied to the velocity but it only matters in relation to the threshold which is a fixed number. Signed-off-by: Peter Hutterer --- src/filter.

[PATCH libinput 4/5] touchpad: don't feed 0/0 deltas into the accel filters

The resolution-based scaling may result in deltas of 0. The accel code doesn't handle 0 deltas too well. 0/0 deltas can't happen for EV_REL devices, so the code just isn't designed for it. Most notably, events with delta 0/0 have no direction. That messes up the history-based velocity calculation

[PATCH libinput 3/6] filter: drop delta-softening

I doubt this does what we think it does. It doesn't soften the delta changes, rather it introduces bumps in the smooth processing of the changes. abs(delta) below 1.0 is untouched, and abs(delta) beyond 3 or 4 isn't noticable much. But in the slow range around the 1/-1 mark there is a bump. For e

[PATCH libinput 4/6] accel_profile_smooth_simple: Cleanup

From: Hans de Goede Cleanup the code a bit, and make sure accel is at least 1.0 . Signed-off-by: Hans de Goede Reviewed-by: Peter Hutterer Signed-off-by: Peter Hutterer --- src/filter.c | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/src/filter.c b/

[PATCH libinput 5/6] accel_profile_smooth_simple: Fix jump in acceleration curve

From: Hans de Goede There was an error in the value passed to the second calc_penumbral_gradient call causing a jump in the acceleration curve. This commit fixes this. Signed-off-by: Hans de Goede Reviewed-by: Peter Hutterer Signed-off-by: Peter Hutterer --- src/filter.c | 4 +++- 1 file cha

[PATCH libinput 1/6] filter: rename motion_filter_destroy to filter_destroy

For better consistency with filter_dispatch(). And move the things around to keep the consumable API together. Signed-off-by: Peter Hutterer --- src/evdev-mt-touchpad.c | 2 +- src/evdev.c | 2 +- src/filter.c| 18 +- src/filter.h| 4 ++--

[PATCH libinput 2/6] test: fix expected delta from relative motion

We send two delta events. One may get eaten or softened by the accel code but our expectation should be that both may get through, so the length of the expected vector is √((2dx)² + (2dy)²). That is the maximum length we expect though for deltas ranged [-1, 1]. Deltas above the threshold would fai

[PATCH libinput 6/6] accel_profile_smooth_simple: Make 0.0-1.0 accel range depend on threshold

From: Hans de Goede Instead of always going from an accel of 0.0 to 1.0 between a velocity of 0.0 and 1.0, make the lead-in length of the curve depend on the threshold setting, using half of the threshold for the lead-in. Signed-off-by: Hans de Goede Reviewed-by: Peter Hutterer Signed-off-by:

Re: Sending keyboard events?

Yes, it's builtin to the compositor. On Mon, Jul 7, 2014 at 5:31 PM, Pouar wrote: > On 07/07/2014 03:49 PM, Jasper St. Pierre wrote: > > It is not possible to send keyboard events to arbitrary other windows or > clients. You have no knowledge that these clients or windows actually > exist, eve

Re: Sending keyboard events?

On 07/07/2014 03:49 PM, Jasper St. Pierre wrote: > It is not possible to send keyboard events to arbitrary other windows > or clients. You have no knowledge that these clients or windows > actually exist, even. > > > On Mon, Jul 7, 2014 at 4:44 PM, Pouar > wrote: > >

Re: Sending keyboard events?

It is not possible to send keyboard events to arbitrary other windows or clients. You have no knowledge that these clients or windows actually exist, even. On Mon, Jul 7, 2014 at 4:44 PM, Pouar wrote: > On 07/07/2014 03:33 PM, Pouar wrote: > > On X I have a program that maps joystick buttons t

Re: Sending keyboard events?

On 07/07/2014 03:33 PM, Pouar wrote: > On X I have a program that maps joystick buttons to keystrokes that > works by sending keystroke events using XTest. Considering that there > are virtual keyboards available for Wayland I assume there's a way to > accomplish the same thing for Wayland. I'd lik

Sending keyboard events?

On X I have a program that maps joystick buttons to keystrokes that works by sending keystroke events using XTest. Considering that there are virtual keyboards available for Wayland I assume there's a way to accomplish the same thing for Wayland. I'd like to know what that is so people can port the

Re: [PATCH 1/3] tests: add expect_protocol_error function

On Mon, Jul 07, 2014 at 05:47:41PM +0300, Pekka Paalanen wrote: > On Thu, 19 Jun 2014 02:37:40 + > "Bryce W. Harrington" wrote: > > > On Mon, May 26, 2014 at 04:58:05PM +0200, Marek Chalupa wrote: > > > This function checks if a particular protocol error came in wire. > > > It's usefull in th

Re: weston: xwayland-test failed without any log.

On Mon, 7 Jul 2014 13:22:03 +0800 Guangyu Zhang wrote: > The following is the content of my test-suite.log. > > = >weston 1.5.90: ./test-suite.log > = > > # TOTAL: 12 > # PASS: 10 > # SKIP: 1 > # XFAIL: 0 > # FAIL: 1

Re: [PATCH 2/3] tests: remove assert from frame_callback_wait()

On Mon, 26 May 2014 16:58:06 +0200 Marek Chalupa wrote: > This function did dispatching wrapped in assert so when an error came, > the test was aborted. Now, with expect_protocol_error, we need > this function to abort only when we are not calling expect_protocol_error > afterwards. So instead of

Re: [PATCH 1/3] tests: add expect_protocol_error function

On Thu, 19 Jun 2014 02:37:40 + "Bryce W. Harrington" wrote: > On Mon, May 26, 2014 at 04:58:05PM +0200, Marek Chalupa wrote: > > This function checks if a particular protocol error came in wire. > > It's usefull in the cases where we hitherto used FAIL_TEST. > > The problem with FAIL_TEST is

Re: [PATCH wayland v5] client: extend error handling

On Mon, 7 Jul 2014 17:28:11 +0300 Pekka Paalanen wrote: > From: Marek Chalupa > > When an error occurs, wl_display_get_error() does not > provide any way of getting know if it was a local error or if it was > an error event, respectively what object caused the error and what > the error was. >

[PATCH wayland v5] client: extend error handling

From: Marek Chalupa When an error occurs, wl_display_get_error() does not provide any way of getting know if it was a local error or if it was an error event, respectively what object caused the error and what the error was. This patch introduces a new function wl_display_get_protocol_error() wh

Re: [PATCH weston-ivi-shell v5 6/9] A reference implementation of UI client how to use ivi-hmi-controller.

On Tue, 20 May 2014 19:02:56 +0900 Nobuhiko Tanibata wrote: > 2014-04-25 20:55 に Pekka Paalanen さんは書きました: > > On Thu, 20 Mar 2014 16:00:57 +0900 > > Nobuhiko Tanibata wrote: > > > >> This is launched from hmi-controller by using hmi_client_start and > >> create a > >> pthread. > >> > >> The b

Re: [PATCH weston-ivi-shell v4 5/9] A reference implementation how to use weston-layout library.

On Tue, 20 May 2014 18:57:46 +0900 Nobuhiko Tanibata wrote: > 2014-04-25 20:38 に Pekka Paalanen さんは書きました: > > On Mon, 17 Mar 2014 15:28:22 +0900 > > Nobuhiko Tanibata wrote: > > > >> The library is used to manage layout of surfaces/layers. Layout change > >> is > >> triggered by ivi-hmi-contro

Re: [PATCH weston-ivi-shell v4 3/9] ivi-shell supports a type of shell for In-Vehicle Infotainment system.

On Tue, 20 May 2014 14:05:10 +0900 Nobuhiko Tanibata wrote: > Hi pq, > > I applied your comments except for several ones, > > >> +struct ivi_shell *shell = wl_resource_get_user_data(resource); > >> +struct ivi_shell_surface *ivisurf = NULL; > >> +struct weston_layout_surface *layout

Re: [PATCH weston-ivi-shell v5 2/9] The weston-layout library supports

On Tue, 20 May 2014 13:52:55 +0900 Nobuhiko Tanibata wrote: > Hi, > > I apply review comments as v5 except following comments. > > >> + > >> +struct link_layerPropertyNotification { > >> +layerPropertyNotificationFunc callback; > >> +void *userdata; > >> +struct wl_list link; > >> +