Re: Wayland generic dmabuf protocol
On 06/09/2014 01:23 PM, Daniel Stone wrote: Hi, On 9 June 2014 12:06, Pekka Paalanen pekka.paala...@collabora.co.uk mailto:pekka.paala...@collabora.co.uk wrote: On Mon, 9 Jun 2014 11:00:04 +0200 Benjamin Gaignard benjamin.gaign...@linaro.org mailto:benjamin.gaign...@linaro.org wrote: One of the main comment on the latest patches was that wl_dmabuf use DRM for buffer allocation. This appear to be an issue since wayland doesn't want to rely on one specific framework (DRM, or V4L2) for buffer allocation, so we have start working on a central dmabuf allocation on kernel side. The goal is provide some as generic as possible to make it acceptable by wayland. Why would Wayland need a central allocator for dmabuf? I think you've just answered your own question further below: On my hardware the patches you have (+ this one on gstwaylandsink https://bugzilla.gnome.org/show_bug.cgi?id=711155 https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.gnome.org/show_bug.cgi?id%3D711155k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0Am=NHSSDNdXVt2oCxexwhcqQAQSZ3K6Xa8Zvuv0jMYfS2c%3D%0As=f6d8c24d7fa4ccdacae79aeaa8221773d892350a191f96cb3bab4f542fb3ad1c) allow me to do zero copy between the hardware video decoder and the display engine. I don't have implemented GPU yet because my hardware is able to do compose few video overlays planes and it was enough for my tests. Right. What I have been thinking is, that the compositor must be able to use the new wl_buffer and we need to guarantee that before-hand. If the compositor fails to use a wl_buffer when the client has already attached it to a wl_surface and it is time to repaint, it is too late and the user will see a glitch. Recovering from that requires asking the client to provide a new wl_buffer of a different kind, which might take time. Or a very rude compositor would just send a protocol error, and then we'd get bug reports like the video player just disappears when I try to play (and ps. I have an old kernel that doesn't support importing whatever). I believe we must allow the compositor to test the wl_buffer before it is usable for the client. That is the reason for the roundtrippy design of the below proposal. A central allocator would solve these issues, by having everyone agree on the restrictions upfront, instead of working out which of the media decode engine, camera, GPU, or display controller is the lowest common denominator, and forcing all allocations through there. One such solution was discussed a while back WRT ION: https://lwn.net/Articles/565469/ https://urldefense.proofpoint.com/v1/url?u=https://lwn.net/Articles/565469/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0Am=NHSSDNdXVt2oCxexwhcqQAQSZ3K6Xa8Zvuv0jMYfS2c%3D%0As=36b71b58f7fc6f3d594529cc674364a23718e5cbb38a439e4a9c628848a13b3a See the 'possible solutions' part for a way for people to agree on restrictions wrt tiling, stride, contiguousness, etc. Hi! I think before deciding on something like this, one needs also to account for the virtual drivers like vmwgfx. Here, a dma-buf internally holds an opaque handle to an object on the host / hypervisor, and the actual memory buffer is only temporarily allocated for dma-buf operations that strictly need it. Not to hold the data while transferring it between devices or applications. Let's say you'd want to use a USB display controller in a virtual machine with the vmwgfx exported prime objects, for example. There's no common denominator. The vmwgfx driver would need to read the dma-buf data from the host object at sg-table export (dma-buf map) time. Whereas if you just want to share data between a wayland server and client, no pages are ever allocated and the only thing passed around is in effect the opaque handle to the host / hypervisor object. I'm currently having trouble seeing how a central allocator would be able to deal with this? /Thomas Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/wayland-develk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0Am=NHSSDNdXVt2oCxexwhcqQAQSZ3K6Xa8Zvuv0jMYfS2c%3D%0As=c4f94901274570868164b5aac297336d544bdba1bc12bda6c09b915fa5495423 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Suggestions on implementing Wayland Protocol Dumper.
On Mon, 09 Jun 2014 16:54:09 +0800 Boyan Ding stu_...@126.com wrote: Hi, According to [1], from which the idea of protocol dumper came, the purpose of the protocol dumper is to track exactly how a client communicate with the server, and to make a difference with how WAYLAND_DEBUG=server works. So IMHO, the protocol dumper may be implemented as a standalone program, though it may probably reside in the wayland source tree. And it job is to reset the WAYLAND_DISPLAY environment argument, fork off the client wanted and redirect what the client send to the real server, dumping the data in the process -- just like a proxy. The benefit of this way of implementation is that it not only help weston but may also help the development of other projects (e.g. you may even use it under Gnome on Wayland). Hi, I fully agree with Boyan here. A basic usage (tracing a single application, all its connections, and all its children) should not require *any* changes to any software: not libwayland, not a compositor, and not clients. If it requires changes or even just recompilation, it will be too hard to use. Bryce gave good examples on why. I also think it should start as a separate project from Wayland and Weston. I would like it to be an independent tool. Wayland is stable, after all, and the tool should not have any specific dependencies to e.g. a compositor. In IRC, I had a discussion with blsd, who wanted to trace absolutely all clients of a compositor from the beginning, and his problem was where to hijack the connections. While it probably would be useful in some cases, I believe the basic usage as above is more important and useful first. Once the basic part works, we can find a way later how to put in place so it will catch all clients. At a later stage, you might also want to see, if some existing analysis framework could be useful (Wireshark?). I have no idea if there is a flexible enough one, and even then it would probably be worthwhile to have a mininal command line tool that just stores the trace into a file and leaves analysis for off-line. Thanks, pq On Mon, 2014-06-09 at 11:17 +0530, Srivardhan wrote: Hi, The following are the ways in which a Protocol Dumper can be implemented: 1. Just before sending a message or when a message is received, the message can be written to a file. This change can be done in libwayland under #ifdef DEBUG. So when built enabling DEBUG, we should get all the protocol messages. 2. We can introduce another layer in Weston for monitoring. This layer would act as Man in the middle. This layer would listen to a socket to which all the Wayland clients would attach and this layer would in turn attach to the server socket. This layer would print the messages it received from the client and would transfer to the server and vise a versa. This could be included in #ifdef DEBUG, so that it is enabled only in DEBUG builds. I feel the 1st approach is simpler, What are your thoughts? Thank-you, Hebbar ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 2/6] test: add litest_assert_empty_queue helper function
Hi,
On 06/11/2014 02:11 AM, Peter Hutterer wrote:
Checks if the queue is empty and prints informatino about any events before
failing.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Looks good:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
test/litest.c | 61
+
test/litest.h | 1 +
test/touchpad.c | 9 ++---
3 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/test/litest.c b/test/litest.c
index 1f1bf7b..571cf76 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -737,6 +737,67 @@ litest_drain_events(struct libinput *li)
}
}
+static void
+litest_print_event(struct libinput_event *event)
+{
+ struct libinput_event_pointer *p;
+ struct libinput_device *dev;
+ enum libinput_event_type type;
+ double x, y;
+
+ dev = libinput_event_get_device(event);
+ type = libinput_event_get_type(event);
+
+ fprintf(stderr,
+ device %s type %d ,
+ libinput_device_get_sysname(dev),
+ type);
+ switch (type) {
+ case LIBINPUT_EVENT_POINTER_MOTION:
+ p = libinput_event_get_pointer_event(event);
+ x = libinput_event_pointer_get_dx(p);
+ y = libinput_event_pointer_get_dy(p);
+ fprintf(stderr, motion: %.2f/%.2f, x, y);
+ break;
+ case LIBINPUT_EVENT_POINTER_MOTION_ABSOLUTE:
+ p = libinput_event_get_pointer_event(event);
+ x = libinput_event_pointer_get_absolute_x(p);
+ y = libinput_event_pointer_get_absolute_y(p);
+ fprintf(stderr, motion: %.2f/%.2f, x, y);
+ break;
+ case LIBINPUT_EVENT_POINTER_BUTTON:
+ p = libinput_event_get_pointer_event(event);
+ fprintf(stderr,
+ button: %d state %d,
+ libinput_event_pointer_get_button(p),
+ libinput_event_pointer_get_button_state(p));
+ break;
+ default:
+ break;
+ }
+
+ fprintf(stderr, \n);
+}
+
+void
+litest_assert_empty_queue(struct libinput *li)
+{
+ bool empty_queue = true;
+ struct libinput_event *event;
+
+ libinput_dispatch(li);
+ while ((event = libinput_get_event(li))) {
+ empty_queue = false;
+ fprintf(stderr,
+ Unexpected event: );
+ litest_print_event(event);
+ libinput_event_destroy(event);
+ libinput_dispatch(li);
+ }
+
+ ck_assert(empty_queue);
+}
+
struct libevdev_uinput *
litest_create_uinput_device_from_description(const char *name,
const struct input_id *id,
diff --git a/test/litest.h b/test/litest.h
index 32e1cb0..170c87c 100644
--- a/test/litest.h
+++ b/test/litest.h
@@ -123,6 +123,7 @@ void litest_keyboard_key(struct litest_device *d,
unsigned int key,
bool is_press);
void litest_drain_events(struct libinput *li);
+void litest_assert_empty_queue(struct libinput *li);
struct libevdev_uinput * litest_create_uinput_device(const char *name,
struct input_id *id,
diff --git a/test/touchpad.c b/test/touchpad.c
index 9c95309..ec412d3 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -182,9 +182,7 @@ START_TEST(touchpad_1fg_tap_n_drag)
assert_button_event(li, BTN_LEFT,
LIBINPUT_BUTTON_STATE_RELEASED);
- libinput_dispatch(li);
- event = libinput_get_event(li);
- ck_assert(event == NULL);
+ litest_assert_empty_queue(li);
}
END_TEST
@@ -192,7 +190,6 @@ START_TEST(touchpad_2fg_tap)
{
struct litest_device *dev = litest_current_device();
struct libinput *li = dev-libinput;
- struct libinput_event *event;
litest_drain_events(dev-libinput);
@@ -209,9 +206,7 @@ START_TEST(touchpad_2fg_tap)
assert_button_event(li, BTN_RIGHT,
LIBINPUT_BUTTON_STATE_RELEASED);
- libinput_dispatch(li);
- event = libinput_get_event(li);
- ck_assert(event == NULL);
+ litest_assert_empty_queue(li);
}
END_TEST
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 1/6] touchpad: always call into the the tap state machine
Hi,
On 06/11/2014 02:11 AM, Peter Hutterer wrote:
A button event consumed by the softbutton or clickpad code does not feed into
the tap state machine, leaving it in its current state. The touch generating
that event however may have triggered state changes.
For some tap/click combinations this gives us either double press/release
events or an inconsistent order of events. Those issues include:
* a really short physical click causes a click + tap-click
* a really short physical click on the right software button causes a right
click + left tap-click
* tap + click causes double button left press events
To avoid these, notify the tap code that a button event has occured and
process that accordingly. Depending on the state this may either continue to
the DEAD state or release the current tap button and then go to the DEAD
state.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Looks good:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
src/evdev-mt-touchpad.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 8b502b7..0294eb2 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -545,13 +545,12 @@ tp_post_events(struct tp_dispatch *tp, uint64_t time)
{
struct tp_touch *t = tp_current_touch(tp);
double dx, dy;
+ int consumed = 0;
- if (tp_post_button_events(tp, time) != 0) {
- tp_stop_scroll_events(tp, time);
- return;
- }
+ consumed |= tp_tap_handle_state(tp, time);
+ consumed |= tp_post_button_events(tp, time);
- if (tp_tap_handle_state(tp, time) != 0) {
+ if (consumed) {
tp_stop_scroll_events(tp, time);
return;
}
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 3/6] test: add a bunch of test for click behavior on touchpads
Hi,
On 06/11/2014 02:11 AM, Peter Hutterer wrote:
Mainly testing the behaviour when clicking during a tap or tap-n-drag. Adds a
new feature to the litest system, Apple clickpads don't have software
buttons by default.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
I've some remarks on the last test, with those fixed:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
test/litest-bcm5974.c | 3 +-
test/litest.h | 1 +
test/touchpad.c | 180
++
3 files changed, 183 insertions(+), 1 deletion(-)
diff --git a/test/litest-bcm5974.c b/test/litest-bcm5974.c
index 33127d9..10a9eb4 100644
--- a/test/litest-bcm5974.c
+++ b/test/litest-bcm5974.c
@@ -97,7 +97,8 @@ static int events[] = {
struct litest_test_device litest_bcm5974_device = {
.type = LITEST_BCM5974,
- .features = LITEST_TOUCHPAD | LITEST_CLICKPAD | LITEST_BUTTON,
+ .features = LITEST_TOUCHPAD | LITEST_CLICKPAD |
+ LITEST_BUTTON | LITEST_APPLE_CLICKPAD,
.shortname = bcm5974,
.setup = litest_bcm5974_setup,
.interface = interface,
diff --git a/test/litest.h b/test/litest.h
index 170c87c..ea7d299 100644
--- a/test/litest.h
+++ b/test/litest.h
@@ -55,6 +55,7 @@ enum litest_device_feature {
LITEST_WHEEL = 1 5,
LITEST_TOUCH = 1 6,
LITEST_SINGLE_TOUCH = 1 7,
+ LITEST_APPLE_CLICKPAD = 1 8,
};
struct litest_device {
diff --git a/test/touchpad.c b/test/touchpad.c
index ec412d3..f9e2820 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -210,6 +210,179 @@ START_TEST(touchpad_2fg_tap)
}
END_TEST
+START_TEST(touchpad_1fg_tap_click)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+
+ litest_drain_events(dev-libinput);
+
+ /* finger down, button click, finger up
+- only one button left event pair */
+ litest_touch_down(dev, 0, 50, 50);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_touch_up(dev, 0);
+
+ libinput_dispatch(li);
+
+ assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+ assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(touchpad_2fg_tap_click)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+
+ litest_drain_events(dev-libinput);
+
+ /* two fingers down, button click, fingers up
+- only one button left event pair */
+ litest_touch_down(dev, 0, 50, 50);
+ litest_touch_down(dev, 1, 70, 50);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_touch_up(dev, 1);
+ litest_touch_up(dev, 0);
+
+ libinput_dispatch(li);
+
+ assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+ assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(touchpad_2fg_tap_click_apple)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+
+ litest_drain_events(dev-libinput);
+
+ /* two fingers down, button click, fingers up
+- only one button right event pair
+(apple have clickfinger enabled by default) */
+ litest_touch_down(dev, 0, 50, 50);
+ litest_touch_down(dev, 1, 70, 50);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_touch_up(dev, 1);
+ litest_touch_up(dev, 0);
+
+ libinput_dispatch(li);
+
+ assert_button_event(li, BTN_RIGHT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+ assert_button_event(li, BTN_RIGHT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(touchpad_1fg_double_tap_click)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+
+ litest_drain_events(dev-libinput);
+
+ /* one finger down, up, down, button click, finger up
+- two button left event pairs */
+ litest_touch_down(dev, 0, 50, 50);
+ litest_touch_up(dev, 0);
+ litest_touch_down(dev, 0, 50, 50);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_event(dev,
Re: [PATCH libinput 5/6] test: Add description for the T440 synaptics touchpad
Hi,
On 06/11/2014 02:11 AM, Peter Hutterer wrote:
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
test/Makefile.am | 1 +
test/litest-synaptics-t440.c | 112
+++
test/litest.c| 2 +
test/litest.h| 2 +
4 files changed, 117 insertions(+)
create mode 100644 test/litest-synaptics-t440.c
Looks good:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
diff --git a/test/Makefile.am b/test/Makefile.am
index 70e83d4..b5dc33c 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -19,6 +19,7 @@ liblitest_la_SOURCES = \
litest-mouse.c \
litest-synaptics.c \
litest-synaptics-st.c \
+ litest-synaptics-t440.c \
litest-trackpoint.c \
litest-wacom-touch.c \
litest.c
diff --git a/test/litest-synaptics-t440.c b/test/litest-synaptics-t440.c
new file mode 100644
index 000..1b66494
--- /dev/null
+++ b/test/litest-synaptics-t440.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright © 2014 Red Hat, Inc.
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that
copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided
as
+ * is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#if HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include litest.h
+#include litest-int.h
+
+static void
+litest_synaptics_t440_setup(void)
+{
+ struct litest_device *d =
litest_create_device(LITEST_SYNAPTICS_TOPBUTTONPAD);
+ litest_set_current_device(d);
+}
+
+static struct input_event down[] = {
+ { .type = EV_KEY, .code = BTN_TOOL_FINGER, .value = 1 },
+ { .type = EV_KEY, .code = BTN_TOUCH, .value = 1 },
+ { .type = EV_ABS, .code = ABS_X, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_Y, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_PRESSURE, .value = 30 },
+ { .type = EV_ABS, .code = ABS_MT_SLOT, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_TRACKING_ID, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_X, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_Y, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
+ { .type = -1, .code = -1 },
+};
+
+static struct input_event move[] = {
+ { .type = EV_ABS, .code = ABS_MT_SLOT, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_X, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_Y, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_X, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_Y, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_KEY, .code = BTN_TOOL_FINGER, .value = 1 },
+ { .type = EV_KEY, .code = BTN_TOUCH, .value = 1 },
+ { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
+ { .type = -1, .code = -1 },
+};
+
+static struct litest_device_interface interface = {
+ .touch_down_events = down,
+ .touch_move_events = move,
+};
+
+static struct input_id input_id = {
+ .bustype = 0x11,
+ .vendor = 0x2,
+ .product = 0x7,
+};
+
+static int events[] = {
+ EV_KEY, BTN_LEFT,
+ EV_KEY, BTN_TOOL_FINGER,
+ EV_KEY, BTN_TOOL_QUINTTAP,
+ EV_KEY, BTN_TOUCH,
+ EV_KEY, BTN_TOOL_DOUBLETAP,
+ EV_KEY, BTN_TOOL_TRIPLETAP,
+ EV_KEY, BTN_TOOL_QUADTAP,
+ INPUT_PROP_MAX, INPUT_PROP_POINTER,
+ INPUT_PROP_MAX, INPUT_PROP_BUTTONPAD,
+ INPUT_PROP_MAX, INPUT_PROP_TOPBUTTONPAD,
+ -1, -1,
+};
+
+static struct input_absinfo absinfo[] = {
+ { ABS_X, 1024, 5112, 0, 0, 42 },
+ { ABS_Y, 2024, 4832, 0, 0, 42 },
+ { ABS_PRESSURE, 0, 255, 0, 0, 0 },
+ { ABS_TOOL_WIDTH, 0, 15, 0, 0, 0 },
+ { ABS_MT_SLOT, 0, 1, 0, 0, 0 },
+ { ABS_MT_POSITION_X, 1024, 5112, 0, 0, 75 },
+ { ABS_MT_POSITION_Y,
Re: [PATCH libinput 6/6] test: add a couple of top software button test
Hi,
On 06/11/2014 02:11 AM, Peter Hutterer wrote:
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
test/touchpad.c | 124
1 file changed, 124 insertions(+)
Looks good:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
diff --git a/test/touchpad.c b/test/touchpad.c
index 7b7cb7d..147d0e2 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -888,6 +888,125 @@ START_TEST(clickpad_softbutton_right_to_left)
}
END_TEST
+START_TEST(clickpad_topsoftbuttons_left)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+
+ litest_drain_events(li);
+
+ litest_touch_down(dev, 0, 10, 5);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ assert_button_event(li,
+ BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+ litest_assert_empty_queue(li);
+
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_touch_up(dev, 0);
+
+ assert_button_event(li,
+ BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(clickpad_topsoftbuttons_right)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+
+ litest_drain_events(li);
+
+ litest_touch_down(dev, 0, 90, 5);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ assert_button_event(li,
+ BTN_RIGHT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+ litest_assert_empty_queue(li);
+
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_touch_up(dev, 0);
+
+ assert_button_event(li,
+ BTN_RIGHT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(clickpad_topsoftbuttons_middle)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+
+ litest_drain_events(li);
+
+ litest_touch_down(dev, 0, 50, 5);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ assert_button_event(li,
+ BTN_MIDDLE,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+ litest_assert_empty_queue(li);
+
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_touch_up(dev, 0);
+
+ assert_button_event(li,
+ BTN_MIDDLE,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(clickpad_topsoftbuttons_move_out_ignore)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+
+ /* Finger down in top button area, wait past enter timeout
+Move into main area, wait past leave timeout
+Click
+ - expect no events
+ */
+
+ litest_drain_events(li);
+
+ litest_touch_down(dev, 0, 50, 5);
+ libinput_dispatch(li);
+ usleep(20);
+ libinput_dispatch(li);
+ litest_assert_empty_queue(li);
+
+ litest_touch_move_to(dev, 0, 50, 5, 80, 90, 20);
+ libinput_dispatch(li);
+ usleep(40);
+ libinput_dispatch(li);
+
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ litest_touch_up(dev, 0);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
int main(int argc, char **argv) {
litest_add(touchpad:motion, touchpad_1fg_motion, LITEST_TOUCHPAD,
LITEST_ANY);
@@ -920,5 +1039,10 @@ int main(int argc, char **argv) {
litest_add(touchpad:softbutton, clickpad_softbutton_left_to_right,
LITEST_CLICKPAD, LITEST_APPLE_CLICKPAD);
litest_add(touchpad:softbutton, clickpad_softbutton_right_to_left,
LITEST_CLICKPAD, LITEST_APPLE_CLICKPAD);
+ litest_add(touchpad:topsoftbuttons, clickpad_topsoftbuttons_left,
LITEST_TOPBUTTONPAD, LITEST_ANY);
+ litest_add(touchpad:topsoftbuttons, clickpad_topsoftbuttons_right,
LITEST_TOPBUTTONPAD, LITEST_ANY);
+ litest_add(touchpad:topsoftbuttons, clickpad_topsoftbuttons_middle,
LITEST_TOPBUTTONPAD, LITEST_ANY);
+ litest_add(touchpad:topsoftbuttons,
clickpad_topsoftbuttons_move_out_ignore, LITEST_TOPBUTTONPAD, LITEST_ANY);
+
return litest_run(argc, argv);
}
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
Re: Wayland generic dmabuf protocol
On Mon, Jun 9, 2014 at 8:44 AM, Pekka Paalanen pekka.paala...@collabora.co.uk wrote: On Mon, 9 Jun 2014 12:23:18 +0100 Daniel Stone dan...@fooishbar.org wrote: Hi, On 9 June 2014 12:06, Pekka Paalanen pekka.paala...@collabora.co.uk wrote: On Mon, 9 Jun 2014 11:00:04 +0200 Benjamin Gaignard benjamin.gaign...@linaro.org wrote: One of the main comment on the latest patches was that wl_dmabuf use DRM for buffer allocation. This appear to be an issue since wayland doesn't want to rely on one specific framework (DRM, or V4L2) for buffer allocation, so we have start working on a central dmabuf allocation on kernel side. The goal is provide some as generic as possible to make it acceptable by wayland. Why would Wayland need a central allocator for dmabuf? I think you've just answered your own question further below: On my hardware the patches you have (+ this one on gstwaylandsink https://bugzilla.gnome.org/show_bug.cgi?id=711155) allow me to do zero copy between the hardware video decoder and the display engine. I don't have implemented GPU yet because my hardware is able to do compose few video overlays planes and it was enough for my tests. Right. What I have been thinking is, that the compositor must be able to use the new wl_buffer and we need to guarantee that before-hand. If the compositor fails to use a wl_buffer when the client has already attached it to a wl_surface and it is time to repaint, it is too late and the user will see a glitch. Recovering from that requires asking the client to provide a new wl_buffer of a different kind, which might take time. Or a very rude compositor would just send a protocol error, and then we'd get bug reports like the video player just disappears when I try to play (and ps. I have an old kernel that doesn't support importing whatever). I believe we must allow the compositor to test the wl_buffer before it is usable for the client. That is the reason for the roundtrippy design of the below proposal. A central allocator would solve these issues, by having everyone agree on the restrictions upfront, instead of working out which of the media decode engine, camera, GPU, or display controller is the lowest common denominator, and forcing all allocations through there. One such solution was discussed a while back WRT ION: https://lwn.net/Articles/565469/ See the 'possible solutions' part for a way for people to agree on restrictions wrt tiling, stride, contiguousness, etc. Hi, that's an excellent article. I didn't know that delayed allocation of dmabufs was not even possible yet, which would have allowed us to not think about importing failures and simply let the client fall back with ok, don't use dmabuf with this particular device then. hrm? I know of at least a couple drm drivers that defer allocation of backing pages.. What is the conclusion here? Wayland protocol does not need to consider import failures at all, and can simply punt those as protocol errors, which essentially kill the app if they ever happen? Do we need to wait for the central allocator in kernel to materialize before we can design the protocol? Is it simply too early to try to do it now? I do tend to think the ION/central-allocator is just substituting one problem for another. It doesn't really solve the problem of how different devices which don't actually know each other can decide on buffers that they can share. On an phone/tablet/etc you know up front when building the kernel what devices there are and in what uses-cases they will be used, etc. But that isn't really solving the more general case. Was the idea of dmabuf in-kernel constraint negotiation with delayed allocation rejected in favour of a central allocator? not really, that I know of. I still think we need to spiff out dma-mapping to better handle placement constraints. (Although still prefer format constraints to be a userspace topic.) pengutronix is doing some work in this area: http://elinux.org/images/b/b0/OSELAS.Presentation-DMABUF-migration.pdf BR, -R Will Intel, Nouveau and Radeon support the central allocator, or will it remain for ARM-related devices only? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 3/6] test: add a bunch of test for click behavior on touchpads
On Wed, Jun 11, 2014 at 10:48:07AM +0200, Hans de Goede wrote:
Hi,
On 06/11/2014 02:11 AM, Peter Hutterer wrote:
Mainly testing the behaviour when clicking during a tap or tap-n-drag. Adds
a
new feature to the litest system, Apple clickpads don't have software
buttons by default.
[...]
+START_TEST(touchpad_1fg_tap_n_drag_click)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ struct libinput_event *event;
+
+ litest_drain_events(dev-libinput);
+
+ /* one finger down, up, down, move, button click, finger up
+ - two button left event pairs, motion allowed */
+ litest_touch_down(dev, 0, 50, 50);
+ litest_touch_up(dev, 0);
+ litest_touch_down(dev, 0, 50, 50);
+ litest_touch_move_to(dev, 1, 50, 50, 80, 50, 5);
+
+ assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+
+ libinput_dispatch(li);
+ while (libinput_next_event_type(li) == LIBINPUT_EVENT_POINTER_MOTION) {
+ event = libinput_get_event(li);
+ libinput_event_destroy(event);
+ libinput_dispatch(li);
+ }
This test for a click + drag using double tapping, right, in that
case I would like to see an assert checking that there is at least
one LIBINPUT_EVENT_POINTER_MOTION event followed by the while consuming
any more LIBINPUT_EVENT_POINTER_MOTION events
good call, and it exposed a copy/paste error: litest_move_to in the patch
I sent out was for slot 1 so had no effect. Fixed, and the check for a
motion event is in now.
+
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+ assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_touch_up(dev, 0);
+
+ libinput_dispatch(li);
+
+ assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+
+ libinput_dispatch(li);
+
+ while (libinput_next_event_type(li) == LIBINPUT_EVENT_POINTER_MOTION) {
+ event = libinput_get_event(li);
+ libinput_event_destroy(event);
+ libinput_dispatch(li);
+ }
Is this really necessary, why would there be motion events after
the button up ?
dropped, thanks
Cheers,
Peter
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
START_TEST(touchpad_1fg_clickfinger)
{
struct litest_device *dev = litest_create_device(LITEST_BCM5974);
@@ -352,6 +525,13 @@ int main(int argc, char **argv) {
litest_add(touchpad:tap, touchpad_1fg_tap, LITEST_TOUCHPAD,
LITEST_ANY);
litest_add(touchpad:tap, touchpad_1fg_tap_n_drag, LITEST_TOUCHPAD,
LITEST_ANY);
litest_add(touchpad:tap, touchpad_2fg_tap, LITEST_TOUCHPAD,
LITEST_SINGLE_TOUCH);
+ litest_add(touchpad:tap, touchpad_1fg_tap_click, LITEST_TOUCHPAD,
LITEST_ANY);
+ litest_add(touchpad:tap, touchpad_2fg_tap_click, LITEST_TOUCHPAD,
LITEST_SINGLE_TOUCH|LITEST_APPLE_CLICKPAD);
+ litest_add(touchpad:tap, touchpad_2fg_tap_click_apple,
LITEST_APPLE_CLICKPAD, LITEST_ANY);
+ /* Real buttons don't interfere with tapping, so don't run those for
+ pads with buttons */
+ litest_add(touchpad:tap, touchpad_1fg_double_tap_click,
LITEST_CLICKPAD, LITEST_ANY);
+ litest_add(touchpad:tap, touchpad_1fg_tap_n_drag_click,
LITEST_CLICKPAD, LITEST_ANY);
litest_add_no_device(touchpad:clickfinger, touchpad_1fg_clickfinger);
litest_add_no_device(touchpad:clickfinger, touchpad_2fg_clickfinger);
Regards,
Hans
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/2] clients: Maximize window when double touch on title bar
Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
---
clients/window.c| 26 --
shared/cairo-util.h | 7 +++
shared/frame.c | 49 +
3 files changed, 80 insertions(+), 2 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 7c9c518..a608a84 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -363,6 +363,7 @@ struct window_frame {
uint32_t last_time;
uint32_t did_double, double_click;
+ int32_t last_id, double_id;
};
struct menu {
@@ -2380,7 +2381,23 @@ frame_touch_down_handler(struct widget *widget, struct
input *input,
{
struct window_frame *frame = data;
- frame_touch_down(frame-frame, input, id, x, y);
+ frame-double_click = 0;
+ if (time - frame-last_time = DOUBLE_CLICK_PERIOD
+ frame-last_id == id) {
+ frame-double_click = 1;
+ frame-did_double = 1;
+ frame-double_id = id;
+ } else
+ frame-did_double = 0;
+
+ frame-last_time = time;
+ frame-last_id = id;
+
+ if (frame-double_click)
+ frame_double_touch_down(frame-frame, input, id, x, y);
+ else
+ frame_touch_down(frame-frame, input, id, x, y);
+
frame_handle_status(frame, input, time, THEME_LOCATION_CLIENT_AREA);
}
@@ -2391,7 +2408,12 @@ frame_touch_up_handler(struct widget *widget,
{
struct window_frame *frame = data;
- frame_touch_up(frame-frame, input, id);
+ if (frame-double_id == id frame-did_double) {
+ frame-did_double = 0;
+ frame-double_id = 0;
+ frame_double_touch_up(frame-frame, input, id);
+ } else
+ frame_touch_up(frame-frame, input, id);
frame_handle_status(frame, input, time, THEME_LOCATION_CLIENT_AREA);
}
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 4e736ef..92f9e74 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -215,6 +215,13 @@ frame_double_click(struct frame *frame, void *pointer,
uint32_t button, enum frame_button_state state);
void
+frame_double_touch_down(struct frame *frame, void *data, int32_t id,
+ int x, int y);
+
+void
+frame_double_touch_up(struct frame *frame, void *data, int32_t id);
+
+void
frame_repaint(struct frame *frame, cairo_t *cr);
#endif
diff --git a/shared/frame.c b/shared/frame.c
index 768cc2e..774f499 100644
--- a/shared/frame.c
+++ b/shared/frame.c
@@ -868,6 +868,55 @@ frame_double_click(struct frame *frame, void *data,
}
void
+frame_double_touch_down(struct frame *frame, void *data, int32_t id,
+ int x, int y)
+{
+ struct frame_touch *touch = frame_touch_get(frame, data);
+ struct frame_button *button = frame_find_button(frame, x, y);
+ enum theme_location location;
+
+ if (touch button) {
+ touch-button = button;
+ frame_button_press(touch-button);
+ return;
+ }
+
+ location = theme_get_location(frame-theme, x, y,
+ frame-width, frame-height,
+ frame-flags FRAME_FLAG_MAXIMIZED ?
+ THEME_FRAME_MAXIMIZED : 0);
+
+ switch (location) {
+ case THEME_LOCATION_TITLEBAR:
+ frame-status |= FRAME_STATUS_MAXIMIZE;
+ break;
+ case THEME_LOCATION_RESIZING_TOP:
+ case THEME_LOCATION_RESIZING_BOTTOM:
+ case THEME_LOCATION_RESIZING_LEFT:
+ case THEME_LOCATION_RESIZING_RIGHT:
+ case THEME_LOCATION_RESIZING_TOP_LEFT:
+ case THEME_LOCATION_RESIZING_TOP_RIGHT:
+ case THEME_LOCATION_RESIZING_BOTTOM_LEFT:
+ case THEME_LOCATION_RESIZING_BOTTOM_RIGHT:
+ frame-status |= FRAME_STATUS_RESIZE;
+ break;
+ default:
+ break;
+ }
+}
+
+void
+frame_double_touch_up(struct frame *frame, void *data, int32_t id)
+{
+ struct frame_touch *touch = frame_touch_get(frame, data);
+
+ if (touch touch-button) {
+ frame_button_release(touch-button);
+ frame_touch_destroy(touch);
+ }
+}
+
+void
frame_repaint(struct frame *frame, cairo_t *cr)
{
struct frame_button *button;
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
