Re: [PATCH libinput 2/2] tablet: Add TABLET_FRAME event

2014-07-15 Thread Peter Hutterer 
On Sun, Jul 13, 2014 at 07:19:29PM -0400, Stephen Chandler Paul wrote:
> This event is used to signify the end of a sequence of events from the tablet.
> This is required since the wayland protocol for tablets also has a frame 
> event,
> and it's impossible to tell where an event frame ends if libinput doesn't tell
> us.

hmm, I don't agree with this. libinput handles SYN_REPORT events, which are
the equivalent to the proposed frame event in wayland. we don't pass events
to the caller until we have the SYN_REPORT, and we have a bitmask telling
the caller what axes have changed, so any axis event can be split up for
wayland into the required sub-events followed by a frame.

The only exception here are button events, but they should be treated
separately anyway I think.

Cheers,
   Peter
 

> Signed-off-by: Stephen Chandler Paul 
> ---
>  src/evdev-tablet.c | 12 +++-
>  src/evdev-tablet.h |  3 ++-
>  src/libinput-private.h |  7 +++
>  src/libinput.c | 28 
>  src/libinput.h |  7 ++-
>  tools/event-debug.c| 15 +++
>  tools/event-gui.c  |  1 +
>  7 files changed, 70 insertions(+), 3 deletions(-)
> 
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index d1ad4bb..09b4b6b 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -164,12 +164,14 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
>  
>   if (axis_update_needed &&
>   !tablet_has_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY) &&
> - !tablet_has_status(tablet, TABLET_TOOL_LEAVING_PROXIMITY))
> + !tablet_has_status(tablet, TABLET_TOOL_LEAVING_PROXIMITY)) {
>   tablet_notify_axis(base,
>  time,
>  tool,
>  tablet->changed_axes,
>  tablet->axes);
> + tablet_set_status(tablet, TABLET_FRAME_NEEDED);
> + }
>  
>   memset(tablet->changed_axes, 0, sizeof(tablet->changed_axes));
>  }
> @@ -391,12 +393,14 @@ tablet_flush(struct tablet_dispatch *tablet,
>   /* Release all stylus buttons */
>   tablet->button_state.stylus_buttons = 0;
>   tablet_set_status(tablet, TABLET_BUTTONS_RELEASED);
> + tablet_set_status(tablet, TABLET_FRAME_NEEDED);
>   } else if (tablet_has_status(tablet, TABLET_TOOL_ENTERING_PROXIMITY)) {
>   tablet_notify_proximity_in(&device->base,
>  time,
>  tool,
>  tablet->axes);
>   tablet_unset_status(tablet, TABLET_TOOL_ENTERING_PROXIMITY);
> + tablet_set_status(tablet, TABLET_FRAME_NEEDED);
>   }
>  
>   if (tablet_has_status(tablet, TABLET_AXES_UPDATED)) {
> @@ -412,6 +416,7 @@ tablet_flush(struct tablet_dispatch *tablet,
> tool,
> LIBINPUT_BUTTON_STATE_RELEASED);
>   tablet_unset_status(tablet, TABLET_BUTTONS_RELEASED);
> + tablet_set_status(tablet, TABLET_FRAME_NEEDED);
>   }
>  
>   if (tablet_has_status(tablet, TABLET_BUTTONS_PRESSED)) {
> @@ -421,6 +426,7 @@ tablet_flush(struct tablet_dispatch *tablet,
> tool,
> LIBINPUT_BUTTON_STATE_PRESSED);
>   tablet_unset_status(tablet, TABLET_BUTTONS_PRESSED);
> + tablet_set_status(tablet, TABLET_FRAME_NEEDED);
>   }
>  
>   if (tablet_has_status(tablet, TABLET_TOOL_LEAVING_PROXIMITY)) {
> @@ -431,6 +437,10 @@ tablet_flush(struct tablet_dispatch *tablet,
>   tablet_set_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY);
>   tablet_unset_status(tablet, TABLET_TOOL_LEAVING_PROXIMITY);
>   }
> + if (tablet_has_status(tablet, TABLET_FRAME_NEEDED)) {
> + tablet_notify_frame(&device->base, time, tool, tablet->axes);
> + tablet_unset_status(tablet, TABLET_FRAME_NEEDED);
> + }
>  
>   /* Update state */
>   memcpy(&tablet->prev_button_state,
> diff --git a/src/evdev-tablet.h b/src/evdev-tablet.h
> index 1b53d20..e5c8654 100644
> --- a/src/evdev-tablet.h
> +++ b/src/evdev-tablet.h
> @@ -35,7 +35,8 @@ enum tablet_status {
>   TABLET_STYLUS_IN_CONTACT = 1 << 3,
>   TABLET_TOOL_LEAVING_PROXIMITY = 1 << 4,
>   TABLET_TOOL_OUT_OF_PROXIMITY = 1 << 5,
> - TABLET_TOOL_ENTERING_PROXIMITY = 1 << 6
> + TABLET_TOOL_ENTERING_PROXIMITY = 1 << 6,
> + TABLET_FRAME_NEEDED = 1 << 7
>  };
>  
>  struct button_state {
> diff --git a/src/libinput-private.h b/src/libinput-private.h
> index dbdf5e6..f348dd8 100644
> --- a/src/libinput-private.h
> +++ b/src/libinput-private.h
> @@ -237,6 +237,13 @@ tablet_notify_button(struct libinput_device *device,
>double *axes,
>int32_t button,
>

[PATCH libinput 2/7] test: set the abs resolution after creating the device

2014-07-15 Thread Peter Hutterer 
Until uinput gets that capability (likely not before 3.17) all we can do is a
racy approach of setting it after creating it. That won't work well for
anything test where libinput is already listening to udev when the device is
created, but it does work for those cases where libinput is started after the
device was initialized.

And it's a better alternative than not testing anything dependent on
resolution settings.

Signed-off-by: Peter Hutterer 
---
 test/litest.c | 32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/test/litest.c b/test/litest.c
index adcbf3e..f32f346 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -808,13 +808,14 @@ litest_assert_empty_queue(struct libinput *li)
 struct libevdev_uinput *
 litest_create_uinput_device_from_description(const char *name,
 const struct input_id *id,
-const struct input_absinfo *abs,
+const struct input_absinfo 
*abs_info,
 const int *events)
 {
struct libevdev_uinput *uinput;
struct libevdev *dev;
int type, code;
-   int rc;
+   int rc, fd;
+   const struct input_absinfo *abs;
const struct input_absinfo default_abs = {
.value = 0,
.minimum = 0,
@@ -824,6 +825,7 @@ litest_create_uinput_device_from_description(const char 
*name,
.resolution = 100
};
char buf[512];
+   const char *devnode;
 
dev = libevdev_new();
ck_assert(dev != NULL);
@@ -836,6 +838,7 @@ litest_create_uinput_device_from_description(const char 
*name,
libevdev_set_id_product(dev, id->product);
}
 
+   abs = abs_info;
while (abs && abs->value != -1) {
rc = libevdev_enable_event_code(dev, EV_ABS,
abs->value, abs);
@@ -864,6 +867,31 @@ litest_create_uinput_device_from_description(const char 
*name,
 
libevdev_free(dev);
 
+   /* uinput does not yet support setting the resolution, so we set it
+* afterwards. This is of course racy as hell but the way we
+* _generally_ use this function by the time libinput uses the
+* device, we're finished here */
+
+   devnode = libevdev_uinput_get_devnode(uinput);
+   ck_assert_notnull(devnode);
+   fd = open(devnode, O_RDONLY);
+   ck_assert_int_gt(fd, -1);
+   rc = libevdev_new_from_fd(fd, &dev);
+   ck_assert_int_eq(rc, 0);
+
+   abs = abs_info;
+   while (abs && abs->value != -1) {
+   if (abs->resolution != 0) {
+   rc = libevdev_kernel_set_abs_info(dev,
+ abs->value,
+ abs);
+   ck_assert_int_eq(rc, 0);
+   }
+   abs++;
+   }
+   close(fd);
+   libevdev_free(dev);
+
return uinput;
 }
 
-- 
1.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 3/7] filter: move get_direction into shared header

2014-07-15 Thread Peter Hutterer 
Makes it possible to use from the touchpad code.

Signed-off-by: Peter Hutterer 
---
 src/filter.c| 60 ++---
 src/libinput-util.h | 58 +++
 2 files changed, 60 insertions(+), 58 deletions(-)

diff --git a/src/filter.c b/src/filter.c
index e1fb2a9..d65adfb 100644
--- a/src/filter.c
+++ b/src/filter.c
@@ -29,6 +29,7 @@
 #include 
 
 #include "filter.h"
+#include "libinput-util.h"
 
 void
 filter_dispatch(struct motion_filter *filter,
@@ -84,63 +85,6 @@ struct pointer_accelerator {
int cur_tracker;
 };
 
-enum directions {
-   N  = 1 << 0,
-   NE = 1 << 1,
-   E  = 1 << 2,
-   SE = 1 << 3,
-   S  = 1 << 4,
-   SW = 1 << 5,
-   W  = 1 << 6,
-   NW = 1 << 7,
-   UNDEFINED_DIRECTION = 0xff
-};
-
-static int
-get_direction(int dx, int dy)
-{
-   int dir = UNDEFINED_DIRECTION;
-   int d1, d2;
-   double r;
-
-   if (abs(dx) < 2 && abs(dy) < 2) {
-   if (dx > 0 && dy > 0)
-   dir = S | SE | E;
-   else if (dx > 0 && dy < 0)
-   dir = N | NE | E;
-   else if (dx < 0 && dy > 0)
-   dir = S | SW | W;
-   else if (dx < 0 && dy < 0)
-   dir = N | NW | W;
-   else if (dx > 0)
-   dir = NE | E | SE;
-   else if (dx < 0)
-   dir = NW | W | SW;
-   else if (dy > 0)
-   dir = SE | S | SW;
-   else if (dy < 0)
-   dir = NE | N | NW;
-   } else {
-   /* Calculate r within the interval  [0 to 8)
-*
-* r = [0 .. 2π] where 0 is North
-* d_f = r / 2π  ([0 .. 1))
-* d_8 = 8 * d_f
-*/
-   r = atan2(dy, dx);
-   r = fmod(r + 2.5*M_PI, 2*M_PI);
-   r *= 4*M_1_PI;
-
-   /* Mark one or two close enough octants */
-   d1 = (int)(r + 0.9) % 8;
-   d2 = (int)(r + 0.1) % 8;
-
-   dir = (1 << d1) | (1 << d2);
-   }
-
-   return dir;
-}
-
 static void
 feed_trackers(struct pointer_accelerator *accel,
  double dx, double dy,
@@ -160,7 +104,7 @@ feed_trackers(struct pointer_accelerator *accel,
trackers[current].dx = 0.0;
trackers[current].dy = 0.0;
trackers[current].time = time;
-   trackers[current].dir = get_direction(dx, dy);
+   trackers[current].dir = vector_get_direction(dx, dy);
 }
 
 static struct pointer_tracker *
diff --git a/src/libinput-util.h b/src/libinput-util.h
index 2558a3d..c0235ef 100644
--- a/src/libinput-util.h
+++ b/src/libinput-util.h
@@ -24,6 +24,7 @@
 #define LIBINPUT_UTIL_H
 
 #include 
+#include 
 
 #include "libinput.h"
 
@@ -92,4 +93,61 @@ msleep(unsigned int ms)
usleep(ms * 1000);
 }
 
+enum directions {
+   N  = 1 << 0,
+   NE = 1 << 1,
+   E  = 1 << 2,
+   SE = 1 << 3,
+   S  = 1 << 4,
+   SW = 1 << 5,
+   W  = 1 << 6,
+   NW = 1 << 7,
+   UNDEFINED_DIRECTION = 0xff
+};
+
+static inline int
+vector_get_direction(int dx, int dy)
+{
+   int dir = UNDEFINED_DIRECTION;
+   int d1, d2;
+   double r;
+
+   if (abs(dx) < 2 && abs(dy) < 2) {
+   if (dx > 0 && dy > 0)
+   dir = S | SE | E;
+   else if (dx > 0 && dy < 0)
+   dir = N | NE | E;
+   else if (dx < 0 && dy > 0)
+   dir = S | SW | W;
+   else if (dx < 0 && dy < 0)
+   dir = N | NW | W;
+   else if (dx > 0)
+   dir = NE | E | SE;
+   else if (dx < 0)
+   dir = NW | W | SW;
+   else if (dy > 0)
+   dir = SE | S | SW;
+   else if (dy < 0)
+   dir = NE | N | NW;
+   } else {
+   /* Calculate r within the interval  [0 to 8)
+*
+* r = [0 .. 2π] where 0 is North
+* d_f = r / 2π  ([0 .. 1))
+* d_8 = 8 * d_f
+*/
+   r = atan2(dy, dx);
+   r = fmod(r + 2.5*M_PI, 2*M_PI);
+   r *= 4*M_1_PI;
+
+   /* Mark one or two close enough octants */
+   d1 = (int)(r + 0.9) % 8;
+   d2 = (int)(r + 0.1) % 8;
+
+   dir = (1 << d1) | (1 << d2);
+   }
+
+   return dir;
+}
+
 #endif /* LIBINPUT_UTIL_H */
-- 
1.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 libinput 4/7] touchpad: implement edge-based basic palm detection

2014-07-15 Thread Peter Hutterer 
A large part of palm events are situated on the far edges of the touchpad. In
a test run on a T440s while typing a long email all but 2 touch points were
located in the outer ~5% of the touchpad. Define a 5% exclusion zone on the
left and right edges in which new touchpoint is automatically assigned to be a
palm.

A finger may move into that exclusion zone without being marked as palm, it
just can't start in one.

On clickpads, the exclusion zone does not extend into the software buttons.

Signed-off-by: Peter Hutterer 
---
Changes to v1:
- drop to 5%

 src/evdev-mt-touchpad-buttons.c |   6 +++
 src/evdev-mt-touchpad.c |  47 
 src/evdev-mt-touchpad.h |   9 
 test/touchpad.c | 117 
 4 files changed, 179 insertions(+)

diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index 520a47f..bd3c0e2 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -733,3 +733,9 @@ tp_button_touch_active(struct tp_dispatch *tp, struct 
tp_touch *t)
 {
return t->button.state == BUTTON_STATE_AREA;
 }
+
+bool
+tp_button_is_inside_softbutton_area(struct tp_dispatch *tp, struct tp_touch *t)
+{
+   return is_inside_top_button_area(tp, t) || 
is_inside_bottom_button_area(tp, t);
+}
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index c7fd3a1..1325355 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -148,6 +148,7 @@ tp_end_touch(struct tp_dispatch *tp, struct tp_touch *t)
 
t->dirty = true;
t->is_pointer = false;
+   t->is_palm = false;
t->state = TOUCH_END;
t->pinned.is_pinned = false;
assert(tp->nfingers_down >= 1);
@@ -339,6 +340,7 @@ static int
 tp_touch_active(struct tp_dispatch *tp, struct tp_touch *t)
 {
return (t->state == TOUCH_BEGIN || t->state == TOUCH_UPDATE) &&
+   !t->is_palm &&
!t->pinned.is_pinned && tp_button_touch_active(tp, t);
 }
 
@@ -358,6 +360,29 @@ tp_set_pointer(struct tp_dispatch *tp, struct tp_touch *t)
 }
 
 static void
+tp_palm_detect(struct tp_dispatch *tp, struct tp_touch *t)
+{
+   /* once a palm, always a palm */
+   if (t->is_palm)
+   return;
+
+   /* palm must start in exclusion zone, it's ok to move into
+  the zone without being a palm */
+   if (t->state != TOUCH_BEGIN ||
+   (t->x > tp->palm.left_edge && t->x < tp->palm.right_edge))
+   return;
+
+   /* don't detect palm in software button areas, it's
+  likely that legitimate touches start in the area
+  covered by the exclusion zone */
+   if (tp->buttons.is_clickpad &&
+   tp_button_is_inside_softbutton_area(tp, t))
+   return;
+
+   t->is_palm = true;
+}
+
+static void
 tp_process_state(struct tp_dispatch *tp, uint64_t time)
 {
struct tp_touch *t;
@@ -373,6 +398,8 @@ tp_process_state(struct tp_dispatch *tp, uint64_t time)
continue;
}
 
+   tp_palm_detect(tp, t);
+
tp_motion_hysteresis(tp, t);
tp_motion_history_push(t);
 
@@ -703,6 +730,23 @@ tp_init_scroll(struct tp_dispatch *tp)
 }
 
 static int
+tp_init_palmdetect(struct tp_dispatch *tp,
+  struct evdev_device *device)
+{
+   int width;
+
+   width = abs(device->abs.absinfo_x->maximum -
+   device->abs.absinfo_x->minimum);
+
+   /* palm edges are 5% of the width on each side */
+   tp->palm.right_edge = device->abs.absinfo_x->maximum - width * 0.05;
+   tp->palm.left_edge = device->abs.absinfo_x->minimum + width * 0.05;
+
+   return 0;
+}
+
+
+static int
 tp_init(struct tp_dispatch *tp,
struct evdev_device *device)
 {
@@ -738,6 +782,9 @@ tp_init(struct tp_dispatch *tp,
if (tp_init_buttons(tp, device) != 0)
return -1;
 
+   if (tp_init_palmdetect(tp, device) != 0)
+   return -1;
+
return 0;
 }
 
diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
index 80f3f60..689687e 100644
--- a/src/evdev-mt-touchpad.h
+++ b/src/evdev-mt-touchpad.h
@@ -103,6 +103,7 @@ struct tp_touch {
bool dirty;
bool fake;  /* a fake touch */
bool is_pointer;/* the pointer-controlling 
touch */
+   bool is_palm;
int32_t x;
int32_t y;
uint64_t millis;
@@ -202,6 +203,11 @@ struct tp_dispatch {
struct libinput_timer timer;
enum tp_tap_state state;
} tap;
+
+   struct {
+   int32_t right_edge;
+   int32_t left_edge;
+   } palm;
 };
 
 #define tp_for_each_touch(_tp, _t) \
@@ -242,4 +248,7 @@ tp_button_handle_state(struct tp_dispatch *tp, uint64_t 
time);
 int
 tp_button_touch_active(struct tp_dispatch *tp, struct tp_touch *t);
 
+bool
+tp_button_is_inside_softbutto

[PATCH libinput 7/7] touchpad: don't init edge palm detection on touchpads less than 8cm across

2014-07-15 Thread Peter Hutterer 
On small touchpads, a touch that intends to go across the width of the
touchpad is likely to start in the edge zone. Likewise, on those touchpads the
chances of a palm event happening on the edge is small.

A minimum width of 8cm determined by an elaborate process of completely
unscientific guesswork: the x220 is roughly 7.5cm across and doesn't suffer
much from edge events, the T440s is 10cm across and definitely suffers from
it. So the trigger width likely somewhere in between which makes 8cm about as
valid as any other guess.

Note that this disables palm detection for resolution-less touchpads too - if
we don't know how big the touchpad is we can't know if palm detection on the
edges is necessary.

Signed-off-by: Peter Hutterer 
---
 src/evdev-mt-touchpad.c | 13 +
 test/touchpad.c | 28 
 2 files changed, 41 insertions(+)

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 2cf8b56..1636e7a 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "evdev-mt-touchpad.h"
 
@@ -753,9 +754,21 @@ tp_init_palmdetect(struct tp_dispatch *tp,
 {
int width;
 
+   /* We don't know how big the touchpad is */
+   if (device->abs.absinfo_x->resolution == 1)
+   return 0;
+
width = abs(device->abs.absinfo_x->maximum -
device->abs.absinfo_x->minimum);
 
+   /* Enable palm detection on touchpads >= 80 mm. Anything smaller
+  probably won't need it, until we find out it does */
+   if (width/device->abs.absinfo_x->resolution < 80) {
+   tp->palm.right_edge = INT_MAX;
+   tp->palm.left_edge = INT_MIN;
+   return 0;
+   }
+
/* palm edges are 5% of the width on each side */
tp->palm.right_edge = device->abs.absinfo_x->maximum - width * 0.05;
tp->palm.left_edge = device->abs.absinfo_x->minimum + width * 0.05;
diff --git a/test/touchpad.c b/test/touchpad.c
index 259b227..bc3658c 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -1241,11 +1241,24 @@ START_TEST(touchpad_tap_default)
 }
 END_TEST
 
+static int
+touchpad_has_palm_detect_size(struct litest_device *dev)
+{
+   double width, height;
+
+   libinput_device_get_size(dev->libinput_device, &width, &height);
+
+   return width >= 80;
+}
+
 START_TEST(touchpad_palm_detect_at_edge)
 {
struct litest_device *dev = litest_current_device();
struct libinput *li = dev->libinput;
 
+   if (!touchpad_has_palm_detect_size(dev))
+   return;
+
litest_drain_events(li);
 
litest_touch_down(dev, 0, 99, 50);
@@ -1265,6 +1278,9 @@ START_TEST(touchpad_palm_detect_at_bottom_corners)
struct litest_device *dev = litest_current_device();
struct libinput *li = dev->libinput;
 
+   if (!touchpad_has_palm_detect_size(dev))
+   return;
+
/* Run for non-clickpads only: make sure the bottom corners trigger
   palm detection too */
litest_drain_events(li);
@@ -1286,6 +1302,9 @@ START_TEST(touchpad_palm_detect_at_top_corners)
struct litest_device *dev = litest_current_device();
struct libinput *li = dev->libinput;
 
+   if (!touchpad_has_palm_detect_size(dev))
+   return;
+
/* Run for non-clickpads only: make sure the bottom corners trigger
   palm detection too */
litest_drain_events(li);
@@ -1307,6 +1326,9 @@ START_TEST(touchpad_palm_detect_palm_stays_palm)
struct litest_device *dev = litest_current_device();
struct libinput *li = dev->libinput;
 
+   if (!touchpad_has_palm_detect_size(dev))
+   return;
+
litest_drain_events(li);
 
litest_touch_down(dev, 0, 99, 20);
@@ -1323,6 +1345,9 @@ START_TEST(touchpad_palm_detect_palm_becomes_pointer)
struct libinput_event *ev;
enum libinput_event_type type;
 
+   if (!touchpad_has_palm_detect_size(dev))
+   return;
+
litest_drain_events(li);
 
litest_touch_down(dev, 0, 99, 50);
@@ -1352,6 +1377,9 @@ START_TEST(touchpad_palm_detect_no_palm_moving_into_edges)
struct libinput_event *ev;
enum libinput_event_type type;
 
+   if (!touchpad_has_palm_detect_size(dev))
+   return;
+
/* moving non-palm into the edge does not label it as palm */
litest_drain_events(li);
 
-- 
1.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 5/7] touchpad: if a palm touch moves out of the edge zone within a timeout, unpalm

2014-07-15 Thread Peter Hutterer 
On small touchpads a touch that is intended to traverse much of the screen
width may start at the very edge, i.e. in the palm zone.
In that case, and if the touch moves out of the palm zone quickly enough, drop
the palm label and make it a normal touchpoint.

Signed-off-by: Peter Hutterer 
---
200 ms picked by classic trial and error. I thought at first 50ms would be
enough and it definitely isn't. 200 ms seems to be good enough here

 src/evdev-mt-touchpad.c | 25 ++---
 src/evdev-mt-touchpad.h |  6 +-
 test/touchpad.c | 20 +---
 3 files changed, 40 insertions(+), 11 deletions(-)

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 1325355..830e9fe 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -148,7 +148,7 @@ tp_end_touch(struct tp_dispatch *tp, struct tp_touch *t)
 
t->dirty = true;
t->is_pointer = false;
-   t->is_palm = false;
+   t->palm.is_palm = false;
t->state = TOUCH_END;
t->pinned.is_pinned = false;
assert(tp->nfingers_down >= 1);
@@ -340,7 +340,7 @@ static int
 tp_touch_active(struct tp_dispatch *tp, struct tp_touch *t)
 {
return (t->state == TOUCH_BEGIN || t->state == TOUCH_UPDATE) &&
-   !t->is_palm &&
+   !t->palm.is_palm &&
!t->pinned.is_pinned && tp_button_touch_active(tp, t);
 }
 
@@ -360,11 +360,21 @@ tp_set_pointer(struct tp_dispatch *tp, struct tp_touch *t)
 }
 
 static void
-tp_palm_detect(struct tp_dispatch *tp, struct tp_touch *t)
+tp_palm_detect(struct tp_dispatch *tp, struct tp_touch *t, uint64_t time)
 {
-   /* once a palm, always a palm */
-   if (t->is_palm)
+   const int PALM_TIMEOUT = 200; /* ms */
+
+   /* If labelled a touch as palm, we unlabel as palm when
+  we move out of the palm edge zone within the timeout.
+*/
+   if (t->palm.is_palm) {
+   if (time < t->palm.time + PALM_TIMEOUT &&
+   (t->x > tp->palm.left_edge && t->x < tp->palm.right_edge)) {
+   t->palm.is_palm = false;
+   tp_set_pointer(tp, t);
+   }
return;
+   }
 
/* palm must start in exclusion zone, it's ok to move into
   the zone without being a palm */
@@ -379,7 +389,8 @@ tp_palm_detect(struct tp_dispatch *tp, struct tp_touch *t)
tp_button_is_inside_softbutton_area(tp, t))
return;
 
-   t->is_palm = true;
+   t->palm.is_palm = true;
+   t->palm.time = time;
 }
 
 static void
@@ -398,7 +409,7 @@ tp_process_state(struct tp_dispatch *tp, uint64_t time)
continue;
}
 
-   tp_palm_detect(tp, t);
+   tp_palm_detect(tp, t, time);
 
tp_motion_hysteresis(tp, t);
tp_motion_history_push(t);
diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
index 689687e..8255a1c 100644
--- a/src/evdev-mt-touchpad.h
+++ b/src/evdev-mt-touchpad.h
@@ -103,7 +103,6 @@ struct tp_touch {
bool dirty;
bool fake;  /* a fake touch */
bool is_pointer;/* the pointer-controlling 
touch */
-   bool is_palm;
int32_t x;
int32_t y;
uint64_t millis;
@@ -140,6 +139,11 @@ struct tp_touch {
struct {
enum tp_tap_touch_state state;
} tap;
+
+   struct {
+   bool is_palm;
+   uint32_t time; /* first timestamp if is_palm == true */
+   } palm;
 };
 
 struct tp_dispatch {
diff --git a/test/touchpad.c b/test/touchpad.c
index 317dcba..5bb8d9b 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -1302,17 +1302,31 @@ START_TEST(touchpad_palm_detect_at_top_corners)
 }
 END_TEST
 
-START_TEST(touchpad_palm_detect_palm_stays_palm)
+START_TEST(touchpad_palm_detect_palm_becomes_pointer)
 {
struct litest_device *dev = litest_current_device();
struct libinput *li = dev->libinput;
+   struct libinput_event *ev;
+   enum libinput_event_type type;
 
litest_drain_events(li);
 
litest_touch_down(dev, 0, 99, 50);
-   litest_touch_move_to(dev, 0, 99, 50, 0, 70, 5);
+   litest_touch_move_to(dev, 0, 99, 70, 0, 70, 5);
litest_touch_up(dev, 0);
 
+   libinput_dispatch(li);
+
+   ev = libinput_get_event(li);
+   ck_assert_notnull(ev);
+   do {
+   type = libinput_event_get_type(ev);
+   ck_assert_int_eq(type, LIBINPUT_EVENT_POINTER_MOTION);
+
+   libinput_event_destroy(ev);
+   ev = libinput_get_event(li);
+   } while (ev);
+
litest_assert_empty_queue(li);
 }
 END_TEST
@@ -1404,7 +1418,7 @@ int main(int argc, char **argv) {
litest_add("touchpad:palm", touchpad_palm_detect_at_edge, 
LITEST_TOUCHPAD, LITEST_ANY);
litest_add("touchpad:palm", touchpad_palm_detect_at_bottom_corners, 
LITEST_TOUCHPAD

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

2014-07-15 Thread Peter Hutterer 
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.

Signed-off-by: Peter Hutterer 
---
Doesn't break until 2/7 is applied.

 test/touchpad.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/test/touchpad.c b/test/touchpad.c
index b7b31d6..a8e0d89 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -1198,15 +1198,13 @@ START_TEST(touchpad_2fg_scroll)
 
litest_drain_events(li);
 
-   /* Note this mixes in a tiny amount of movement in the wrong direction,
-  which should be ignored */
-   test_2fg_scroll(dev, 1, 40, 0);
+   test_2fg_scroll(dev, 0, 40, 0);
check_2fg_scroll(dev, LIBINPUT_POINTER_AXIS_SCROLL_VERTICAL, 10);
-   test_2fg_scroll(dev, 1, -40, 0);
+   test_2fg_scroll(dev, 0, -40, 0);
check_2fg_scroll(dev, LIBINPUT_POINTER_AXIS_SCROLL_VERTICAL, -10);
-   test_2fg_scroll(dev, 40, 1, 0);
+   test_2fg_scroll(dev, 40, 0, 0);
check_2fg_scroll(dev, LIBINPUT_POINTER_AXIS_SCROLL_HORIZONTAL, 10);
-   test_2fg_scroll(dev, -40, 1, 0);
+   test_2fg_scroll(dev, -40, 0, 0);
check_2fg_scroll(dev, LIBINPUT_POINTER_AXIS_SCROLL_HORIZONTAL, -10);
 
/* 2fg scroll smaller than the threshold should not generate events */
-- 
1.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 6/7] touchpad: require a <45 degree movement for a palm to become a touch

2014-07-15 Thread Peter Hutterer 
Any legitimate finger movement that starts in the palm area is expected to
move out of the palm area at an angle roughly orthogonal to the edge of the
touchpad. Check for the direction of the movement vector, and if it is within
the accepted cardinal/ordinal directions then proceed.

Signed-off-by: Peter Hutterer 
---
Thought this was an interesting-enough idea. The palmdata on the edges tends
to move around a bit but it does so mostly vertically. A pure movement
threshold is not enough as the palm moves whenever the top or bottom row of
the keys are accessed.

Adding the directional component should filter palm events. But tbh, this is
all just based on one touchpad so far.

 src/evdev-mt-touchpad.c | 13 ++---
 src/evdev-mt-touchpad.h |  1 +
 test/touchpad.c | 15 +++
 3 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 830e9fe..2cf8b56 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -363,15 +363,20 @@ static void
 tp_palm_detect(struct tp_dispatch *tp, struct tp_touch *t, uint64_t time)
 {
const int PALM_TIMEOUT = 200; /* ms */
+   const int DIRECTIONS = NE|E|SE|SW|W|NW;
 
/* If labelled a touch as palm, we unlabel as palm when
-  we move out of the palm edge zone within the timeout.
+  we move out of the palm edge zone within the timeout, provided
+  the direction is within 45 degrees of the horizontal.
 */
if (t->palm.is_palm) {
if (time < t->palm.time + PALM_TIMEOUT &&
(t->x > tp->palm.left_edge && t->x < tp->palm.right_edge)) {
-   t->palm.is_palm = false;
-   tp_set_pointer(tp, t);
+   int dirs = vector_get_direction(t->x - t->palm.x, t->y 
- t->palm.y);
+   if ((dirs & DIRECTIONS) && !(dirs & ~DIRECTIONS)) {
+   t->palm.is_palm = false;
+   tp_set_pointer(tp, t);
+   }
}
return;
}
@@ -391,6 +396,8 @@ tp_palm_detect(struct tp_dispatch *tp, struct tp_touch *t, 
uint64_t time)
 
t->palm.is_palm = true;
t->palm.time = time;
+   t->palm.x = t->x;
+   t->palm.y = t->y;
 }
 
 static void
diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
index 8255a1c..4779120 100644
--- a/src/evdev-mt-touchpad.h
+++ b/src/evdev-mt-touchpad.h
@@ -142,6 +142,7 @@ struct tp_touch {
 
struct {
bool is_palm;
+   int32_t x, y;  /* first coordinates if is_palm == true */
uint32_t time; /* first timestamp if is_palm == true */
} palm;
 };
diff --git a/test/touchpad.c b/test/touchpad.c
index 5bb8d9b..259b227 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -1302,6 +1302,20 @@ START_TEST(touchpad_palm_detect_at_top_corners)
 }
 END_TEST
 
+START_TEST(touchpad_palm_detect_palm_stays_palm)
+{
+   struct litest_device *dev = litest_current_device();
+   struct libinput *li = dev->libinput;
+
+   litest_drain_events(li);
+
+   litest_touch_down(dev, 0, 99, 20);
+   litest_touch_move_to(dev, 0, 99, 20, 75, 99, 5);
+   litest_touch_up(dev, 0);
+   litest_assert_empty_queue(li);
+}
+END_TEST
+
 START_TEST(touchpad_palm_detect_palm_becomes_pointer)
 {
struct litest_device *dev = litest_current_device();
@@ -1419,6 +1433,7 @@ int main(int argc, char **argv) {
litest_add("touchpad:palm", touchpad_palm_detect_at_bottom_corners, 
LITEST_TOUCHPAD, LITEST_CLICKPAD);
litest_add("touchpad:palm", touchpad_palm_detect_at_top_corners, 
LITEST_TOUCHPAD, LITEST_TOPBUTTONPAD);
litest_add("touchpad:palm", touchpad_palm_detect_palm_becomes_pointer, 
LITEST_TOUCHPAD, LITEST_ANY);
+   litest_add("touchpad:palm", touchpad_palm_detect_palm_stays_palm, 
LITEST_TOUCHPAD, LITEST_ANY);
litest_add("touchpad:palm", 
touchpad_palm_detect_no_palm_moving_into_edges, LITEST_TOUCHPAD, LITEST_ANY);
 
return litest_run(argc, argv);
-- 
1.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] client: add a public function to make a roundtrip on a custom queue

2014-07-15 Thread Daniel Stone 
Hi,

On Tuesday, July 15, 2014, Giulio Camuffo  wrote:

> 2014-07-14 22:31 GMT+03:00 Jason Ekstrand  >:
> > Guilio,
> > Would it be better to name it wl_event_queue_roundtrip and just have it
> take
> > the wl_event_queue?  I guess it is sort-of a wl_display operation, but
> you
> > could argue it either way.  Thoughts?
>
> You have a point here, it makes more sense.


TBH I'd rather steer clear of that nomenclature, since the 'queue' in an
immediate request context implies delayed dispatch, rather than on a queue.

Sorry for being that bikeshed guy ...
-d


> > --Jason Ekstrand
> >
> >
> > On Mon, Jul 14, 2014 at 7:15 AM, Giulio Camuffo  >
> > wrote:
> >>
> >> wl_display_roundtrip() works on the default queue. Add a parallel
> >> wl_display_roundtrip_queue().
> >> ---
> >>
> >> v3: fixed dispatch call in place of dispatch_queue
> >> documented the queue parameter
> >>  src/wayland-client.c | 24 +---
> >>  src/wayland-client.h |  2 ++
> >>  2 files changed, 23 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/src/wayland-client.c b/src/wayland-client.c
> >> index e8aab7e..d2c1b5c 100644
> >> --- a/src/wayland-client.c
> >> +++ b/src/wayland-client.c
> >> @@ -834,15 +834,16 @@ static const struct wl_callback_listener
> >> sync_listener = {
> >>  /** Block until all pending request are processed by the server
> >>   *
> >>   * \param display The display context object
> >> + * \param queue The queue on which to run the roundtrip
> >>   * \return The number of dispatched events on success or -1 on failure
> >>   *
> >>   * Blocks until the server process all currently issued requests and
> >> - * sends out pending events on all event queues.
> >> + * sends out pending events on the event queue.
> >>   *
> >>   * \memberof wl_display
> >>   */
> >>  WL_EXPORT int
> >> -wl_display_roundtrip(struct wl_display *display)
> >> +wl_display_roundtrip_queue(struct wl_display *display, struct
> >> wl_event_queue *queue)
> >>  {
> >> struct wl_callback *callback;
> >> int done, ret = 0;
> >> @@ -851,9 +852,10 @@ wl_display_roundtrip(struct wl_display *display)
> >> callback = wl_display_sync(display);
> >> if (callback == NULL)
> >> return -1;
> >> +   wl_proxy_set_queue(callback, queue);
> >> wl_callback_add_listener(callback, &sync_listener, &done);
> >> while (!done && ret >= 0)
> >> -   ret = wl_display_dispatch(display);
> >> +   ret = wl_display_dispatch_queue(display, queue);
> >>
> >> if (ret == -1 && !done)
> >> wl_callback_destroy(callback);
> >> @@ -861,6 +863,22 @@ wl_display_roundtrip(struct wl_display *display)
> >> return ret;
> >>  }
> >>
> >> +/** Block until all pending request are processed by the server
> >> + *
> >> + * \param display The display context object
> >> + * \return The number of dispatched events on success or -1 on failure
> >> + *
> >> + * Blocks until the server process all currently issued requests and
> >> + * sends out pending events on the default event queue.
> >> + *
> >> + * \memberof wl_display
> >> + */
> >> +WL_EXPORT int
> >> +wl_display_roundtrip(struct wl_display *display)
> >> +{
> >> +   wl_display_roundtrip_queue(display, &display->default_queue);
> >> +}
> >> +
> >>  static int
> >>  create_proxies(struct wl_proxy *sender, struct wl_closure *closure)
> >>  {
> >> diff --git a/src/wayland-client.h b/src/wayland-client.h
> >> index 2a32785..4377207 100644
> >> --- a/src/wayland-client.h
> >> +++ b/src/wayland-client.h
> >> @@ -163,6 +163,8 @@ int wl_display_dispatch_pending(struct wl_display
> >> *display);
> >>  int wl_display_get_error(struct wl_display *display);
> >>
> >>  int wl_display_flush(struct wl_display *display);
> >> +int wl_display_roundtrip_queue(struct wl_display *display,
> >> +   struct wl_event_queue *queue);
> >>  int wl_display_roundtrip(struct wl_display *display);
> >>  struct wl_event_queue *wl_display_create_queue(struct wl_display
> >> *display);
> >>
> >> --
> >> 2.0.1
> >>
> >> ___
> >> wayland-devel mailing list
> >> wayland-devel@lists.freedesktop.org 
> >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
> >
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org 
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wcap-snapshot

2014-07-15 Thread Boyan Ding 
Hi,
  The wcap-snapshot program is now integrated into wcap-decode now but
the README didn't change, we should really fix that.
  So to extract a specific frame from a wcap file (recorded using Mod+R
in weston), you can use
  wcap-decode capture.wcap --frame=

  Or more directly, if you just want a screenshot, you can use Mod+S in
weston.

Cheers,
Boyan Ding


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] client: add a public function to make a roundtrip on a custom queue

2014-07-15 Thread Jason Ekstrand 
On Tue, Jul 15, 2014 at 10:39 AM, Daniel Stone  wrote:

> Hi,
>
>
> On Tuesday, July 15, 2014, Giulio Camuffo  wrote:
>
>> 2014-07-14 22:31 GMT+03:00 Jason Ekstrand :
>> > Guilio,
>> > Would it be better to name it wl_event_queue_roundtrip and just have it
>> take
>> > the wl_event_queue?  I guess it is sort-of a wl_display operation, but
>> you
>> > could argue it either way.  Thoughts?
>>
>> You have a point here, it makes more sense.
>
>
> TBH I'd rather steer clear of that nomenclature, since the 'queue' in an
> immediate request context implies delayed dispatch, rather than on a queue.
>
> Sorry for being that bikeshed guy ...


It's not my fault it's named wl_even_queue and therefore tne natural name
sounds like you're queueing a roundtrip on a wl_event object...  That said,
you do have a point and it is a bad name.  I just don't know what else to
call it.
--Jasn


> -d
>
>
>
>> > --Jason Ekstrand
>> >
>> >
>> > On Mon, Jul 14, 2014 at 7:15 AM, Giulio Camuffo <
>> giuliocamu...@gmail.com>
>> > wrote:
>> >>
>> >> wl_display_roundtrip() works on the default queue. Add a parallel
>> >> wl_display_roundtrip_queue().
>> >> ---
>> >>
>> >> v3: fixed dispatch call in place of dispatch_queue
>> >> documented the queue parameter
>> >>  src/wayland-client.c | 24 +---
>> >>  src/wayland-client.h |  2 ++
>> >>  2 files changed, 23 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/src/wayland-client.c b/src/wayland-client.c
>> >> index e8aab7e..d2c1b5c 100644
>> >> --- a/src/wayland-client.c
>> >> +++ b/src/wayland-client.c
>> >> @@ -834,15 +834,16 @@ static const struct wl_callback_listener
>> >> sync_listener = {
>> >>  /** Block until all pending request are processed by the server
>> >>   *
>> >>   * \param display The display context object
>> >> + * \param queue The queue on which to run the roundtrip
>> >>   * \return The number of dispatched events on success or -1 on failure
>> >>   *
>> >>   * Blocks until the server process all currently issued requests and
>> >> - * sends out pending events on all event queues.
>> >> + * sends out pending events on the event queue.
>> >>   *
>> >>   * \memberof wl_display
>> >>   */
>> >>  WL_EXPORT int
>> >> -wl_display_roundtrip(struct wl_display *display)
>> >> +wl_display_roundtrip_queue(struct wl_display *display, struct
>> >> wl_event_queue *queue)
>> >>  {
>> >> struct wl_callback *callback;
>> >> int done, ret = 0;
>> >> @@ -851,9 +852,10 @@ wl_display_roundtrip(struct wl_display *display)
>> >> callback = wl_display_sync(display);
>> >> if (callback == NULL)
>> >> return -1;
>> >> +   wl_proxy_set_queue(callback, queue);
>> >> wl_callback_add_listener(callback, &sync_listener, &done);
>> >> while (!done && ret >= 0)
>> >> -   ret = wl_display_dispatch(display);
>> >> +   ret = wl_display_dispatch_queue(display, queue);
>> >>
>> >> if (ret == -1 && !done)
>> >> wl_callback_destroy(callback);
>> >> @@ -861,6 +863,22 @@ wl_display_roundtrip(struct wl_display *display)
>> >> return ret;
>> >>  }
>> >>
>> >> +/** Block until all pending request are processed by the server
>> >> + *
>> >> + * \param display The display context object
>> >> + * \return The number of dispatched events on success or -1 on failure
>> >> + *
>> >> + * Blocks until the server process all currently issued requests and
>> >> + * sends out pending events on the default event queue.
>> >> + *
>> >> + * \memberof wl_display
>> >> + */
>> >> +WL_EXPORT int
>> >> +wl_display_roundtrip(struct wl_display *display)
>> >> +{
>> >> +   wl_display_roundtrip_queue(display, &display->default_queue);
>> >> +}
>> >> +
>> >>  static int
>> >>  create_proxies(struct wl_proxy *sender, struct wl_closure *closure)
>> >>  {
>> >> diff --git a/src/wayland-client.h b/src/wayland-client.h
>> >> index 2a32785..4377207 100644
>> >> --- a/src/wayland-client.h
>> >> +++ b/src/wayland-client.h
>> >> @@ -163,6 +163,8 @@ int wl_display_dispatch_pending(struct wl_display
>> >> *display);
>> >>  int wl_display_get_error(struct wl_display *display);
>> >>
>> >>  int wl_display_flush(struct wl_display *display);
>> >> +int wl_display_roundtrip_queue(struct wl_display *display,
>> >> +   struct wl_event_queue *queue);
>> >>  int wl_display_roundtrip(struct wl_display *display);
>> >>  struct wl_event_queue *wl_display_create_queue(struct wl_display
>> >> *display);
>> >>
>> >> --
>> >> 2.0.1
>> >>
>> >> ___
>> >> wayland-devel mailing list
>> >> wayland-devel@lists.freedesktop.org
>> >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>> >
>> >
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>
___
wayland-devel

Re: [PATCH wayland] client: add a public function to make a roundtrip on a custom queue

2014-07-15 Thread Daniel Stone 
Hi,

On Tuesday, July 15, 2014, Giulio Camuffo  wrote:

> 2014-07-14 22:31 GMT+03:00 Jason Ekstrand  >:
> > Guilio,
> > Would it be better to name it wl_event_queue_roundtrip and just have it
> take
> > the wl_event_queue?  I guess it is sort-of a wl_display operation, but
> you
> > could argue it either way.  Thoughts?
>
> You have a point here, it makes more sense.


TBH I'd rather steer clear of that nomenclature, since the 'queue' in an
immediate request context implies delayed dispatch, rather than on a queue.

Sorry for being that bikeshed guy ...
-d


> > --Jason Ekstrand
> >
> >
> > On Mon, Jul 14, 2014 at 7:15 AM, Giulio Camuffo  >
> > wrote:
> >>
> >> wl_display_roundtrip() works on the default queue. Add a parallel
> >> wl_display_roundtrip_queue().
> >> ---
> >>
> >> v3: fixed dispatch call in place of dispatch_queue
> >> documented the queue parameter
> >>  src/wayland-client.c | 24 +---
> >>  src/wayland-client.h |  2 ++
> >>  2 files changed, 23 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/src/wayland-client.c b/src/wayland-client.c
> >> index e8aab7e..d2c1b5c 100644
> >> --- a/src/wayland-client.c
> >> +++ b/src/wayland-client.c
> >> @@ -834,15 +834,16 @@ static const struct wl_callback_listener
> >> sync_listener = {
> >>  /** Block until all pending request are processed by the server
> >>   *
> >>   * \param display The display context object
> >> + * \param queue The queue on which to run the roundtrip
> >>   * \return The number of dispatched events on success or -1 on failure
> >>   *
> >>   * Blocks until the server process all currently issued requests and
> >> - * sends out pending events on all event queues.
> >> + * sends out pending events on the event queue.
> >>   *
> >>   * \memberof wl_display
> >>   */
> >>  WL_EXPORT int
> >> -wl_display_roundtrip(struct wl_display *display)
> >> +wl_display_roundtrip_queue(struct wl_display *display, struct
> >> wl_event_queue *queue)
> >>  {
> >> struct wl_callback *callback;
> >> int done, ret = 0;
> >> @@ -851,9 +852,10 @@ wl_display_roundtrip(struct wl_display *display)
> >> callback = wl_display_sync(display);
> >> if (callback == NULL)
> >> return -1;
> >> +   wl_proxy_set_queue(callback, queue);
> >> wl_callback_add_listener(callback, &sync_listener, &done);
> >> while (!done && ret >= 0)
> >> -   ret = wl_display_dispatch(display);
> >> +   ret = wl_display_dispatch_queue(display, queue);
> >>
> >> if (ret == -1 && !done)
> >> wl_callback_destroy(callback);
> >> @@ -861,6 +863,22 @@ wl_display_roundtrip(struct wl_display *display)
> >> return ret;
> >>  }
> >>
> >> +/** Block until all pending request are processed by the server
> >> + *
> >> + * \param display The display context object
> >> + * \return The number of dispatched events on success or -1 on failure
> >> + *
> >> + * Blocks until the server process all currently issued requests and
> >> + * sends out pending events on the default event queue.
> >> + *
> >> + * \memberof wl_display
> >> + */
> >> +WL_EXPORT int
> >> +wl_display_roundtrip(struct wl_display *display)
> >> +{
> >> +   wl_display_roundtrip_queue(display, &display->default_queue);
> >> +}
> >> +
> >>  static int
> >>  create_proxies(struct wl_proxy *sender, struct wl_closure *closure)
> >>  {
> >> diff --git a/src/wayland-client.h b/src/wayland-client.h
> >> index 2a32785..4377207 100644
> >> --- a/src/wayland-client.h
> >> +++ b/src/wayland-client.h
> >> @@ -163,6 +163,8 @@ int wl_display_dispatch_pending(struct wl_display
> >> *display);
> >>  int wl_display_get_error(struct wl_display *display);
> >>
> >>  int wl_display_flush(struct wl_display *display);
> >> +int wl_display_roundtrip_queue(struct wl_display *display,
> >> +   struct wl_event_queue *queue);
> >>  int wl_display_roundtrip(struct wl_display *display);
> >>  struct wl_event_queue *wl_display_create_queue(struct wl_display
> >> *display);
> >>
> >> --
> >> 2.0.1
> >>
> >> ___
> >> wayland-devel mailing list
> >> wayland-devel@lists.freedesktop.org 
> >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
> >
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org 
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

wcap-snapshot

2014-07-15 Thread pplive 
Dear all,

I need a snapshot program under weston/wayland. According to
wcap/README, there is a program name 'wcap-snapshot'. I can find some
screenshoter program in src/ , but I don't know how can I compile this
wcap-snapshot. Can somebody give me a hint? Thanks so much!

Best regards,
Alex
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: libinput polling

2014-07-15 Thread Stefanos A. 
2014-07-15 17:32 GMT+02:00 Thiago Macieira :

> On Tuesday 15 July 2014 11:51:40 Stefanos A. wrote:
> > while (!exit) {
> > int ret = poll(&pfd, 1, -1);
> > if (ret < 0) {
> > // ret is always -1
> > exit = ret;
> > }
> > else {
> > // never gets here
> > libinput_dispatch(input_context);
> > }
> > }
> >
> > If I remove 'poll' then I can retrieve input events without any trouble.
> >
> > Is what I am trying to do supported? If so, what could be the problem?
> Or,
> > if not, then is there a supported way to block on libinput events?
>
> What errno are you getting?
>

The original code is not written in C, so I mistakenly assumed I couldn't
access errno. I checked the documentation and it appears I was wrong - so I
added the necessary code to retrieve errno and... poll() no longer returns
an error.

It may be that I have changed something in the meantime that resolves the
issue, whatever that was, although I cannot find anything relevant in the
git log. Oh well, the libinput driver is working correctly now. If
something comes up, and I can conclusively verify its not my code, I'll
follow up in bugzilla.

Cheers!
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: libinput polling

2014-07-15 Thread Thiago Macieira 
On Tuesday 15 July 2014 11:51:40 Stefanos A. wrote:
> while (!exit) {
> int ret = poll(&pfd, 1, -1);
> if (ret < 0) {
> // ret is always -1
> exit = ret;
> }
> else {
> // never gets here
> libinput_dispatch(input_context);
> }
> }
> 
> If I remove 'poll' then I can retrieve input events without any trouble.
> 
> Is what I am trying to do supported? If so, what could be the problem? Or,
> if not, then is there a supported way to block on libinput events?

What errno are you getting?
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: New guy

2014-07-15 Thread Jasper St. Pierre 
On Tue, Jul 15, 2014 at 7:48 AM, Magnus Hoff 
wrote:

> Hi :)
>
> I'm Magnus, and I'd like to help. I'm not scared of working with
> low-level stuff in C :) My experience is more with C++, so I will need
> some getting used to C idioms.
>
> I have successfully installed and run Wayland and Weston on my
> machine, both on a dedicated virtual terminal and nested within X. I
> am super excited about how great an improvement Wayland can turn out
> to be!
>

Hey Magnus! Glad to hear you're excited about all this!


> I think it's most effective if I can help with something that's
> specific to my hardware and scratches my own itch, so I'll proceed by
> presenting my hardware and ideas for related things that may need
> implementing:
>
> I have a MacBook Pro Retina 13", late 2012 model:
> http://support.apple.com/kb/sp658
>
> My graphics chipset is Intel HD Graphics 4000. There are performance
> issues here, especially with big textures (8kx8k) and as the video
> memory gets exhausted, but I'm guessing the problems here are outside
> of the scope of wayland. Maybe there is something to be done here to
> support a resource constrained environment?
>
> I have a high DPI display (227 PPI). I can help with stuff related to
> high DPI support.
>
> I have an external monitor, Dell 30" at 2560x1600 pixels resolution
> (100 PPI). I can help with external monitor-support and dynamic DPI
> support. I don't know what plans you have made for supporting a
> hetrogenous DPI environment. I also like to close and tuck away my
> laptop while using the external monitor. This doesn't appear to be
> very well supported, save from configuring it explicitly in
> weston.ini.
>
> I also have an integrated touchpad which has very high resolution and
> sensitivity. I don't know the low level details of programming this,
> but I'd like to help with designing good support for this input
> method. Ideas:
>
>  * Support for (sub-)pixel resolution of two-finger scroll. In X.org,
> two-finger scroll is mapped to button-events, which means that the
> resolution of scrolling is reduced to line-level. Can we support such
> smooth scrolling in wayland?
>

Smooth scrolling is supported in XI2 by some special axes, but not a lot of
applications support this.

Scrolling in Wayland is done by the "axis" event [0], which describes
relative changes on an axis, and not by button presses. So apps couldn't do
chunky scrolling even if they wanted to!

If you're running Weston under X11, then that doesn't have support for XI2
smooth scrolling, it just uses the button presses [1]. The nested X11 is
more meant as a testing and debugging, so it only supports core events. If
you want to get XI2 and smooth scrolling working for the nested X11
compositor, I don't think anybody would mind.


> * Similar support for several-finger-gestures. In X.org, I use
> touchegg to switch workspaces by a four-finger swipe. The interaction
> is like this: 1. put four fingers on touchpad, 2. swipe left/right, 3.
> let fingers go, 4. observe that the workspace changes. The
> corresponding interaction in OS X is like this: 1. put three fingers
> on touchpad, 2. as I swipe left or right, the workspaces on the screen
> respond proportionately by moving right/left, 3. as I let go, one of
> the workspaces snap to fill the screen.
>

The feedback in OS X is immediate, making the interaction feel much
> better and leaves the user with a much greater feeling of control. Can
> we support this in wayland?
>

XI2 is really unfortunate with how its protocol handles touch. We recently
added gesture support in GNOME for X11. I'm not too familiar with it
myself, so I'm CC'ing Carlos Garnacho, who wrote our gestures
implementation, to see if he has any feedback about whether the Wayland
protocol works fine and would allow for really smooth gestures.

I also have a Wacom Bamboo Pen&Touch, but I am not a graphics artist.
> I can help with testing tablet-/pen-stuff.
>
>
> That's probably more ideas than I can realize on my own :) Does
> anybody want to help me with contributing something valuable in one of
> these areas?
>
>
> Thanks,
> Magnus Hoff
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>

[0]
http://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml#n1467
[1]
http://cgit.freedesktop.org/wayland/weston/tree/src/compositor-x11.c#n1026

-- 
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

New guy

2014-07-15 Thread Magnus Hoff 
Hi :)

I'm Magnus, and I'd like to help. I'm not scared of working with
low-level stuff in C :) My experience is more with C++, so I will need
some getting used to C idioms.

I have successfully installed and run Wayland and Weston on my
machine, both on a dedicated virtual terminal and nested within X. I
am super excited about how great an improvement Wayland can turn out
to be!

I think it's most effective if I can help with something that's
specific to my hardware and scratches my own itch, so I'll proceed by
presenting my hardware and ideas for related things that may need
implementing:

I have a MacBook Pro Retina 13", late 2012 model:
http://support.apple.com/kb/sp658

My graphics chipset is Intel HD Graphics 4000. There are performance
issues here, especially with big textures (8kx8k) and as the video
memory gets exhausted, but I'm guessing the problems here are outside
of the scope of wayland. Maybe there is something to be done here to
support a resource constrained environment?

I have a high DPI display (227 PPI). I can help with stuff related to
high DPI support.

I have an external monitor, Dell 30" at 2560x1600 pixels resolution
(100 PPI). I can help with external monitor-support and dynamic DPI
support. I don't know what plans you have made for supporting a
hetrogenous DPI environment. I also like to close and tuck away my
laptop while using the external monitor. This doesn't appear to be
very well supported, save from configuring it explicitly in
weston.ini.

I also have an integrated touchpad which has very high resolution and
sensitivity. I don't know the low level details of programming this,
but I'd like to help with designing good support for this input
method. Ideas:

 * Support for (sub-)pixel resolution of two-finger scroll. In X.org,
two-finger scroll is mapped to button-events, which means that the
resolution of scrolling is reduced to line-level. Can we support such
smooth scrolling in wayland?

* Similar support for several-finger-gestures. In X.org, I use
touchegg to switch workspaces by a four-finger swipe. The interaction
is like this: 1. put four fingers on touchpad, 2. swipe left/right, 3.
let fingers go, 4. observe that the workspace changes. The
corresponding interaction in OS X is like this: 1. put three fingers
on touchpad, 2. as I swipe left or right, the workspaces on the screen
respond proportionately by moving right/left, 3. as I let go, one of
the workspaces snap to fill the screen.

The feedback in OS X is immediate, making the interaction feel much
better and leaves the user with a much greater feeling of control. Can
we support this in wayland?

I also have a Wacom Bamboo Pen&Touch, but I am not a graphics artist.
I can help with testing tablet-/pen-stuff.


That's probably more ideas than I can realize on my own :) Does
anybody want to help me with contributing something valuable in one of
these areas?


Thanks,
Magnus Hoff
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: libinput polling

2014-07-15 Thread Stefanos A. 
Forgot to mention that I am using libinput 0.2.0 and libsystemd 215 (latest
versions available on Arch).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

libinput polling

2014-07-15 Thread Stefanos A. 
Hello everyone,

I am trying out libinput as an input backend for OpenTK[1] when running on
a VT terminal. Using weston as a reference, I have managed to get keyboard
input working as expected. The API is pleasantly terse, with very little of
the X11/XI2 non-sense remaining.

There is one thing I haven't been able to manage so far is to implement a
blocking poll on the input thread. If my understanding is correct (and it
probably isn't), I should be able to call libinput_get_fd() and then poll
on that for events. However, if I do that, poll invariably returns an error
(-1):


 int fd = libinput_get_fd(input_context);
struct poll_fd pfd = {
.fd = fd,
.events = POLLIN
};

while (!exit) {
int ret = poll(&pfd, 1, -1);
if (ret < 0) {
// ret is always -1
exit = ret;
}
else {
// never gets here
libinput_dispatch(input_context);
}
}

If I remove 'poll' then I can retrieve input events without any trouble.

Is what I am trying to do supported? If so, what could be the problem? Or,
if not, then is there a supported way to block on libinput events?

Cheers!


[1] http://www.opentk.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland v3] client: add a public function to make a roundtrip on a custom queue

2014-07-15 Thread Giulio Camuffo 
2014-07-14 22:31 GMT+03:00 Jason Ekstrand :
> Guilio,
> Would it be better to name it wl_event_queue_roundtrip and just have it take
> the wl_event_queue?  I guess it is sort-of a wl_display operation, but you
> could argue it either way.  Thoughts?

You have a point here, it makes more sense.

> --Jason Ekstrand
>
>
> On Mon, Jul 14, 2014 at 7:15 AM, Giulio Camuffo 
> wrote:
>>
>> wl_display_roundtrip() works on the default queue. Add a parallel
>> wl_display_roundtrip_queue().
>> ---
>>
>> v3: fixed dispatch call in place of dispatch_queue
>> documented the queue parameter
>>  src/wayland-client.c | 24 +---
>>  src/wayland-client.h |  2 ++
>>  2 files changed, 23 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/wayland-client.c b/src/wayland-client.c
>> index e8aab7e..d2c1b5c 100644
>> --- a/src/wayland-client.c
>> +++ b/src/wayland-client.c
>> @@ -834,15 +834,16 @@ static const struct wl_callback_listener
>> sync_listener = {
>>  /** Block until all pending request are processed by the server
>>   *
>>   * \param display The display context object
>> + * \param queue The queue on which to run the roundtrip
>>   * \return The number of dispatched events on success or -1 on failure
>>   *
>>   * Blocks until the server process all currently issued requests and
>> - * sends out pending events on all event queues.
>> + * sends out pending events on the event queue.
>>   *
>>   * \memberof wl_display
>>   */
>>  WL_EXPORT int
>> -wl_display_roundtrip(struct wl_display *display)
>> +wl_display_roundtrip_queue(struct wl_display *display, struct
>> wl_event_queue *queue)
>>  {
>> struct wl_callback *callback;
>> int done, ret = 0;
>> @@ -851,9 +852,10 @@ wl_display_roundtrip(struct wl_display *display)
>> callback = wl_display_sync(display);
>> if (callback == NULL)
>> return -1;
>> +   wl_proxy_set_queue(callback, queue);
>> wl_callback_add_listener(callback, &sync_listener, &done);
>> while (!done && ret >= 0)
>> -   ret = wl_display_dispatch(display);
>> +   ret = wl_display_dispatch_queue(display, queue);
>>
>> if (ret == -1 && !done)
>> wl_callback_destroy(callback);
>> @@ -861,6 +863,22 @@ wl_display_roundtrip(struct wl_display *display)
>> return ret;
>>  }
>>
>> +/** Block until all pending request are processed by the server
>> + *
>> + * \param display The display context object
>> + * \return The number of dispatched events on success or -1 on failure
>> + *
>> + * Blocks until the server process all currently issued requests and
>> + * sends out pending events on the default event queue.
>> + *
>> + * \memberof wl_display
>> + */
>> +WL_EXPORT int
>> +wl_display_roundtrip(struct wl_display *display)
>> +{
>> +   wl_display_roundtrip_queue(display, &display->default_queue);
>> +}
>> +
>>  static int
>>  create_proxies(struct wl_proxy *sender, struct wl_closure *closure)
>>  {
>> diff --git a/src/wayland-client.h b/src/wayland-client.h
>> index 2a32785..4377207 100644
>> --- a/src/wayland-client.h
>> +++ b/src/wayland-client.h
>> @@ -163,6 +163,8 @@ int wl_display_dispatch_pending(struct wl_display
>> *display);
>>  int wl_display_get_error(struct wl_display *display);
>>
>>  int wl_display_flush(struct wl_display *display);
>> +int wl_display_roundtrip_queue(struct wl_display *display,
>> +   struct wl_event_queue *queue);
>>  int wl_display_roundtrip(struct wl_display *display);
>>  struct wl_event_queue *wl_display_create_queue(struct wl_display
>> *display);
>>
>> --
>> 2.0.1
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel