[PATCH libinput 3/8] Add libinput_device_suspend() and libinput_device_resume()
Does what it says on the box, preventing events from the device without actually
dropping the device from the context.
Signed-off-by: Peter Hutterer
---
See my notes in the coverletter. For the T440 case I specifically did not
mention that _suspend() closes the file descriptors.
src/evdev.c| 23 +++
src/evdev.h| 3 +++
src/libinput.c | 16
src/libinput.h | 45 +
4 files changed, 87 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index d4a4a07..78d9985 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1082,6 +1082,29 @@ evdev_device_suspend(struct evdev_device *device)
return 0;
}
+int
+evdev_device_resume(struct evdev_device *device)
+{
+ struct libinput *libinput = device->base.seat->libinput;
+ int fd;
+
+ if (device->fd != -1)
+ return 0;
+
+ fd = open_restricted(libinput, device->devnode, O_RDWR | O_NONBLOCK);
+
+ if (fd < 0)
+ return fd;
+
+ device->fd = fd;
+ device->source =
+ libinput_add_fd(libinput, fd, evdev_device_dispatch, device);
+ if (!device->source)
+ return -ENOMEM;
+
+ return 0;
+}
+
void
evdev_device_remove(struct evdev_device *device)
{
diff --git a/src/evdev.h b/src/evdev.h
index 05125b7..b4749b6 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -182,6 +182,9 @@ evdev_device_transform_y(struct evdev_device *device,
int
evdev_device_suspend(struct evdev_device *device);
+int
+evdev_device_resume(struct evdev_device *device);
+
void
evdev_keyboard_notify_key(struct evdev_device *device,
uint32_t time,
diff --git a/src/libinput.c b/src/libinput.c
index 90b6a13..d18d9b8 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1142,6 +1142,22 @@ libinput_suspend(struct libinput *libinput)
libinput->interface_backend->suspend(libinput);
}
+LIBINPUT_EXPORT int
+libinput_device_suspend(struct libinput_device *device)
+{
+ struct evdev_device *dev = (struct evdev_device*)device;
+
+ return evdev_device_suspend(dev);
+}
+
+LIBINPUT_EXPORT int
+libinput_device_resume(struct libinput_device *device)
+{
+ struct evdev_device *dev = (struct evdev_device*)device;
+
+ return evdev_device_resume(dev);
+}
+
LIBINPUT_EXPORT void
libinput_device_set_user_data(struct libinput_device *device, void *user_data)
{
diff --git a/src/libinput.h b/src/libinput.h
index 9296a35..338a08f 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -1226,6 +1226,51 @@ libinput_device_unref(struct libinput_device *device);
/**
* @ingroup device
*
+ * Suspend the device but do not remove the device from the context.
+ * Suspending a device stops the device from generating events until it is
+ * either resumed with libinput_device_resume() or removed from the context.
+ * Suspending a device does not generate a @ref
+ * LIBINPUT_EVENT_DEVICE_REMOVED event.
+ *
+ * Events already received and processed from this device are unaffected and
+ * will be passed to the caller on the next call to libinput_get_event().
+ * When the device is suspended, it may generate events to reset it into a
+ * neutral state (e.g. releasing currently pressed buttons).
+ *
+ * If the device is already suspended, this function does nothing.
+ *
+ * @param device A previously obtained device
+ * @return 0 on success or a negative errno on failure
+ *
+ * @see libinput_device_resume
+ */
+int
+libinput_device_suspend(struct libinput_device *device);
+
+/**
+ * @ingroup device
+ *
+ * Resume a previously suspended device. Events from this device will be
+ * processed in the next call of libinput_dispatch().
+ * Resuming a device does not generate a @ref LIBINPUT_EVENT_DEVICE_ADDED
+ * event.
+ *
+ * When the device is resumed, it may generate events to match the logical
+ * state with the current physical state of the device.
+ *
+ * If the device is not currently suspended, this function does nothing.
+ *
+ * @param device A previously suspended device
+ * @return 0 on success or a negative errno on failure
+ *
+ * @see libinput_device_suspend
+ */
+int
+libinput_device_resume(struct libinput_device *device);
+
+/**
+ * @ingroup device
+ *
* Set caller-specific data associated with this input device. libinput does
* not manage, look at, or modify this data. The caller must ensure the
* data is valid.
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 4/8] evdev: don't resume a removed device
A device may disappear and a new device may re-appear with the same device
node while the original device is suspended. Prevent a device resume to open
the wrong device.
In a path context, a changing syspath is the only indicator we get of the
device changing.
In a udev context, if the device was removed and libinput_dispatch() was
called, we can short-cut the syspath comparison by setting it to NULL.
Signed-off-by: Peter Hutterer
---
src/evdev.c | 48 +++-
src/evdev.h | 4 +++-
src/path.c | 9 ++---
src/udev-seat.c | 4 +++-
4 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 78d9985..74632c8 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -861,7 +861,8 @@ evdev_configure_device(struct evdev_device *device)
struct evdev_device *
evdev_device_create(struct libinput_seat *seat,
const char *devnode,
- const char *sysname)
+ const char *sysname,
+ const char *syspath)
{
struct libinput *libinput = seat->libinput;
struct evdev_device *device;
@@ -897,6 +898,7 @@ evdev_device_create(struct libinput_seat *seat,
device->mtdev = NULL;
device->devnode = strdup(devnode);
device->sysname = strdup(sysname);
+ device->syspath = strdup(syspath);
device->rel.dx = 0;
device->rel.dy = 0;
device->abs.seat_slot = -1;
@@ -1082,6 +1084,36 @@ evdev_device_suspend(struct evdev_device *device)
return 0;
}
+static int
+evdev_device_compare_syspath(struct evdev_device *device, int fd)
+{
+ struct udev *udev = NULL;
+ struct udev_device *udev_device = NULL;
+ const char *syspath;
+ struct stat st;
+ int rc = 1;
+
+ udev = udev_new();
+ if (!udev)
+ goto out;
+
+ if (fstat(fd, &st) < 0)
+ goto out;
+
+ udev_device = udev_device_new_from_devnum(udev, 'c', st.st_rdev);
+ if (!device)
+ goto out;
+
+ syspath = udev_device_get_syspath(udev_device);
+ rc = strcmp(syspath, device->syspath);
+out:
+ if (udev_device)
+ udev_device_unref(udev_device);
+ if (udev)
+ udev_unref(udev);
+ return rc;
+}
+
int
evdev_device_resume(struct evdev_device *device)
{
@@ -1091,11 +1123,19 @@ evdev_device_resume(struct evdev_device *device)
if (device->fd != -1)
return 0;
+ if (device->syspath == NULL)
+ return -ENODEV;
+
fd = open_restricted(libinput, device->devnode, O_RDWR | O_NONBLOCK);
if (fd < 0)
return fd;
+ if (evdev_device_compare_syspath(device, fd)) {
+ close_restricted(libinput, fd);
+ return -ENODEV;
+ }
+
device->fd = fd;
device->source =
libinput_add_fd(libinput, fd, evdev_device_dispatch, device);
@@ -1110,6 +1150,11 @@ evdev_device_remove(struct evdev_device *device)
{
evdev_device_suspend(device);
+ /* A device may be removed while suspended. Free the syspath to
+* skip re-opening a different device with the same node */
+ free(device->syspath);
+ device->syspath = NULL;
+
list_remove(&device->base.link);
notify_removed_device(&device->base);
@@ -1131,5 +1176,6 @@ evdev_device_destroy(struct evdev_device *device)
free(device->mt.slots);
free(device->devnode);
free(device->sysname);
+ free(device->syspath);
free(device);
}
diff --git a/src/evdev.h b/src/evdev.h
index b4749b6..55fae4c 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -63,6 +63,7 @@ struct evdev_device {
char *output_name;
char *devnode;
char *sysname;
+ char *syspath;
const char *devname;
int fd;
struct {
@@ -126,7 +127,8 @@ struct evdev_dispatch {
struct evdev_device *
evdev_device_create(struct libinput_seat *seat,
const char *devnode,
- const char *sysname);
+ const char *sysname,
+ const char *syspath);
struct evdev_dispatch *
evdev_touchpad_create(struct evdev_device *device);
diff --git a/src/path.c b/src/path.c
index e9c0ee8..3752751 100644
--- a/src/path.c
+++ b/src/path.c
@@ -112,6 +112,7 @@ path_seat_get_named(struct path_input *input,
static int
path_get_udev_properties(const char *path,
char **sysname,
+char **syspath,
char **seat_name,
char **seat_logical_name)
{
@@ -133,6 +134,7 @@ path_get_udev_properties(const char *path,
goto out;
*sysname = strdup(udev_device_get_sysname(device));
+ *syspath = strdup(udev_device_get_syspath(device));
seat = udev_device_get_property_value(device, "ID_SEAT");
*seat_name = strdup(seat
[PATCH libinput 6/8] evdev: drop the button count when releasing keys on remove
We only called this function before device removal, so failing to update the button state didn't matter. To make this function generic for the upcoming device suspend/resume, we need to keep track of the button/key count properly. Signed-off-by: Peter Hutterer --- src/evdev.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index 74632c8..6bbea92 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -1042,15 +1042,15 @@ release_pressed_keys(struct evdev_device *device) case EVDEV_KEY_TYPE_NONE: break; case EVDEV_KEY_TYPE_KEY: - keyboard_notify_key( - &device->base, + evdev_keyboard_notify_key( + device, time, code, LIBINPUT_KEY_STATE_RELEASED); break; case EVDEV_KEY_TYPE_BUTTON: - pointer_notify_button( - &device->base, + evdev_pointer_notify_button( + device, time, code, LIBINPUT_BUTTON_STATE_RELEASED); -- 1.9.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 7/8] evdev: ignore excessive releases of a button or key
When we're suspending a touchpad, several events triggered by timers may still
be waiting in the background. We still need to release all buttons/keys
immediately though so we get an uneven number of release events: one from
release_pressed_keys() and one when the timers expire and send the release
event through the normal channels.
Don't assert if we're already on a press-count of 0, simply ignore it and
discard the event.
Signed-off-by: Peter Hutterer
---
I'm not 100% sure on this one. It's the easy solution, but until we know the
general direction I didn't want to implement the full solution.
What's needed here are hooks for suspending/resuming in the dispatch structs
so that the touchpad code can cancel anything currently happening and reset
the state. For the normal fallback_dispatch the hooks can just release keys
and touches.
src/evdev.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 6bbea92..755e7a1 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -74,8 +74,10 @@ update_key_down_count(struct evdev_device *device, int code,
int pressed)
if (pressed) {
key_count = ++device->key_count[code];
} else {
- assert(device->key_count[code] > 0);
- key_count = --device->key_count[code];
+ if (device->key_count[code] > 0)
+ key_count = --device->key_count[code];
+ else
+ return -1;
}
if (key_count > 32) {
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 8/8] test: test for release events on device suspend
Signed-off-by: Peter Hutterer
---
test/device.c | 149 ++
1 file changed, 149 insertions(+)
diff --git a/test/device.c b/test/device.c
index 25e119e..2367fd6 100644
--- a/test/device.c
+++ b/test/device.c
@@ -30,6 +30,7 @@
#include
#include "litest.h"
+#include "libinput-util.h"
static int open_restricted(const char *path, int flags, void *data)
{
@@ -238,6 +239,151 @@ START_TEST(device_resume_invalid_device_removed)
}
END_TEST
+START_TEST(device_suspend_release_buttons)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev->libinput;
+ struct libinput_device *device;
+ struct libinput_event *event;
+ struct libinput_event_pointer *ptrevent;
+
+ device = dev->libinput_device;
+
+ litest_button_click(dev, BTN_LEFT, true);
+ litest_drain_events(li);
+ litest_assert_empty_queue(li);
+
+ libinput_device_suspend(device);
+
+ libinput_dispatch(li);
+ while ((event = libinput_get_event(li)) == NULL)
+ libinput_dispatch(li);
+
+ ck_assert_int_eq(libinput_event_get_type(event),
+LIBINPUT_EVENT_POINTER_BUTTON);
+ ptrevent = libinput_event_get_pointer_event(event);
+ ck_assert_int_eq(libinput_event_pointer_get_button(ptrevent),
+BTN_LEFT);
+ ck_assert_int_eq(libinput_event_pointer_get_button_state(ptrevent),
+LIBINPUT_BUTTON_STATE_RELEASED);
+
+ libinput_event_destroy(event);
+ litest_assert_empty_queue(li);
+
+ /* double-suspend for good measure, make sure we don't get
+* the button events again */
+ libinput_device_suspend(device);
+ libinput_dispatch(li);
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(device_suspend_release_keys)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev->libinput;
+ struct libinput_device *device;
+ struct libinput_event *event;
+ struct libinput_event_keyboard *kbdevent;
+
+ device = dev->libinput_device;
+
+ litest_button_click(dev, KEY_A, true);
+ litest_drain_events(li);
+ litest_assert_empty_queue(li);
+
+ libinput_device_suspend(device);
+
+ libinput_dispatch(li);
+ while ((event = libinput_get_event(li)) == NULL)
+ libinput_dispatch(li);
+
+ ck_assert_int_eq(libinput_event_get_type(event),
+LIBINPUT_EVENT_KEYBOARD_KEY);
+ kbdevent = libinput_event_get_keyboard_event(event);
+ ck_assert_int_eq(libinput_event_keyboard_get_key(kbdevent),
+KEY_A);
+ ck_assert_int_eq(libinput_event_keyboard_get_key_state(kbdevent),
+LIBINPUT_KEY_STATE_RELEASED);
+
+ libinput_event_destroy(event);
+ litest_assert_empty_queue(li);
+
+ /* double-suspend for good measure, make sure we don't get
+* the key events again */
+ libinput_device_suspend(device);
+ libinput_dispatch(li);
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(device_suspend_release_tap)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev->libinput;
+ struct libinput_device *device;
+ struct libinput_event *event;
+ struct libinput_event_pointer *ptrevent;
+
+ device = dev->libinput_device;
+
+ libinput_device_config_tap_set_enabled(device,
+ LIBINPUT_CONFIG_TAP_ENABLED);
+
+ litest_drain_events(li);
+
+ litest_touch_down(dev, 0, 50, 50);
+ litest_touch_up(dev, 0);
+
+ libinput_dispatch(li);
+
+ libinput_device_suspend(device);
+ /* tap happened before suspending, so we still expect the event */
+
+ msleep(300); /* tap-n-drag timeout */
+
+ libinput_dispatch(li);
+ while ((event = libinput_get_event(li)) == NULL)
+ libinput_dispatch(li);
+
+ ck_assert_int_eq(libinput_event_get_type(event),
+LIBINPUT_EVENT_POINTER_BUTTON);
+ ptrevent = libinput_event_get_pointer_event(event);
+ ck_assert_int_eq(libinput_event_pointer_get_button(ptrevent),
+BTN_LEFT);
+ ck_assert_int_eq(libinput_event_pointer_get_button_state(ptrevent),
+LIBINPUT_BUTTON_STATE_PRESSED);
+
+ libinput_event_destroy(event);
+
+ while ((event = libinput_get_event(li)) == NULL)
+ libinput_dispatch(li);
+
+ ck_assert_int_eq(libinput_event_get_type(event),
+LIBINPUT_EVENT_POINTER_BUTTON);
+ ptrevent = libinput_event_get_pointer_event(event);
+ ck_assert_int_eq(libinput_event_pointer_get_button(ptrevent),
+BTN_LEFT);
+ ck_assert_int_eq(libinput_event_pointer_get_button_state(ptrevent),
+
[PATCH libinput 5/8] test: add test for device suspend/resume
Signed-off-by: Peter Hutterer
---
test/Makefile.am | 7 +-
test/device.c| 250 +++
2 files changed, 256 insertions(+), 1 deletion(-)
create mode 100644 test/device.c
diff --git a/test/Makefile.am b/test/Makefile.am
index 76d4e8c..4602f9f 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -34,7 +34,8 @@ run_tests = \
test-log \
test-touchpad \
test-misc \
- test-keyboard
+ test-keyboard \
+ test-device
build_tests = \
test-build-cxx \
test-build-linker \
@@ -78,6 +79,10 @@ test_keyboard_SOURCES = keyboard.c
test_keyboard_LDADD = $(TEST_LIBS)
test_keyboard_LDFLAGS = -no-install
+test_device_SOURCES = device.c
+test_device_LDADD = $(TEST_LIBS)
+test_device_LDFLAGS = -no-install
+
# build-test only
test_build_pedantic_c99_SOURCES = build-pedantic.c
test_build_pedantic_c99_CFLAGS = -std=c99 -pedantic -Werror
diff --git a/test/device.c b/test/device.c
new file mode 100644
index 000..25e119e
--- /dev/null
+++ b/test/device.c
@@ -0,0 +1,250 @@
+/*
+ * 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.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "litest.h"
+
+static int open_restricted(const char *path, int flags, void *data)
+{
+ int fd;
+ fd = open(path, flags);
+ return fd < 0 ? -errno : fd;
+}
+static void close_restricted(int fd, void *data)
+{
+ close(fd);
+}
+
+const struct libinput_interface simple_interface = {
+ .open_restricted = open_restricted,
+ .close_restricted = close_restricted,
+};
+
+
+START_TEST(device_suspend)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev->libinput;
+ struct libinput_device *device;
+
+ device = dev->libinput_device;
+
+ litest_drain_events(li);
+
+ /* no event from suspending */
+ libinput_device_suspend(device);
+ litest_assert_empty_queue(li);
+
+ /* no event from suspended device */
+ litest_event(dev, EV_REL, REL_X, 10);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_assert_empty_queue(li);
+
+ /* no event from resuming */
+ libinput_device_resume(device);
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(device_double_suspend)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev->libinput;
+ struct libinput_device *device;
+
+ device = dev->libinput_device;
+
+ litest_drain_events(li);
+
+ libinput_device_suspend(device);
+ libinput_device_suspend(device);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(device_double_resume)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev->libinput;
+ struct libinput_device *device;
+
+ device = dev->libinput_device;
+
+ litest_drain_events(li);
+
+ libinput_device_suspend(device);
+ libinput_device_resume(device);
+ libinput_device_resume(device);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(device_resume_invalid_syspath_changed)
+{
+ struct libinput *li;
+ struct libinput_device *device;
+ struct libevdev *evdev;
+ struct libevdev_uinput *uinput;
+ int rc;
+ char *devnode;
+
+ evdev = libevdev_new();
+ ck_assert_notnull(evdev);
+
+ libevdev_set_name(evdev, "litest device");
+ libevdev_enable_event_code(evdev, EV_KEY, BTN_LEFT, NULL);
+ libevdev_enable_event_code(evdev, EV_KEY, BTN_RIGHT, NULL);
+ libevdev_enable_event_code(evdev, EV_REL, REL_X, NULL);
+ libevdev_enable_event_code(evdev, EV_REL, REL_Y, NULL);
+
+ rc = libevdev_uinput_create_from_device(evdev,
+
[PATCH libinput 2/8] evdev: prevent double-suspending a device
Signed-off-by: Peter Hutterer
---
Could be merged with 1/8, but two patches for easier review.
src/evdev.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 8b154a3..d4a4a07 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1061,16 +1061,23 @@ release_pressed_keys(struct evdev_device *device)
int
evdev_device_suspend(struct evdev_device *device)
{
- if (device->source)
+ if (device->source) {
libinput_remove_source(device->base.seat->libinput,
device->source);
+ device->source = NULL;
+ }
release_pressed_keys(device);
- if (device->mtdev)
+ if (device->mtdev) {
mtdev_close_delete(device->mtdev);
- close_restricted(device->base.seat->libinput, device->fd);
- device->fd = -1;
+ device->mtdev = NULL;
+ }
+
+ if (device->fd != -1) {
+ close_restricted(device->base.seat->libinput, device->fd);
+ device->fd = -1;
+ }
return 0;
}
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 1/8] evdev: factor out closing a device into evdev_suspend()
No functional changes, just prep work for an upcoming patch
Signed-off-by: Peter Hutterer
---
src/evdev.c | 13 +++--
src/evdev.h | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index b9f635d..8b154a3 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1058,8 +1058,8 @@ release_pressed_keys(struct evdev_device *device)
}
}
-void
-evdev_device_remove(struct evdev_device *device)
+int
+evdev_device_suspend(struct evdev_device *device)
{
if (device->source)
libinput_remove_source(device->base.seat->libinput,
@@ -1071,6 +1071,15 @@ evdev_device_remove(struct evdev_device *device)
mtdev_close_delete(device->mtdev);
close_restricted(device->base.seat->libinput, device->fd);
device->fd = -1;
+
+ return 0;
+}
+
+void
+evdev_device_remove(struct evdev_device *device)
+{
+ evdev_device_suspend(device);
+
list_remove(&device->base.link);
notify_removed_device(&device->base);
diff --git a/src/evdev.h b/src/evdev.h
index f1ccdc2..05125b7 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -179,6 +179,8 @@ double
evdev_device_transform_y(struct evdev_device *device,
double y,
uint32_t height);
+int
+evdev_device_suspend(struct evdev_device *device);
void
evdev_keyboard_notify_key(struct evdev_device *device,
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 0/8] Add libinput_device_suspend() to disable devices
This patchset adds two new API hooks, libinput_device_suspend() and libinput_device_resume() which do what it says on the box. No special event is sent when suspending or resuming, so this is really the hook to ignore a specific device. The main idea here is two-fold: some devices simply shouldn't send events, in which case suspending them means fewer wakeup calls. The other use-case is touchpads. GNOME and other DE's provide hooks to disable the touchpad altogether - suspending it achieves that. Now, there are some issues that we should discuss: * the touchpad use-case seems to be mainly caused by bad palm detection in the synaptics driver. Presumably having near-perfect palm detection would remove the need for that toggle (except on the devices that have that magic "disable touchpad button" on the touchpad itself). So there's an argument that we don't necessarily need this, but I don't know yet how good palm detection can be. * the second problem: I don't think we provide enough information to callers to identify which device we don't need. Short of name matching there is no way currently to a touchpad before disabling it. Same goes for identifying any other device we don't care about. To allow that, we'd need some sort of device identification system beyond simple capabilities. * the third problem: the T440s. Users want to disable the touchpad but allow the top software buttons need to continue to work. That would be fairly trivial to implement in libinput, but we'd have to send the top software buttons through the trackstick device. And to be consistent here, we'd have to do that in the non-suspended state too, which opens a can of worms. discuss, because I'm rather stuck now. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] test: avoid erroneous devices to be passed into the test suites
The litest features overlap with the litest device specifiers, so it's easy to
pass in LITEST_MOUSE where LITEST_POINTER should be passed in, and vice versa.
Lacking proper type checking the best we can do here is simply move the
devices into the negative range and check for that.
Signed-off-by: Peter Hutterer
---
test/litest.c | 5 +
test/litest.h | 18 +-
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/test/litest.c b/test/litest.c
index 00db464..0341e9a 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -157,6 +157,9 @@ litest_add_tcase(struct suite *suite, void *func,
{
struct litest_test_device **dev = devices;
+ assert(required >= LITEST_DISABLE_DEVICE);
+ assert(excluded >= LITEST_DISABLE_DEVICE);
+
if (required == LITEST_DISABLE_DEVICE &&
excluded == LITEST_DISABLE_DEVICE) {
litest_add_tcase_no_device(suite, func);
@@ -221,6 +224,8 @@ litest_add_for_device(const char *name,
struct suite *s;
struct litest_test_device **dev = devices;
+ assert(type < LITEST_NO_DEVICE);
+
s = get_suite(name);
while (*dev) {
if ((*dev)->type == type) {
diff --git a/test/litest.h b/test/litest.h
index 2dcb7b2..aac71e4 100644
--- a/test/litest.h
+++ b/test/litest.h
@@ -35,15 +35,15 @@
enum litest_device_type {
LITEST_NO_DEVICE = -1,
- LITEST_SYNAPTICS_CLICKPAD,
- LITEST_SYNAPTICS_TOUCHPAD,
- LITEST_SYNAPTICS_TOPBUTTONPAD,
- LITEST_BCM5974,
- LITEST_KEYBOARD,
- LITEST_TRACKPOINT,
- LITEST_MOUSE,
- LITEST_WACOM_TOUCH,
- LITEST_ALPS_SEMI_MT,
+ LITEST_SYNAPTICS_CLICKPAD = -2,
+ LITEST_SYNAPTICS_TOUCHPAD = -3,
+ LITEST_SYNAPTICS_TOPBUTTONPAD = -4,
+ LITEST_BCM5974 = -5,
+ LITEST_KEYBOARD = -6,
+ LITEST_TRACKPOINT = -7,
+ LITEST_MOUSE = -8,
+ LITEST_WACOM_TOUCH = -9,
+ LITEST_ALPS_SEMI_MT = -10,
};
enum litest_device_feature {
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH V2 3/3] image: don't print redundant error
This error is printed by load_image() now
---
clients/image.c |1 -
1 file changed, 1 deletion(-)
diff --git a/clients/image.c b/clients/image.c
index 573117c..aee8112 100644
--- a/clients/image.c
+++ b/clients/image.c
@@ -373,7 +373,6 @@ image_create(struct display *display, const char *filename,
image->image = load_cairo_surface(filename);
if (!image->image) {
- fprintf(stderr, "could not find the image %s!\n", b);
free(image->filename);
free(image);
return NULL;
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH V2] fixes to parse_options, help info
This replaces the two unpushed patches from my previous set. Includes changes based on Pekka's comments: Removed merging of 1-letter boolean switches Fixed the error message for image files less than 4 bytes long Style fixes. Split patch for library from patch to demo program. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH V2 2/3] load_image: always print a message on failure if filename is not empty
It was rather inconsistent before. This may help users figure out why
backgrounds and icons don't show up. A better api where the error can
be queried might be nice, but this seems sufficient for current Weston use.
---
shared/image-loader.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/shared/image-loader.c b/shared/image-loader.c
index 35dadd3..0d04b03 100644
--- a/shared/image-loader.c
+++ b/shared/image-loader.c
@@ -23,6 +23,7 @@
#include "config.h"
+#include
#include
#include
#include
@@ -374,12 +375,18 @@ load_image(const char *filename)
FILE *fp;
unsigned int i;
+ if (!filename || !*filename)
+ return NULL;
+
fp = fopen(filename, "rb");
- if (fp == NULL)
+ if (!fp) {
+ fprintf(stderr, "%s: %s\n", filename, strerror(errno));
return NULL;
+ }
if (fread(header, sizeof header, 1, fp) != 1) {
fclose(fp);
+ fprintf(stderr, "%s: unable to read file header\n", filename);
return NULL;
}
@@ -395,10 +402,13 @@ load_image(const char *filename)
fclose(fp);
if (i == ARRAY_LENGTH(loaders)) {
- fprintf(stderr, "unrecognized file header for %s: "
+ fprintf(stderr, "%s: unrecognized file header "
"0x%02x 0x%02x 0x%02x 0x%02x\n",
filename, header[0], header[1], header[2], header[3]);
image = NULL;
+ } else if (!image) {
+ /* load probably printed something, but just in case */
+ fprintf(stderr, "%s: error reading image\n", filename);
}
return image;
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH V2 1/3] parse_options: fail on more malformed options
Fail on trailing text after numbers, such as --width=100mm
Fail on any text after booleans, such as --flag=false
Also fixed reading of memory after the null terminator of a long
option with no = sign in it.
---
shared/option-parser.c | 89 +---
1 file changed, 61 insertions(+), 28 deletions(-)
diff --git a/shared/option-parser.c b/shared/option-parser.c
index c00349a..b8e7394 100644
--- a/shared/option-parser.c
+++ b/shared/option-parser.c
@@ -30,53 +30,86 @@
#include "config-parser.h"
-static void
+static int
handle_option(const struct weston_option *option, char *value)
{
+ char* p;
+
switch (option->type) {
case WESTON_OPTION_INTEGER:
- * (int32_t *) option->data = strtol(value, NULL, 0);
- return;
+ * (int32_t *) option->data = strtol(value, &p, 0);
+ return *value && !*p;
case WESTON_OPTION_UNSIGNED_INTEGER:
- * (uint32_t *) option->data = strtoul(value, NULL, 0);
- return;
+ * (uint32_t *) option->data = strtoul(value, &p, 0);
+ return *value && !*p;
case WESTON_OPTION_STRING:
* (char **) option->data = strdup(value);
- return;
- case WESTON_OPTION_BOOLEAN:
- * (int32_t *) option->data = 1;
- return;
+ return 1;
default:
assert(0);
}
}
+static int
+long_option(const struct weston_option *options, int count, char* arg)
+{
+ int k, len;
+
+ for (k = 0; k < count; k++) {
+ if (!options[k].name)
+ continue;
+ len = strlen(options[k].name);
+ if (strncmp(options[k].name, arg + 2, len) != 0)
+ continue;
+ if (options[k].type == WESTON_OPTION_BOOLEAN) {
+ if (!arg[len + 2]) {
+ * (int32_t *) options[k].data = 1;
+ return 1;
+ }
+ } else if (arg[len+2] == '=') {
+ return handle_option(options + k, arg + len + 3);
+ }
+ }
+ return 0;
+}
+
+static int
+short_option(const struct weston_option *options, int count, char* arg)
+{
+ int k;
+
+ if (!arg[1])
+ return 0;
+ for (k = 0; k < count; k++) {
+ if (options[k].short_name != arg[1])
+ continue;
+ if (options[k].type == WESTON_OPTION_BOOLEAN) {
+ if (!arg[2]) {
+ * (int32_t *) options[k].data = 1;
+ return 1;
+ }
+ } else {
+ return handle_option(options + k, arg + 2);
+ }
+ }
+ return 0;
+}
+
int
parse_options(const struct weston_option *options,
int count, int *argc, char *argv[])
{
- int i, j, k, len = 0;
+ int i, j;
for (i = 1, j = 1; i < *argc; i++) {
- for (k = 0; k < count; k++) {
- if (options[k].name)
- len = strlen(options[k].name);
- if (options[k].name &&
- argv[i][0] == '-' &&
- argv[i][1] == '-' &&
- strncmp(options[k].name, &argv[i][2], len) == 0 &&
- (argv[i][len + 2] == '=' || argv[i][len + 2] ==
'\0')) {
- handle_option(&options[k], &argv[i][len + 3]);
- break;
- } else if (options[k].short_name &&
- argv[i][0] == '-' &&
- options[k].short_name == argv[i][1]) {
- handle_option(&options[k], &argv[i][2]);
- break;
- }
+ if (argv[i][0] == '-') {
+ if (argv[i][1] == '-') {
+ if (long_option(options, count, argv[i]))
+ continue;
+ } else if (short_option(options, count, argv[i]))
+ continue;
}
- if (k == count)
- argv[j++] = argv[i];
+ argv[j++] = argv[i];
}
argv[j] = NULL;
*argc = j;
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: allow weird multitouch device without slots
On Tue, Aug 19, 2014 at 06:44:25PM +0300, Leonid Borisenko wrote: > 2014-08-19 10:02 GMT+03:00 Peter Hutterer : > > > On Tue, Aug 19, 2014 at 06:29:40AM +0300, Leonid Borisenko wrote: > > > HID device 'USB HID v1.11 Mouse' provided by Microsoft Wireless Optical > > > Desktop=C2=AE 2.20 (connected to USB and identified as vendor 0x45e, pr= > oduct > > > 0xe3, version 0x111) is reported as supporting EV_ABS event with > > ABS_MT_SLOT > > > code, but nevertheless libevdev_get_num_slots returns -1. > > > > yeah, that's intentional. libevdev detects those devices (through > > guesswork, > > but still...) and returns -1 as slot number. > > > > > Furthermore, all connected devices (mouse and keyboard) don't produce a= > ny > > > EV_ABS events for that HID Mouse device in tests with evtest. > > > > > > Before this fix mouse didn't work in Weston (but worked in X.Org). > > > > > > As partially explained by LKML message [1] (Message-Id [2]): > > > > > > The root of the problem comes from hid-input, which maps unknown ax= > is > > > to ABS_MISC. However, when an event code is already in use, hid-inp= > ut > > > uses the one after, leading to uses of ABS_MISC + N, where N is the > > > number of unknown axis. > > > > > > We are encountering a problem with the multitouch protocol here > > because > > > if a device has more than 7 unknown axis (which is the case for the > > PS3 > > > Sixaxis controller), then the unknown axis get maps to ABS_MT_SLOT > > and > > > beyond. > > > > > > [1] https://lkml.org/lkml/2013/11/20/515 > > > [2] 1384983141-31019-1-git-send-email-benjamin.tissoi...@redhat.com > > > > > > [...] > > > > so, as I said above the libevdev behaviour is intentional and our > > indicator > > that this isn't a MT device after all. We should integrate that knowledge > > better so that we don't label a device as touch device when it isn't, and > > so > > that we process events from those axes as normal ABS events instead of MT > > events. > > Unfortunately, my device (that Wireless Optical Desktop) doesn't produce > any events with the questionable codes, so if I would try to change > libinput behavior for these events to produce visible reaction, I'll not be > able to test changes for sanity. look at all the stuff in test/, it's fairly trivial to add your device (look at litest-synaptics.c for example) and send events for any axis using litest_event() or directly with libevdev_uinput_write_event(). plus, having a test makes sure we don't accidentally break things in the future. > I understand that my patch isn't general enough. It fixes my problem. > though, making mouse working in Weston. Current libinput code isn't > forgiving enough in handling of similar devices, so it cripples experience. > I'm not complaining, it's v0.5, so missing functionality is acceptable, but > it's frustrating. > > I will file a bug report in hope that someone will propose more general fix= You're pretty close with your fix already. In evdev_configure_device, check for ABS_MT_SLOT and libevdev_get_num_slots() before setting device->is_mt. If the number of slots is -1, don't set the mt flags and that's 80% of the effort. so it's mostly just a bit of reshuffling. > As a sidenote, cited LKML message says that "the axis currently mapped on > ABS_MT_SLOT is a special case in the kernel, > and it is not updated", so I think processing axes as normal ABS events > will not work for the axis reported as ABS_MT_SLOT. yeah, that's fine. but we should still handle all other axes correctly then. at the very least, we should make sure that we don't crash if that happens. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 2/2] Don't protect xkb_*_unref from NULL
Since xkbcommon-0.3.0, which is required by weston, a NULL argument
doesn't do anything.
Signed-off-by: Ran Benita
---
src/compositor-wayland.c | 3 +--
src/compositor-x11.c | 3 +--
src/input.c | 9 +++--
src/screen-share.c | 3 +--
4 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 57e850f..5f73c78 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1464,8 +1464,7 @@ input_handle_keymap(void *data, struct wl_keyboard
*keyboard, uint32_t format,
else
weston_seat_init_keyboard(&input->base, keymap);
- if (keymap)
- xkb_keymap_unref(keymap);
+ xkb_keymap_unref(keymap);
return;
diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 984d799..3494e34 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -322,8 +322,7 @@ x11_input_create(struct x11_compositor *c, int no_input)
keymap = x11_compositor_get_keymap(c);
if (weston_seat_init_keyboard(&c->core_seat, keymap) < 0)
return -1;
- if (keymap)
- xkb_keymap_unref(keymap);
+ xkb_keymap_unref(keymap);
x11_compositor_setup_xkb(c);
diff --git a/src/input.c b/src/input.c
index 2130789..975cd77 100644
--- a/src/input.c
+++ b/src/input.c
@@ -544,12 +544,10 @@ weston_keyboard_destroy(struct weston_keyboard *keyboard)
#ifdef ENABLE_XKBCOMMON
if (keyboard->seat->compositor->use_xkbcommon) {
- if (keyboard->xkb_state.state != NULL)
- xkb_state_unref(keyboard->xkb_state.state);
+ xkb_state_unref(keyboard->xkb_state.state);
if (keyboard->xkb_info)
weston_xkb_info_destroy(keyboard->xkb_info);
- if (keyboard->pending_keymap)
- xkb_keymap_unref(keyboard->pending_keymap);
+ xkb_keymap_unref(keyboard->pending_keymap);
}
#endif
@@ -1869,8 +1867,7 @@ weston_xkb_info_destroy(struct weston_xkb_info *xkb_info)
if (--xkb_info->ref_count > 0)
return;
- if (xkb_info->keymap)
- xkb_keymap_unref(xkb_info->keymap);
+ xkb_keymap_unref(xkb_info->keymap);
if (xkb_info->keymap_area)
munmap(xkb_info->keymap_area, xkb_info->keymap_size);
diff --git a/src/screen-share.c b/src/screen-share.c
index 9e81ef9..524a0ca 100644
--- a/src/screen-share.c
+++ b/src/screen-share.c
@@ -214,8 +214,7 @@ ss_seat_handle_keymap(void *data, struct wl_keyboard
*keyboard,
else
weston_seat_init_keyboard(&seat->base, keymap);
- if (keymap)
- xkb_keymap_unref(keymap);
+ xkb_keymap_unref(keymap);
return;
--
2.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 1/2] Replace deprecated xkbcommon symbols with current names
These symbols (xkb_map_* and others) were replaced in xkbcommon with more
consistent names. See the header xkbcommon/xkbcommon-compat.h for how
the old names map to the new.
The new names have been available since the first stable xkbcommon
release (0.2.0).
Signed-off-by: Ran Benita
---
clients/weston-simple-im.c | 22
clients/window.c | 24 -
src/compositor-wayland.c | 10 +++
src/compositor-x11.c | 4 +--
src/input.c| 66 --
src/screen-share.c | 10 +++
6 files changed, 70 insertions(+), 66 deletions(-)
diff --git a/clients/weston-simple-im.c b/clients/weston-simple-im.c
index ded6a04..787782f 100644
--- a/clients/weston-simple-im.c
+++ b/clients/weston-simple-im.c
@@ -187,10 +187,10 @@ input_method_keyboard_keymap(void *data,
}
keyboard->keymap =
- xkb_map_new_from_string(keyboard->xkb_context,
- map_str,
- XKB_KEYMAP_FORMAT_TEXT_V1,
- 0);
+ xkb_keymap_new_from_string(keyboard->xkb_context,
+ map_str,
+ XKB_KEYMAP_FORMAT_TEXT_V1,
+ 0);
munmap(map_str, size);
close(fd);
@@ -203,16 +203,16 @@ input_method_keyboard_keymap(void *data,
keyboard->state = xkb_state_new(keyboard->keymap);
if (!keyboard->state) {
fprintf(stderr, "failed to create XKB state\n");
- xkb_map_unref(keyboard->keymap);
+ xkb_keymap_unref(keyboard->keymap);
return;
}
keyboard->control_mask =
- 1 << xkb_map_mod_get_index(keyboard->keymap, "Control");
+ 1 << xkb_keymap_mod_get_index(keyboard->keymap, "Control");
keyboard->alt_mask =
- 1 << xkb_map_mod_get_index(keyboard->keymap, "Mod1");
+ 1 << xkb_keymap_mod_get_index(keyboard->keymap, "Mod1");
keyboard->shift_mask =
- 1 << xkb_map_mod_get_index(keyboard->keymap, "Shift");
+ 1 << xkb_keymap_mod_get_index(keyboard->keymap, "Shift");
}
static void
@@ -234,7 +234,7 @@ input_method_keyboard_key(void *data,
return;
code = key + 8;
- num_syms = xkb_key_get_syms(keyboard->state, code, &syms);
+ num_syms = xkb_state_key_get_syms(keyboard->state, code, &syms);
sym = XKB_KEY_NoSymbol;
if (num_syms == 1)
@@ -261,8 +261,8 @@ input_method_keyboard_modifiers(void *data,
xkb_state_update_mask(keyboard->state, mods_depressed,
mods_latched, mods_locked, 0, 0, group);
mask = xkb_state_serialize_mods(keyboard->state,
- XKB_STATE_DEPRESSED |
- XKB_STATE_LATCHED);
+ XKB_STATE_MODS_DEPRESSED |
+ XKB_STATE_MODS_LATCHED);
keyboard->modifiers = 0;
if (mask & keyboard->control_mask)
diff --git a/clients/window.c b/clients/window.c
index a8bc260..90f45d3 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2749,10 +2749,10 @@ keyboard_handle_keymap(void *data, struct wl_keyboard
*keyboard,
return;
}
- keymap = xkb_map_new_from_string(input->display->xkb_context,
-map_str,
-XKB_KEYMAP_FORMAT_TEXT_V1,
-0);
+ keymap = xkb_keymap_new_from_string(input->display->xkb_context,
+ map_str,
+ XKB_KEYMAP_FORMAT_TEXT_V1,
+ 0);
munmap(map_str, size);
close(fd);
@@ -2764,7 +2764,7 @@ keyboard_handle_keymap(void *data, struct wl_keyboard
*keyboard,
state = xkb_state_new(keymap);
if (!state) {
fprintf(stderr, "failed to create XKB state\n");
- xkb_map_unref(keymap);
+ xkb_keymap_unref(keymap);
return;
}
@@ -2774,11 +2774,11 @@ keyboard_handle_keymap(void *data, struct wl_keyboard
*keyboard,
input->xkb.state = state;
input->xkb.control_mask =
- 1 << xkb_map_mod_get_index(input->xkb.keymap, "Control");
+ 1 << xkb_keymap_mod_get_index(input->xkb.keymap, "Control");
input->xkb.alt_mask =
- 1 << xkb_map_mod_get_index(input->xkb.keymap, "Mod1");
+ 1 << xkb_keymap_mod_get_index(input->xkb.keymap, "Mod1");
input->xkb.shift_mask =
- 1 << xkb_map_mod_get_index(input->xkb.keymap, "Shift");
+ 1 << xkb_keymap_mod_get_index(input->xkb.keymap, "Shift");
Re: [PATCH wayland v2] protocol: define the concept of wl_surface role
On 08/19/2014 12:29 AM, Pekka Paalanen wrote: + Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. Destroying the last protocol object for the role does not remove the role, correct? The client can recreate a new protocol object for that role and it still works? + Losing a role means losing all the role-specific state. I'm not sure what you are saying here. I think maybe you are talking about a surface that was used for drag & drop when the drag & drop ends? I thought in that case the surface must be destroyed: ie once a surface "loses a role" it cannot be assigned any role, including the same one. But in that case the "state" is irrelevant. Are you allowed to reuse the drag & drop surface for another drag & drop? If the creation request also sets some state it is obvious that portion of the state is not preserved. But it seems a lot easier on both clients and compositors if other state is allowed to be preserved. In any case I find this sentence really confusing. Also it might help if there was a concrete example of a surface "losing a role". ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] weston.ini.man: Add libinput section
Signed-off-by: Jonas Ådahl --- man/weston.ini.man | 14 ++ 1 file changed, 14 insertions(+) diff --git a/man/weston.ini.man b/man/weston.ini.man index fbcec81..4be752b 100644 --- a/man/weston.ini.man +++ b/man/weston.ini.man @@ -70,6 +70,7 @@ The section headers are: .RS 4 .nf .BR "core " "The core modules" +.BR "libinput " "Input device configuration" .BR "shell " "Desktop customization" .BR "launcher " "Add launcher to the panel" .BR "screensaver" "Screensaver selection" @@ -144,6 +145,19 @@ By default, xrgb is used. .RS .PP +.SH "LIBINPUT SECTION" +The +.B libinput +section is used to configure input devices when using the libinput input device +backend. +.PP +Available configuration are: +.TP 7 +.BI "enable_tap=" true +enables tap to click on touchpad devices +.RS +.PP + .SH "SHELL SECTION" The .B shell -- 1.8.5.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 01/12] Fixes to parse_options
On 08/19/2014 02:18 AM, Pekka Paalanen wrote: Multiple single-letter booleans in one switch allowed, ie -xyz is the same as -x -y -z. For wayland modules they all have to belong to the same module. This was not accepted before, right? It is confusing that one needs to know that they are from the same module, so I'd rather just not accept combined single letter booleans at all. It may have been suggested by somebody else? And then rejected? I'll remove this, it's not a big deal. Previous version could use text after the null at the end of an argv entry. Now requires the = sign. What does this mean? I mean, how could one have ever used the old behaviour? Nothing comes to my mind, so I suppose that is ok. The old code basically did *(string+strlen(string)+1) if the string did not have an = sign in it, passing that pointer to the argument parser. Probably this always fails parsing without a segfault but technically it is wrong, it could segfault, or it could get some text at that point that actually parses, producing an unexpected value. There are some style issues. First is the patch subject, it should be prefixed with the component the patch is touching. To get a feeling what the components are, look at the git-log of the file your are changing, and there should be a pattern. I see, there is a "name:" at the start of the description line. I missed that, I was only adding the git repository if it was not weston to [PATCH repository]. Also looks like things like V2 should be between the square brackets. Though, I see that option-parser.c doesn't really have any pattern. Oh well, "shared:" should do then. Or the demo programs, or startup. More style issues below. Will try to address these. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] evdev: turn off all the leds at startup
the internal state in xkbcommon is off for all the three leds, so
make them be in sync.
---
src/evdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/evdev.c b/src/evdev.c
index 888dfbd..a46ed87 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -581,6 +581,7 @@ evdev_configure_device(struct evdev_device *device)
device->seat_caps |= EVDEV_SEAT_KEYBOARD;
weston_log("input device %s, %s is a keyboard\n",
device->devname, device->devnode);
+ evdev_led_update(device, 0);
}
if (has_touch && !has_button) {
weston_seat_init_touch(device->seat);
--
2.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/2] compositor: add a way to change the keyboard leds
This adds a function weston_keyboard_set_leds() which can be used
to change the state of the num lock and the caps lock leds.
Only the evdev backend supports this, since it doesn't make sense
for embedded sessions.
---
src/compositor.h | 3 +++
src/input.c | 43 +++
2 files changed, 46 insertions(+)
diff --git a/src/compositor.h b/src/compositor.h
index c0fc0a6..0c5c98a 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -393,6 +393,9 @@ weston_keyboard_start_grab(struct weston_keyboard *device,
struct weston_keyboard_grab *grab);
void
weston_keyboard_end_grab(struct weston_keyboard *keyboard);
+int
+weston_keyboard_set_leds(struct weston_keyboard *keyboard,
+enum weston_led leds, enum weston_led active);
struct weston_touch *
weston_touch_create(void);
diff --git a/src/input.c b/src/input.c
index 1ab55ce..d0637b8 100644
--- a/src/input.c
+++ b/src/input.c
@@ -1064,6 +1064,49 @@ notify_axis(struct weston_seat *seat, uint32_t time,
uint32_t axis,
value);
}
+WL_EXPORT int
+weston_keyboard_set_leds(struct weston_keyboard *keyboard,
+enum weston_led leds, enum weston_led active)
+{
+ /* We don't want the leds to go out of sync with the actual state
+* so if the backend has no way to change the leds don't try to
+* change the state */
+ if (!keyboard->seat->led_update)
+ return -1;
+
+ uint32_t mods_depressed, mods_latched, mods_locked, group;
+ uint32_t serial;
+ int num, caps;
+ mods_depressed = xkb_state_serialize_mods(keyboard->xkb_state.state,
+ XKB_STATE_DEPRESSED);
+ mods_latched = xkb_state_serialize_mods(keyboard->xkb_state.state,
+ XKB_STATE_LATCHED);
+ mods_locked = xkb_state_serialize_mods(keyboard->xkb_state.state,
+ XKB_STATE_LOCKED);
+ group = xkb_state_serialize_group(keyboard->xkb_state.state,
+ XKB_STATE_EFFECTIVE);
+
+ num = (1 << keyboard->xkb_info->mod2_mod);
+ caps = (1 << keyboard->xkb_info->caps_mod);
+ if (leds & LED_NUM_LOCK)
+ mods_locked = (active & LED_NUM_LOCK) ? mods_locked | num
+ : mods_locked & ~num;
+ if (leds & LED_CAPS_LOCK)
+ mods_locked = (active & LED_CAPS_LOCK) ? mods_locked | caps
+ : mods_locked & ~caps;
+ if (leds & LED_SCROLL_LOCK)
+ weston_log("Changing the LED_SCROLL_LOCK value is not
supported.");
+
+ xkb_state_update_mask(keyboard->xkb_state.state, mods_depressed,
+ mods_latched, mods_locked, 0, 0, group);
+
+ serial = wl_display_next_serial(
+ keyboard->seat->compositor->wl_display);
+ notify_modifiers(keyboard->seat, serial);
+
+ return 0;
+}
+
#ifdef ENABLE_XKBCOMMON
WL_EXPORT void
notify_modifiers(struct weston_seat *seat, uint32_t serial)
--
2.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libxkbcommon 0.4.3
A new release of libxkbcommon, containing mostly bug-fixes. libxkbcommon 0.4.3 - 2014-08-19 == - Fixed a bug which caused xkb_x11_keymap_new_from_device() to misrepresent modifiers for some keymaps. https://github.com/xkbcommon/libxkbcommon/issues/9 - Fixed a bug which caused xkb_x11_keymap_new_from_device() to ignore XKB PrivateAction's. - Modifiers are now always fully resolved after xkb_state_update_mask(). Previously the given state components were used as-is, without considering virtual modifier mappings. Note: this only affects non-standard uses of xkb_state_update_mask(). - Added a test for xkbcommon-x11, "x11comp". The test uses the system's Xvfb server and xkbcomp. If they do not exist or fail, the test is skipped. - Fixed memory leaks after parse errors in the XKB yacc parser. The fix required changes which are currently incompatible with byacc. https://github.com/xkbcommon/libxkbcommon/issues/8 Tarballs: git tag: xkbcommon-0.4.3 http://xkbcommon.org/download/libxkbcommon-0.4.3.tar.xz MD5: 26c57ff21438ed45de2a4ca609177db9 libxkbcommon-0.4.3.tar.xz SHA1: 2251adc7425c816ec7af4f1c3776a619a53293b6 libxkbcommon-0.4.3.tar.xz Ran ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] configure.ac: use libinput by default
On Tue, Aug 19, 2014 at 09:46:55AM -0700, Jason Ekstrand wrote: > Reviewed-by: Jason Ekstrand > Acked-by: Jonas Ådahl > > On Tue, Aug 19, 2014 at 3:13 AM, Pekka Paalanen wrote: > > > From: Pekka Paalanen > > > > Libinput is stabilizing soon, so let's flip the default switch now. The > > old input code will still be carried as an option for a while. > > > > Cc: Peter Hutterer > > Cc: Jonas Ådahl > > Signed-off-by: Pekka Paalanen > > --- > > configure.ac | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/configure.ac b/configure.ac > > index 354db14..bc5c88a 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -155,8 +155,8 @@ if test x$enable_drm_compositor = xyes; then > > fi > > > > > > -AC_ARG_ENABLE(libinput-backend, [ --enable-libinput-backend],, > > - enable_libinput_backend=no) > > +AC_ARG_ENABLE(libinput-backend, [ --disable-libinput-backend],, > > + enable_libinput_backend=yes) > > AM_CONDITIONAL([ENABLE_LIBINPUT_BACKEND], [test x$enable_libinput_backend > > = xyes]) > > if test x$enable_libinput_backend = xyes; then > >AC_DEFINE([BUILD_LIBINPUT_BACKEND], [1], [Build the libinput input > > device backend]) > > -- > > 1.8.5.5 > > > > ___ > > 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: [PATCH wayland v2] protocol: define the concept of wl_surface role
Pekka, I have one nitpick below. However, if we can't find a good solution, I'm ok with pushing as-is. Reviewed-by: Jason Ekstrand On Tue, Aug 19, 2014 at 1:41 AM, Pekka Paalanen wrote: > On Tue, 19 Aug 2014 10:29:21 +0300 > Pekka Paalanen wrote: > > > From: Pekka Paalanen > > > > Define what a role is, and what restrictions there are. > > > > A change to existing behaviour is that a role cannot be changed at all > > once set. However, this is unlikely to cause problems, as there is no > > reason to re-use wl_surfaces in clients. > > > > v2: give more concrete examples of roles, define losing a role, Jasper > > rewrote the paragraph on how a role is set. > > > > Signed-off-by: Pekka Paalanen > > --- > > protocol/wayland.xml | 26 -- > > 1 file changed, 24 insertions(+), 2 deletions(-) > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 2d57f69..d3fcaec 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -973,8 +973,30 @@ > >local coordinates of the pixel content, in case a buffer_transform > >or a buffer_scale is used. > > > > - Surfaces are also used for some special purposes, e.g. as > > - cursor images for pointers, drag icons, etc. > > + A surface without a "role" is fairly useless, a compositor does > > + not know where, when or how to present it. The role is the > > + purpose of a wl_surface. Examples of roles are a cursor for a > > + pointer (as set by wl_pointer.set_cursor), a drag icon > > + (wl_data_device.start_drag), a sub-surface > > + (wl_subcompositor.get_subsurface), and a window as defined by a > > + shell protocol (e.g. wl_shell.get_shell_surface). > > + > > + A surface can have only one role at a time. Initially a > > + wl_surface does not have a role. Once a wl_surface is given a > > + role, it can never be given a different role again, even if the > > + wl_surface loses the role in between. > I don't really like the term "looses its role". Once a surface is a "cursor surface" it is always a cursor surface, it just might not be the *current* currsor surface. How about: "A surface can only have one role in its lifetime. Even if the surface stops being actively used in its role, it can never be used in any other role. For instance, once you call wl_pointer.set_cursor on a surface, the surface is now a "cursor surface". Even if it stops being the active cursor, the wl_surface object retains the "cursor" role cannot be used in a different role." Thoughts? > > + > > + Surface roles are set by requests in other interfaces such as > > Bah... forgot to save one tiny change: > > "Surface roles are given by ..." > ---^ > > Thanks, > pq > > > + wl_pointer.set_cursor. The request should explicitly mention > > + that this request gives a role to a wl_surface. Often, this > > + request also creates a new protocol object that represents the > > + role and adds additional functionality to wl_surface. When a > > + client wants to destroy a wl_surface, they must destroy this 'role > > + object' before the wl_surface. > > + > > + A wl_surface may lose its role as specified in the interface > > + that gave it the role or in the interface of the role object. > > + Losing a role means losing all the role-specific state. > > > > > > > > ___ > 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: [PATCH weston] configure.ac: use libinput by default
Reviewed-by: Jason Ekstrand On Tue, Aug 19, 2014 at 3:13 AM, Pekka Paalanen wrote: > From: Pekka Paalanen > > Libinput is stabilizing soon, so let's flip the default switch now. The > old input code will still be carried as an option for a while. > > Cc: Peter Hutterer > Cc: Jonas Ådahl > Signed-off-by: Pekka Paalanen > --- > configure.ac | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 354db14..bc5c88a 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -155,8 +155,8 @@ if test x$enable_drm_compositor = xyes; then > fi > > > -AC_ARG_ENABLE(libinput-backend, [ --enable-libinput-backend],, > - enable_libinput_backend=no) > +AC_ARG_ENABLE(libinput-backend, [ --disable-libinput-backend],, > + enable_libinput_backend=yes) > AM_CONDITIONAL([ENABLE_LIBINPUT_BACKEND], [test x$enable_libinput_backend > = xyes]) > if test x$enable_libinput_backend = xyes; then >AC_DEFINE([BUILD_LIBINPUT_BACKEND], [1], [Build the libinput input > device backend]) > -- > 1.8.5.5 > > ___ > 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: [PATCH wayland] client: add a public function to make a roundtrip on a custom queue
On Tue, Aug 19, 2014 at 3:58 AM, Pekka Paalanen wrote:
> On Wed, 16 Jul 2014 11:13:06 +0300
> Giulio Camuffo wrote:
>
> > 2014-07-15 20:39 GMT+03:00 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.
> >
> > I didn't realize you could read it as "queue a roundtrip on a
> > wl_event". I think that the meaning is quite obvious once you know
> > that there is a wl_event_queue type in Wayland.
>
> Hi,
>
> hm, that's a tricky one. Yes, the name wl_event_queue_roundtrip() is
> confusing when out of context, but as the argument is a wl_event_queue,
> that name is the logical and unfortunate result.
>
> Another problem with wl_display_roundtrip_queue() is that it gets both
> wl_display and wl_event_queue as arguments. Therefore the function
> would need to check that the wl_event_queue indeed belongs to the given
> wl_display. It's just a thing one can get wrong, and it has no benefits
> that I see.
>
> wl_display_roundtrip_queue() taking only wl_event_queue as an argument
> would be strange, because the name implies a wl_display method.
>
> (Up until this point, I would have agreed with Giulio and Jason...)
>
> But, now I see, that we already have:
>
> int wl_display_dispatch_queue(struct wl_display *display,
> struct wl_event_queue *queue);
> int wl_display_dispatch_queue_pending(struct wl_display *display,
> struct wl_event_queue *queue);
> int wl_display_prepare_read_queue(struct wl_display *display,
> struct wl_event_queue *queue);
>
> So there is precendent, that redundant arguments are ok, and
> wl_display_roundtrip_queue() would indeed follow the existing scheme.
>
> Btw. I do not see anywhere, where the libwayland-client code would be
> checking that the wl_display and the wl_event_queue would actually be
> related. Would be a good thing to add more checks to the public API
> functions for that.
>
> I think I would go with wl_display_roundtrip_queue() here. Would you
> agree?
>
Yeah, you've convinced me. I don't like the name (and, by extension, don't
like the others) but it goes better with the current API. Let's go with
that.
--Jason
>
>
> Thanks,
> pq
>
> > >> > 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);
> > >> >>
> > >>
RE: The road to Wayland/Weston 1.6 and 1.5.1
> -Original Message- > From: Pekka Paalanen [mailto:ppaala...@gmail.com] > Sent: Monday, August 18, 2014 4:36 AM > To: wayland-devel@lists.freedesktop.org; krh@ > Cc: Eoff, Ullysses A; Peter Hutterer; Jasper St. Pierre > Subject: The road to Wayland/Weston 1.6 and 1.5.1 > > Hi all, > > in the release announcement of 1.5.0[1] it was said that the alpha > release towards 1.6 should come out mid-August. That time is now, so > how about we target Friday, Aug 22nd (European time)? > Just wanted you to know I'm still following the project, albeit quite silently these days due to other tasks ;). Nonetheless, my test team is ready to ramp up our usual manual testing for this 1.6 release cycle. Our in-house automated builds and tests have still been running and continue to run without issue. I want to make sure we stay synced up during each phase of this release cycle. As you know, it takes us about 3-4 days to complete a manual test run... this includes execution, reflection, and reporting. As long as you plan to continue the usual 1 week phases for each alpha (1.5.91), beta 1 (1.5.92) and beta 2 (1.5.93) then we should be able to keep up. We don't have plans to add any new test cases to our manual test set this time. So our testing will only be regression testing, essentially. Also, our testing only covers the DRM (w/libinput) and X11 backends using the Desktop shell (w/cairo-glesv2) on specific Intel-based hardware. If there are new features and/or other recipes (hardware, backends, etc.) then I trust others will cover those. Cheers :), U. Artie Intel Open Source Technology Center > I know the review process has been lagging behind badly, and we > probably won't see e.g. IVI-shell merged for 1.6, but I try to do what > I can. What major features have been forgotten on the mailing list > unmerged, that you would like to see included in 1.6? > > I can't promise anything, and I know at least none of my new features > (Presentation extension, new repaint scheduling algorithm, repaint > timeline logging, DRM universal planes & nuclear pageflip support, > linux_dmabuf protocol sketch, and some smaller things) brewing in my > personal 'next' branch will not make it. > > Obviously a stable first version of xdg_shell would be great to see in > 1.6, but we shall see if we can beat it into shape in time. When I > reviewed the XML spec not long ago, it was close but not ready in my > opinion. > > When xdg_shell does stabilize, we will move xdg_shell.xml into Wayland > repository and it will be installed, but all build-time users of it must > generate their own wrappers with wayland-scanner or equivalent. This > means that libwayland-client will not contain any xdg_shell symbols or > headers pre-generated. I asked Kristian and he was ok with this plan, > and I have also talked a little on #wayland-devel, that maybe this > would be a good idea. If this turns out a bad idea, we can always fix > it later. Doing it the other way around would be near impossible. > > Should we make libinput the default for 1.6, so that in 1.7 we can > remove the old input code, or is libinput API still too much in flux? > > > Also, it was said that 1.5.1 should have come out in "a few weeks" and > it has been 3 months now. I will try and check the patches already in > 'master' of both Wayland and Weston and pick them to the 1.5 branches, > but if you know of patches that should be in stable, especially ones > without review or not in 'master', let me know and I try do something. > My selection, especially for Wayland, will probably be very > conservative, though, as my priority is 1.6. > > > Thanks, > pq > > [1] > http://lists.freedesktop.org/archives/wayland-devel/2014-May/014955.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: allow weird multitouch device without slots
2014-08-19 10:02 GMT+03:00 Peter Hutterer : > On Tue, Aug 19, 2014 at 06:29:40AM +0300, Leonid Borisenko wrote: > > HID device 'USB HID v1.11 Mouse' provided by Microsoft Wireless Optical > > Desktop=C2=AE 2.20 (connected to USB and identified as vendor 0x45e, pr= oduct > > 0xe3, version 0x111) is reported as supporting EV_ABS event with > ABS_MT_SLOT > > code, but nevertheless libevdev_get_num_slots returns -1. > > yeah, that's intentional. libevdev detects those devices (through > guesswork, > but still...) and returns -1 as slot number. > > > Furthermore, all connected devices (mouse and keyboard) don't produce a= ny > > EV_ABS events for that HID Mouse device in tests with evtest. > > > > Before this fix mouse didn't work in Weston (but worked in X.Org). > > > > As partially explained by LKML message [1] (Message-Id [2]): > > > > The root of the problem comes from hid-input, which maps unknown ax= is > > to ABS_MISC. However, when an event code is already in use, hid-inp= ut > > uses the one after, leading to uses of ABS_MISC + N, where N is the > > number of unknown axis. > > > > We are encountering a problem with the multitouch protocol here > because > > if a device has more than 7 unknown axis (which is the case for the > PS3 > > Sixaxis controller), then the unknown axis get maps to ABS_MT_SLOT > and > > beyond. > > > > [1] https://lkml.org/lkml/2013/11/20/515 > > [2] 1384983141-31019-1-git-send-email-benjamin.tissoi...@redhat.com > > > > [...] > > so, as I said above the libevdev behaviour is intentional and our > indicator > that this isn't a MT device after all. We should integrate that knowledge > better so that we don't label a device as touch device when it isn't, and > so > that we process events from those axes as normal ABS events instead of MT > events. Unfortunately, my device (that Wireless Optical Desktop) doesn't produce any events with the questionable codes, so if I would try to change libinput behavior for these events to produce visible reaction, I'll not be able to test changes for sanity. I understand that my patch isn't general enough. It fixes my problem. though, making mouse working in Weston. Current libinput code isn't forgiving enough in handling of similar devices, so it cripples experience. I'm not complaining, it's v0.5, so missing functionality is acceptable, but it's frustrating. I will file a bug report in hope that someone will propose more general fix= . As a sidenote, cited LKML message says that "the axis currently mapped on ABS_MT_SLOT is a special case in the kernel, and it is not updated", so I think processing axes as normal ABS events will not work for the axis reported as ABS_MT_SLOT. [Peter, sorry for spamming with this message in personal mail, it was my unintentional mistake in using Gmail UI.] ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/2] xwm: check whether the picked seat can be NULL
On Tue, 2014-08-19 at 16:53 +0300, Pekka Paalanen wrote: > I was not able to reproduce the crash without the patch, and using > gnome-terminal, either. Actually I'm also curious about how is the problem triggered, and I reproduced it on my machine just now. And I'm even more astonished to see this [1], though I can't reproduce it myself. It said that the picked seat can be NULL even in weston_wm_handle_button! I guess somewhere might be wrong in X (just a wild guess). Cheers, Boyan Ding [1] https://bugs.archlinux.org/task/41456 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 1/2] Remove duplicated code from cliptest.c
Signed-off-by: Ondřej Majerech
---
Makefile.am| 2 +-
clients/cliptest.c | 293 +
2 files changed, 4 insertions(+), 291 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 191dcc9..8a27d44 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -476,7 +476,7 @@ weston_image_SOURCES = clients/image.c
weston_image_LDADD = libtoytoolkit.la
weston_image_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
-weston_cliptest_SOURCES = clients/cliptest.c
+weston_cliptest_SOURCES = clients/cliptest.c src/vertex-clipping.c
weston_cliptest_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
weston_cliptest_LDADD = libtoytoolkit.la
diff --git a/clients/cliptest.c b/clients/cliptest.c
index 907c5d4..af7bff1 100644
--- a/clients/cliptest.c
+++ b/clients/cliptest.c
@@ -49,6 +49,7 @@
#include
#include
+#include "src/vertex-clipping.h"
#include "window.h"
typedef float GLfloat;
@@ -81,269 +82,6 @@ weston_surface_to_global_float(struct weston_surface
*surface,
*y = -g->s * sx + g->c * sy;
}
-/* -- copied begins ---*/
-
-struct polygon8 {
- GLfloat x[8];
- GLfloat y[8];
- int n;
-};
-
-struct clip_context {
- struct {
- GLfloat x;
- GLfloat y;
- } prev;
-
- struct {
- GLfloat x1, y1;
- GLfloat x2, y2;
- } clip;
-
- struct {
- GLfloat *x;
- GLfloat *y;
- } vertices;
-};
-
-static GLfloat
-float_difference(GLfloat a, GLfloat b)
-{
- /*
http://www.altdevblogaday.com/2012/02/22/comparing-floating-point-numbers-2012-edition/
*/
- static const GLfloat max_diff = 4.0f * FLT_MIN;
- static const GLfloat max_rel_diff = 4.0e-5;
- GLfloat diff = a - b;
- GLfloat adiff = fabsf(diff);
-
- if (adiff <= max_diff)
- return 0.0f;
-
- a = fabsf(a);
- b = fabsf(b);
- if (adiff <= (a > b ? a : b) * max_rel_diff)
- return 0.0f;
-
- return diff;
-}
-
-/* A line segment (p1x, p1y)-(p2x, p2y) intersects the line x = x_arg.
- * Compute the y coordinate of the intersection.
- */
-static GLfloat
-clip_intersect_y(GLfloat p1x, GLfloat p1y, GLfloat p2x, GLfloat p2y,
-GLfloat x_arg)
-{
- GLfloat a;
- GLfloat diff = float_difference(p1x, p2x);
-
- /* Practically vertical line segment, yet the end points have already
-* been determined to be on different sides of the line. Therefore
-* the line segment is part of the line and intersects everywhere.
-* Return the end point, so we use the whole line segment.
-*/
- if (diff == 0.0f)
- return p2y;
-
- a = (x_arg - p2x) / diff;
- return p2y + (p1y - p2y) * a;
-}
-
-/* A line segment (p1x, p1y)-(p2x, p2y) intersects the line y = y_arg.
- * Compute the x coordinate of the intersection.
- */
-static GLfloat
-clip_intersect_x(GLfloat p1x, GLfloat p1y, GLfloat p2x, GLfloat p2y,
-GLfloat y_arg)
-{
- GLfloat a;
- GLfloat diff = float_difference(p1y, p2y);
-
- /* Practically horizontal line segment, yet the end points have already
-* been determined to be on different sides of the line. Therefore
-* the line segment is part of the line and intersects everywhere.
-* Return the end point, so we use the whole line segment.
-*/
- if (diff == 0.0f)
- return p2x;
-
- a = (y_arg - p2y) / diff;
- return p2x + (p1x - p2x) * a;
-}
-
-enum path_transition {
- PATH_TRANSITION_OUT_TO_OUT = 0,
- PATH_TRANSITION_OUT_TO_IN = 1,
- PATH_TRANSITION_IN_TO_OUT = 2,
- PATH_TRANSITION_IN_TO_IN = 3,
-};
-
-static void
-clip_append_vertex(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- *ctx->vertices.x++ = x;
- *ctx->vertices.y++ = y;
-}
-
-static enum path_transition
-path_transition_left_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx->prev.x >= ctx->clip.x1) << 1) | (x >= ctx->clip.x1);
-}
-
-static enum path_transition
-path_transition_right_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx->prev.x < ctx->clip.x2) << 1) | (x < ctx->clip.x2);
-}
-
-static enum path_transition
-path_transition_top_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx->prev.y >= ctx->clip.y1) << 1) | (y >= ctx->clip.y1);
-}
-
-static enum path_transition
-path_transition_bottom_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx->prev.y < ctx->clip.y2) << 1) | (y < ctx->clip.y2);
-}
-
-static void
-clip_polygon_leftright(struct clip_context *ctx,
- enum path_transition transition,
- GLfloat x, GLfloat y, GLfloat clip_x)
-{
- GLfloat yi;
-
- switch (transition) {
- case PATH_TRANSITION_IN_TO_IN:
- clip_append_vertex(ctx, x, y);
[PATCH v2 2/2] Don't underrun the vertex array of empty polygons
This silences the following warning:
src/vertex-clipping.c:196:22: warning: array subscript is below array
bounds [-Warray-bounds]
ctx->prev.x = src->x[src->n - 1];
Signed-off-by: Ondřej Majerech
---
src/vertex-clipping.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/vertex-clipping.c b/src/vertex-clipping.c
index db527e1..2bb8c0a 100644
--- a/src/vertex-clipping.c
+++ b/src/vertex-clipping.c
@@ -206,6 +206,9 @@ clip_polygon_left(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src->n < 2)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i < src->n; i++) {
trans = path_transition_left_edge(ctx, src->x[i], src->y[i]);
@@ -222,6 +225,9 @@ clip_polygon_right(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src->n < 2)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i < src->n; i++) {
trans = path_transition_right_edge(ctx, src->x[i], src->y[i]);
@@ -238,6 +244,9 @@ clip_polygon_top(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src->n < 2)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i < src->n; i++) {
trans = path_transition_top_edge(ctx, src->x[i], src->y[i]);
@@ -254,6 +263,9 @@ clip_polygon_bottom(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src->n < 2)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i < src->n; i++) {
trans = path_transition_bottom_edge(ctx, src->x[i], src->y[i]);
--
2.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The road to Wayland/Weston 1.6 and 1.5.1
On Mon, 18 Aug 2014 20:55:52 +0800 Boyan Ding wrote: > Hi, > > On Mon, 2014-08-18 at 14:35 +0300, Pekka Paalanen wrote: > > Hi all, > > > > in the release announcement of 1.5.0[1] it was said that the alpha > > release towards 1.6 should come out mid-August. That time is now, so > > how about we target Friday, Aug 22nd (European time)? > > > [...] > > > > Also, it was said that 1.5.1 should have come out in "a few weeks" and > > it has been 3 months now. I will try and check the patches already in > > 'master' of both Wayland and Weston and pick them to the 1.5 branches, > > but if you know of patches that should be in stable, especially ones > > without review or not in 'master', let me know and I try do something. > > My selection, especially for Wayland, will probably be very > > conservative, though, as my priority is 1.6. > > There are two patches for xwayland part in weston that has stood for > quite a while: > http://lists.freedesktop.org/archives/wayland-devel/2014-July/015885.html > http://lists.freedesktop.org/archives/wayland-devel/2014-July/015886.html > with the first one being a little feature and the second one > a simple bugfix. > > Also another patch that doesn't got reviewed but quite important: > http://lists.freedesktop.org/archives/wayland-devel/2014-August/016307.html > It should follow c4902124 and 9c5aedff in master (and also in 1.5 > branch) but I left that out then. All three adressed, I think. Feel free to poke me again when I start asking about what I forgot from the stable branches. I'd like to let things live a bit in master, if at all possible. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/19] Basic tablet support in Weston
On Tue, 19 Aug 2014 13:21:54 +0200 Jonas Ådahl wrote: > On Tue, Aug 19, 2014 at 01:03:52PM +0300, Pekka Paalanen wrote: > > On Wed, 6 Aug 2014 19:07:50 -0400 > > Stephen Chandler Paul wrote: > > > > > Hi! As some of you have been aware, I have been working on implementing > > > tablet > > > ssupport in libinput, the wayland protocol and weston. This patchset adds > > > basic > > > tablet support to weston, along with support in the shell and the window > > > manager. It should be noted that these patches rely on one of the earlier > > > patches to libinput that I posted on the mailing list: "tablet: Add > > > libinput_tablet_has_axis()", along with the tablet-support branch in the > > > git repository for libinput. > > > > > > As of right now, the following things are still missing/haven't been > > > finished > > > yet: > > > * Tablet objects don't ever send a removed event, right now it's up to the > > > clients to free the resources for each tool object. > > > * Tablet tool objects should be separate for each tablet connected that > > > doesn't > > > report serial numbers. Right now tablet objects are shared by all > > > tablets > > > connected to the system unconditionally. > > > * The tablet cursor disappears occasionally when moving a window and > > > causing > > > the mouse pointer to change images, but reappears the next time a > > > client sets > > > a cursor image. > > > * weston-flower can crash the shell for some reason. It seems that if a > > > tablet > > > is turned on, and the first surface the tool comes into focus on > > > belongs to a > > > weston-flower instance, the desktop-shell runs into an error and exits. > > > I > > > haven't noticed this with anything other then weston-flower though. > > > * Held down buttons are released when the tool changes focus from one > > > surface > > > to another, instead of being held down until they're released. > > > * Some of the declarations for structs in my code might need to be moved > > > around, I'm not sure what the expected guidelines for this in weston's > > > code > > > are though. > > > * A surface argument needs to be added to the proximity_out event, so we > > > can > > > tell if the tablet tool is leaving proximity to switch focus to another > > > surface, or if it's just exiting proximity. > > > > > > Review/critique would be appreciated, thank you! ^^ > > > > > > Cheers, > > > Lyude > > > > > > Stephen Chandler Paul (19): > > > tablet: Add XML for wl_tablet and wl_tablet_manager > > > tablet: Add initial tablet support to weston > > > client: Add support for handling motion events in toytoolkit > > > client: Add support for handling proximity_in/out events in > > > libtoytoolkit > > > tablet: Add support for setting/changing the tablet cursor in weston > > > client: Add tablet cursor support into libtoytoolkit > > > tablet: Add support for tablet tool objects > > > client: Add support for tool objects in libtoytoolkit > > > client: Add support for tablet cursor motion to window frames in > > > libtoytoolkit > > > tablet: Add support for button presses to weston > > > client: Add support for handling button presses to libtoytoolkit > > > tablet: Add support for up/down events to weston > > > client: Add up/down event support into libtoytoolkit > > > tablet: Add support for moving windows around using the stylus > > > tablet: Add support for reporting pressure, distance, and tilt in > > > weston > > > client: Add support for pressure, distance, and tilt into > > > libtoytoolkit > > > tablet: Add tablet support to the top panel of the desktop shell > > > tablet: Add binding to activate surfaces using the tablet tool > > > tablet: Add demo application for tablets > > > > > > .gitignore | 1 + > > > Makefile.am | 23 +- > > > clients/desktop-shell.c | 55 > > > clients/tablet.c| 341 > > > clients/window.c| 607 > > > clients/window.h| 102 ++ > > > desktop-shell/shell.c | 282 + > > > protocol/wayland-tablet.xml | 310 +++ > > > shared/cairo-util.h | 4 + > > > shared/frame.c | 38 +++ > > > src/bindings.c | 37 +++ > > > src/compositor.c| 1 + > > > src/compositor.h| 171 ++ > > > src/input.c | 736 > > > > > > src/libinput-device.c | 317 +++ > > > src/libinput-device.h | 4 +- > > > 16 files changed, 3024 insertions(+), 5 deletions(-) > > > create mode 100644 clients/tablet.c > > > create mode 100644 protocol/wayland-tablet.xml > > > > > > > Hi, > > > > just a heads-up, do I get the right impression that this is not yet in > > a shape to merge into Weston, so won't be included in 1.6? >
Re: [PATCH weston 2/2] xwm: check whether the picked seat can be NULL
On Sun, 6 Jul 2014 11:44:58 +0800 Boyan Ding wrote: > The seat picked in weston_wm_window_handle_moveresize can sometimes > be NULL when it is (somehow) triggered with all buttons released. > > This patch checks whether the seat is NULL to avoid NULL dereference. > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=80837 > Signed-off-by: Boyan Ding > --- > xwayland/window-manager.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c > index f64ef94..6e74b89 100644 > --- a/xwayland/window-manager.c > +++ b/xwayland/window-manager.c > @@ -1250,8 +1250,8 @@ weston_wm_window_handle_moveresize(struct > weston_wm_window *window, > struct weston_shell_interface *shell_interface = > &wm->server->compositor->shell_interface; > > - if (seat->pointer->button_count != 1 || !window->view > - || seat->pointer->focus != window->view) > + if (seat == NULL || seat->pointer->button_count != 1 > + || !window->view || seat->pointer->focus != window->view) > return; > > detail = client_message->data.data32[2]; Shouldn't hurt and I accidentally already pushed this. :-P I was not able to reproduce the crash without the patch, and using gnome-terminal, either. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] cairo-util: Draw solid titlebar for frames with only buttons
On Tue, 5 Aug 2014 15:22:04 +0800
Boyan Ding wrote:
> Previously geometry was changed to leave space for titlebar if a frame
> has only buttons but no title. This patch fixes theme_render_frame to
> avoid transparent titlebar.
>
> Signed-off-by: Boyan Ding
> ---
> shared/cairo-util.c | 8 +---
> shared/cairo-util.h | 5 -
> shared/frame.c | 2 +-
> 3 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/shared/cairo-util.c b/shared/cairo-util.c
> index 2a33249..26286c5 100644
> --- a/shared/cairo-util.c
> +++ b/shared/cairo-util.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "cairo-util.h"
>
> @@ -413,7 +414,8 @@ theme_destroy(struct theme *t)
> void
> theme_render_frame(struct theme *t,
> cairo_t *cr, int width, int height,
> -const char *title, uint32_t flags)
> +const char *title, struct wl_list *buttons,
> +uint32_t flags)
> {
> cairo_text_extents_t extents;
> cairo_font_extents_t font_extents;
> @@ -439,7 +441,7 @@ theme_render_frame(struct theme *t,
> else
> source = t->inactive_frame;
>
> - if (title)
> + if (title || !wl_list_empty(buttons))
> top_margin = t->titlebar_height;
> else
> top_margin = t->width;
> @@ -449,7 +451,7 @@ theme_render_frame(struct theme *t,
> width - margin * 2, height - margin * 2,
> t->width, top_margin);
>
> - if (title) {
> + if (title || !wl_list_empty(buttons)) {
> cairo_rectangle (cr, margin + t->width, margin,
>width - (margin + t->width) * 2,
>t->titlebar_height - t->width);
> diff --git a/shared/cairo-util.h b/shared/cairo-util.h
> index 4493b0d..fb25c34 100644
> --- a/shared/cairo-util.h
> +++ b/shared/cairo-util.h
> @@ -26,6 +26,8 @@
> #include
> #include
>
> +#include
> +
> void
> surface_flush_device(cairo_surface_t *surface);
>
> @@ -69,7 +71,8 @@ theme_set_background_source(struct theme *t, cairo_t *cr,
> uint32_t flags);
> void
> theme_render_frame(struct theme *t,
> cairo_t *cr, int width, int height,
> -const char *title, uint32_t flags);
> +const char *title, struct wl_list *buttons,
> +uint32_t flags);
>
> enum theme_location {
> THEME_LOCATION_INTERIOR = 0,
> diff --git a/shared/frame.c b/shared/frame.c
> index 53f3f5f..5ea0e12 100644
> --- a/shared/frame.c
> +++ b/shared/frame.c
> @@ -853,7 +853,7 @@ frame_repaint(struct frame *frame, cairo_t *cr)
>
> cairo_save(cr);
> theme_render_frame(frame->theme, cr, frame->width, frame->height,
> -frame->title, flags);
> +frame->title, &frame->buttons, flags);
> cairo_restore(cr);
>
> wl_list_for_each(button, &frame->buttons, link)
Not sure how I'd test it, but it looks okay to me... pushed.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 1/2] xwm: Use cursor theme and size in weston.ini
On Sun, 6 Jul 2014 11:44:57 +0800
Boyan Ding wrote:
> to make it consistent with native wayland apps
>
> Signed-off-by: Boyan Ding
> ---
> xwayland/window-manager.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index 2fb65b1..f64ef94 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -38,6 +38,7 @@
>
> #include "cairo-util.h"
> #include "compositor.h"
> +#include "config-parser.h"
> #include "hash.h"
>
> struct wm_size_hints {
> @@ -269,22 +270,24 @@ xcb_cursor_images_load_cursor(struct weston_wm *wm,
> const XcursorImages *images)
> static xcb_cursor_t
> xcb_cursor_library_load_cursor(struct weston_wm *wm, const char *file)
> {
> + struct weston_config *config;
> + struct weston_config_section *s;
> xcb_cursor_t cursor;
> XcursorImages *images;
> - char *v = NULL;
> + char *theme = NULL;
> int size = 0;
>
> if (!file)
> return 0;
>
> - v = getenv ("XCURSOR_SIZE");
> - if (v)
> - size = atoi(v);
> + config = weston_config_parse("weston.ini");
> + s = weston_config_get_section(config, "shell", NULL, NULL);
> + weston_config_section_get_string(s, "cursor-theme", &theme, NULL);
> + weston_config_section_get_int(s, "cursor-size", &size, 32);
> + weston_config_destroy(config);
>
> - if (!size)
> - size = 32;
> -
> - images = XcursorLibraryLoadImages (file, NULL, size);
> + images = XcursorLibraryLoadImages (file, theme, size);
> + free(theme);
> if (!images)
> return -1;
>
Hi,
looks ok, but could you re-spin this so that you do not call
weston_config_parse() but use the already parsed
weston_compositor::config?
For an example, see 673a889fd88a70a9308d29bd6574f7c8c67da68d.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] cliptest: Don't underrun the vertex array of empty polygons.
On 19 August 2014 14:16, Pekka Paalanen wrote:
> On Tue, 19 Aug 2014 13:10:55 +0200
> Ondřej Majerech wrote:
>
>> This silences the following warning:
>>
>> clients/cliptest.c:277:22: warning: array subscript is below array
>> bounds [-Warray-bounds]
>> ctx->prev.x = src->x[src->n - 1];
>
> Hi,
>
> seems like I would need something more recent than gcc 4.6.4 to get
> these warnings, right?
I'm using GCC 4.9.1, so presumably yes. :)
>
> Do you not get these warnings from src/vertex-clipping.c too?
Ah, yes. Fresh rebuild gives me warnings from src/vertex-clipping.c as well.
>
> At minimum, could you patch both clients/cliptest.c and
> src/vertex-clipping.c in the same patch, and check that the duplicated
> code is identical.
>
> An even better alternative would be to just drop the duplicate code
> from cliptest.c, and make it somehow just use src/vertex-clipping.c
> and .h. I'm not sure how the build system would cope with that, but
> that would be excellent. So first remove duplication, then fix the
> issues.
indeed. I'll see what I can do about the duplication.
>
> Also, I think the correct condition would be:
> if (src->n < 2)
> return 0;
>
> Because if a polygon has less than 2 points, it's not a polygon that
> could even theoretically be clipped. The 2 points case also is
> denegerate, but least it has two lines that can be clipped.
You're right -- I was thinking more about buffers than geometry. :)
>
>
> Thanks,
> pq
>
>>
>> Signed-off-by: Ondřej Majerech
>> ---
>> clients/cliptest.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/clients/cliptest.c b/clients/cliptest.c
>> index 907c5d4..20b3776 100644
>> --- a/clients/cliptest.c
>> +++ b/clients/cliptest.c
>> @@ -287,6 +287,9 @@ clip_polygon_left(struct clip_context *ctx, const struct
>> polygon8 *src,
>> enum path_transition trans;
>> int i;
>>
>> + if (src->n == 0)
>> + return 0;
>> +
>> clip_context_prepare(ctx, src, dst_x, dst_y);
>> for (i = 0; i < src->n; i++) {
>> trans = path_transition_left_edge(ctx, src->x[i], src->y[i]);
>> @@ -303,6 +306,9 @@ clip_polygon_right(struct clip_context *ctx, const
>> struct polygon8 *src,
>> enum path_transition trans;
>> int i;
>>
>> + if (src->n == 0)
>> + return 0;
>> +
>> clip_context_prepare(ctx, src, dst_x, dst_y);
>> for (i = 0; i < src->n; i++) {
>> trans = path_transition_right_edge(ctx, src->x[i], src->y[i]);
>> @@ -319,6 +325,9 @@ clip_polygon_top(struct clip_context *ctx, const struct
>> polygon8 *src,
>> enum path_transition trans;
>> int i;
>>
>> + if (src->n == 0)
>> + return 0;
>> +
>> clip_context_prepare(ctx, src, dst_x, dst_y);
>> for (i = 0; i < src->n; i++) {
>> trans = path_transition_top_edge(ctx, src->x[i], src->y[i]);
>> @@ -335,6 +344,9 @@ clip_polygon_bottom(struct clip_context *ctx, const
>> struct polygon8 *src,
>> enum path_transition trans;
>> int i;
>>
>> + if (src->n == 0)
>> + return 0;
>> +
>> clip_context_prepare(ctx, src, dst_x, dst_y);
>> for (i = 0; i < src->n; i++) {
>> trans = path_transition_bottom_edge(ctx, src->x[i], src->y[i]);
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] cliptest: Don't underrun the vertex array of empty polygons.
On Tue, 19 Aug 2014 13:10:55 +0200
Ondřej Majerech wrote:
> This silences the following warning:
>
> clients/cliptest.c:277:22: warning: array subscript is below array
> bounds [-Warray-bounds]
> ctx->prev.x = src->x[src->n - 1];
Hi,
seems like I would need something more recent than gcc 4.6.4 to get
these warnings, right?
Do you not get these warnings from src/vertex-clipping.c too?
At minimum, could you patch both clients/cliptest.c and
src/vertex-clipping.c in the same patch, and check that the duplicated
code is identical.
An even better alternative would be to just drop the duplicate code
from cliptest.c, and make it somehow just use src/vertex-clipping.c
and .h. I'm not sure how the build system would cope with that, but
that would be excellent. So first remove duplication, then fix the
issues.
Also, I think the correct condition would be:
if (src->n < 2)
return 0;
Because if a polygon has less than 2 points, it's not a polygon that
could even theoretically be clipped. The 2 points case also is
denegerate, but least it has two lines that can be clipped.
Thanks,
pq
>
> Signed-off-by: Ondřej Majerech
> ---
> clients/cliptest.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/clients/cliptest.c b/clients/cliptest.c
> index 907c5d4..20b3776 100644
> --- a/clients/cliptest.c
> +++ b/clients/cliptest.c
> @@ -287,6 +287,9 @@ clip_polygon_left(struct clip_context *ctx, const struct
> polygon8 *src,
> enum path_transition trans;
> int i;
>
> + if (src->n == 0)
> + return 0;
> +
> clip_context_prepare(ctx, src, dst_x, dst_y);
> for (i = 0; i < src->n; i++) {
> trans = path_transition_left_edge(ctx, src->x[i], src->y[i]);
> @@ -303,6 +306,9 @@ clip_polygon_right(struct clip_context *ctx, const struct
> polygon8 *src,
> enum path_transition trans;
> int i;
>
> + if (src->n == 0)
> + return 0;
> +
> clip_context_prepare(ctx, src, dst_x, dst_y);
> for (i = 0; i < src->n; i++) {
> trans = path_transition_right_edge(ctx, src->x[i], src->y[i]);
> @@ -319,6 +325,9 @@ clip_polygon_top(struct clip_context *ctx, const struct
> polygon8 *src,
> enum path_transition trans;
> int i;
>
> + if (src->n == 0)
> + return 0;
> +
> clip_context_prepare(ctx, src, dst_x, dst_y);
> for (i = 0; i < src->n; i++) {
> trans = path_transition_top_edge(ctx, src->x[i], src->y[i]);
> @@ -335,6 +344,9 @@ clip_polygon_bottom(struct clip_context *ctx, const
> struct polygon8 *src,
> enum path_transition trans;
> int i;
>
> + if (src->n == 0)
> + return 0;
> +
> clip_context_prepare(ctx, src, dst_x, dst_y);
> for (i = 0; i < src->n; i++) {
> trans = path_transition_bottom_edge(ctx, src->x[i], src->y[i]);
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Added destructor protocol to wl_data_device interface
From: "kabeer.khan" This is a fix to Bug# 81745 Signed-off-by: kabeer --- protocol/wayland.xml |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..c3a9f28 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -569,8 +569,13 @@ - - + + +Destroy the data device. + + + + The data_offer event introduces a new wl_data_offer object, which will subsequently be used in either the -- 1.7.9.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The road to Wayland/Weston 1.6 and 1.5.1
2014-08-19 14:50 GMT+03:00 Daniel Stone :
> Hi,
>
> On 18 August 2014 13:14, Pekka Paalanen wrote:
>>
>> On Mon, 18 Aug 2014 14:57:37 +0300
>> Giulio Camuffo wrote:
>> > 2014-08-18 14:35 GMT+03:00 Pekka Paalanen :
>> > > had these patches which I'd like to see going in:
>> >
>> > http://lists.freedesktop.org/archives/wayland-devel/2013-December/012589.html
>>
>> This one looks pretty simple, and I can confirm the problem with
>> CapsLock, so yes, I'd like to take this. Could you rebase it?
>
>
> This is a good start, yes. It's either that or go through the keymap state
> trying to work out the modifier state to accompany the LEDs, which is doable
> but a bit fiddly.
>
>>
>> >
>> > http://lists.freedesktop.org/archives/wayland-devel/2013-December/012590.html
>> >
>> > http://lists.freedesktop.org/archives/wayland-devel/2013-December/012591.html
>>
>> Of these two, the first needs the second to be used at all, right? The
>> follow-up comment is true, I would not want NumLock be on by default on
>> my laptop, so I think this needs more work, like you have identified.
>
>
> Yes, definitely not on by default please. As for the second patch, I'm a
> little hesitant to add it to X11 in particular: why should we be telling the
> host server what the modifier state for the entire session (which is larger
> than the nested compositor) should be?
>
> evdev requires LEDs to be driven because in that situation, we are the
> lowest-level input consumer, and thus calculate our own state (i.e. call
> xkb_state_update_key). In nested environments (compositor-{x11,wayland}), we
> never calculate our own state, but receive the state from the host display
> server. If the host display server isn't keeping the state sent to its
> clients in sync with the state of its input devices, then that's a bug.
That makes sense, and I don't remember why i wrote that
"x11_compositor_led_update()" honestly.
I'll reply with a patch just adding the weston_keyboard_set_leds API,
without the X11 code.
--
Giulio
>
> (tl;dr: NAK)
>
> Cheers,
> Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 3/3] tests: add one more test for event-loop signal source
On 19 August 2014 13:37, Pekka Paalanen wrote: > On Tue, 19 Aug 2014 12:37:53 +0200 > Marek Chalupa wrote: > > > On 18 August 2014 12:23, Marek Chalupa wrote: > > > > > Hi, > > > > > > thanks for reviewing. > > > > > > The failure you got is not introduced by this patch, I reported it some > > > time ago here: > > > https://bugs.freedesktop.org/show_bug.cgi?id=80594 > > > > > > > I put a patch for this bug into bugzilla: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=80594 > > Hi, > > ok, I picked them up from bugzilla, but I would really prefer email to > the list, because I can't review bugzilla attachments on the mailing > list, and it is much much easier for me to apply patches from email. > Ok :) > So the essence of the test is to get two timers fire so, that they will > both be dispatched on the same wl_event_loop_dispatch() call. What it > actually tests is that the timerfd handler won't get stuck because the > handler that runs first modifies the second. > Yes. > I believe your patch should fix it, so I pushed them. I try to remember > to leave a 'make check' loop running over night. > > I had it running in a loop for some time and I hope it fixed it. It was not a whole night, though :) > > Thanks, > pq > Thanks, Marek ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The road to Wayland/Weston 1.6 and 1.5.1
Hi,
On 18 August 2014 13:14, Pekka Paalanen wrote:
> On Mon, 18 Aug 2014 14:57:37 +0300
> Giulio Camuffo wrote:
> > 2014-08-18 14:35 GMT+03:00 Pekka Paalanen :
> > > had these patches which I'd like to see going in:
> >
> http://lists.freedesktop.org/archives/wayland-devel/2013-December/012589.html
>
> This one looks pretty simple, and I can confirm the problem with
> CapsLock, so yes, I'd like to take this. Could you rebase it?
>
This is a good start, yes. It's either that or go through the keymap state
trying to work out the modifier state to accompany the LEDs, which is
doable but a bit fiddly.
> >
> http://lists.freedesktop.org/archives/wayland-devel/2013-December/012590.html
> >
> http://lists.freedesktop.org/archives/wayland-devel/2013-December/012591.html
>
> Of these two, the first needs the second to be used at all, right? The
> follow-up comment is true, I would not want NumLock be on by default on
> my laptop, so I think this needs more work, like you have identified.
>
Yes, definitely not on by default please. As for the second patch, I'm a
little hesitant to add it to X11 in particular: why should we be telling
the host server what the modifier state for the entire session (which is
larger than the nested compositor) should be?
evdev requires LEDs to be driven because in that situation, we are the
lowest-level input consumer, and thus calculate our own state (i.e. call
xkb_state_update_key). In nested environments (compositor-{x11,wayland}),
we never calculate our own state, but receive the state from the host
display server. If the host display server isn't keeping the state sent to
its clients in sync with the state of its input devices, then that's a bug.
(tl;dr: NAK)
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The road to Wayland/Weston 1.6 and 1.5.1
Hi, On 19 August 2014 07:54, Peter Hutterer wrote: > On Mon, Aug 18, 2014 at 02:35:49PM +0300, Pekka Paalanen wrote: > > Should we make libinput the default for 1.6, so that in 1.7 we can > > remove the old input code, or is libinput API still too much in flux? > > I don't think it'll change much and Jonas and I have been talking about > declaring it stable soon anyway. I've got two more changes that are > somewhat > urgent, both would be additive. > > So yes, I think switching to libinput by default would be good. > +1 from me. Even if it does still have problems, it's a damn sight better than what came before it, and I'd like to bin the latter as soon as possible. So if we can agree a sensible libinput release for dependencies, we should absolutely do this. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 3/3] tests: add one more test for event-loop signal source
On Tue, 19 Aug 2014 12:37:53 +0200 Marek Chalupa wrote: > On 18 August 2014 12:23, Marek Chalupa wrote: > > > Hi, > > > > thanks for reviewing. > > > > The failure you got is not introduced by this patch, I reported it some > > time ago here: > > https://bugs.freedesktop.org/show_bug.cgi?id=80594 > > > > I put a patch for this bug into bugzilla: > > https://bugs.freedesktop.org/show_bug.cgi?id=80594 Hi, ok, I picked them up from bugzilla, but I would really prefer email to the list, because I can't review bugzilla attachments on the mailing list, and it is much much easier for me to apply patches from email. So the essence of the test is to get two timers fire so, that they will both be dispatched on the same wl_event_loop_dispatch() call. What it actually tests is that the timerfd handler won't get stuck because the handler that runs first modifies the second. I believe your patch should fix it, so I pushed them. I try to remember to leave a 'make check' loop running over night. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/19] Basic tablet support in Weston
On Tue, Aug 19, 2014 at 01:03:52PM +0300, Pekka Paalanen wrote: > On Wed, 6 Aug 2014 19:07:50 -0400 > Stephen Chandler Paul wrote: > > > Hi! As some of you have been aware, I have been working on implementing > > tablet > > ssupport in libinput, the wayland protocol and weston. This patchset adds > > basic > > tablet support to weston, along with support in the shell and the window > > manager. It should be noted that these patches rely on one of the earlier > > patches to libinput that I posted on the mailing list: "tablet: Add > > libinput_tablet_has_axis()", along with the tablet-support branch in the > > git repository for libinput. > > > > As of right now, the following things are still missing/haven't been > > finished > > yet: > > * Tablet objects don't ever send a removed event, right now it's up to the > > clients to free the resources for each tool object. > > * Tablet tool objects should be separate for each tablet connected that > > doesn't > > report serial numbers. Right now tablet objects are shared by all tablets > > connected to the system unconditionally. > > * The tablet cursor disappears occasionally when moving a window and causing > > the mouse pointer to change images, but reappears the next time a client > > sets > > a cursor image. > > * weston-flower can crash the shell for some reason. It seems that if a > > tablet > > is turned on, and the first surface the tool comes into focus on belongs > > to a > > weston-flower instance, the desktop-shell runs into an error and exits. I > > haven't noticed this with anything other then weston-flower though. > > * Held down buttons are released when the tool changes focus from one > > surface > > to another, instead of being held down until they're released. > > * Some of the declarations for structs in my code might need to be moved > > around, I'm not sure what the expected guidelines for this in weston's > > code > > are though. > > * A surface argument needs to be added to the proximity_out event, so we can > > tell if the tablet tool is leaving proximity to switch focus to another > > surface, or if it's just exiting proximity. > > > > Review/critique would be appreciated, thank you! ^^ > > > > Cheers, > > Lyude > > > > Stephen Chandler Paul (19): > > tablet: Add XML for wl_tablet and wl_tablet_manager > > tablet: Add initial tablet support to weston > > client: Add support for handling motion events in toytoolkit > > client: Add support for handling proximity_in/out events in > > libtoytoolkit > > tablet: Add support for setting/changing the tablet cursor in weston > > client: Add tablet cursor support into libtoytoolkit > > tablet: Add support for tablet tool objects > > client: Add support for tool objects in libtoytoolkit > > client: Add support for tablet cursor motion to window frames in > > libtoytoolkit > > tablet: Add support for button presses to weston > > client: Add support for handling button presses to libtoytoolkit > > tablet: Add support for up/down events to weston > > client: Add up/down event support into libtoytoolkit > > tablet: Add support for moving windows around using the stylus > > tablet: Add support for reporting pressure, distance, and tilt in > > weston > > client: Add support for pressure, distance, and tilt into > > libtoytoolkit > > tablet: Add tablet support to the top panel of the desktop shell > > tablet: Add binding to activate surfaces using the tablet tool > > tablet: Add demo application for tablets > > > > .gitignore | 1 + > > Makefile.am | 23 +- > > clients/desktop-shell.c | 55 > > clients/tablet.c| 341 > > clients/window.c| 607 > > clients/window.h| 102 ++ > > desktop-shell/shell.c | 282 + > > protocol/wayland-tablet.xml | 310 +++ > > shared/cairo-util.h | 4 + > > shared/frame.c | 38 +++ > > src/bindings.c | 37 +++ > > src/compositor.c| 1 + > > src/compositor.h| 171 ++ > > src/input.c | 736 > > > > src/libinput-device.c | 317 +++ > > src/libinput-device.h | 4 +- > > 16 files changed, 3024 insertions(+), 5 deletions(-) > > create mode 100644 clients/tablet.c > > create mode 100644 protocol/wayland-tablet.xml > > > > Hi, > > just a heads-up, do I get the right impression that this is not yet in > a shape to merge into Weston, so won't be included in 1.6? Yes. The libinput side of tablet support still live on a separate branch, so merging this series is not an option for 1.6 IMHO. Jonas > > Could an input person review this and suggest whether this should in > his opinion get merged for 1.6 and is it reasonable to assume, that all
[PATCH] cliptest: Don't underrun the vertex array of empty polygons.
This silences the following warning:
clients/cliptest.c:277:22: warning: array subscript is below array
bounds [-Warray-bounds]
ctx->prev.x = src->x[src->n - 1];
Signed-off-by: Ondřej Majerech
---
clients/cliptest.c | 12
1 file changed, 12 insertions(+)
diff --git a/clients/cliptest.c b/clients/cliptest.c
index 907c5d4..20b3776 100644
--- a/clients/cliptest.c
+++ b/clients/cliptest.c
@@ -287,6 +287,9 @@ clip_polygon_left(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src->n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i < src->n; i++) {
trans = path_transition_left_edge(ctx, src->x[i], src->y[i]);
@@ -303,6 +306,9 @@ clip_polygon_right(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src->n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i < src->n; i++) {
trans = path_transition_right_edge(ctx, src->x[i], src->y[i]);
@@ -319,6 +325,9 @@ clip_polygon_top(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src->n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i < src->n; i++) {
trans = path_transition_top_edge(ctx, src->x[i], src->y[i]);
@@ -335,6 +344,9 @@ clip_polygon_bottom(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src->n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i < src->n; i++) {
trans = path_transition_bottom_edge(ctx, src->x[i], src->y[i]);
--
2.0.4
___
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
On Wed, 16 Jul 2014 11:13:06 +0300
Giulio Camuffo wrote:
> 2014-07-15 20:39 GMT+03:00 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.
>
> I didn't realize you could read it as "queue a roundtrip on a
> wl_event". I think that the meaning is quite obvious once you know
> that there is a wl_event_queue type in Wayland.
Hi,
hm, that's a tricky one. Yes, the name wl_event_queue_roundtrip() is
confusing when out of context, but as the argument is a wl_event_queue,
that name is the logical and unfortunate result.
Another problem with wl_display_roundtrip_queue() is that it gets both
wl_display and wl_event_queue as arguments. Therefore the function
would need to check that the wl_event_queue indeed belongs to the given
wl_display. It's just a thing one can get wrong, and it has no benefits
that I see.
wl_display_roundtrip_queue() taking only wl_event_queue as an argument
would be strange, because the name implies a wl_display method.
(Up until this point, I would have agreed with Giulio and Jason...)
But, now I see, that we already have:
int wl_display_dispatch_queue(struct wl_display *display,
struct wl_event_queue *queue);
int wl_display_dispatch_queue_pending(struct wl_display *display,
struct wl_event_queue *queue);
int wl_display_prepare_read_queue(struct wl_display *display,
struct wl_event_queue *queue);
So there is precendent, that redundant arguments are ok, and
wl_display_roundtrip_queue() would indeed follow the existing scheme.
Btw. I do not see anywhere, where the libwayland-client code would be
checking that the wl_display and the wl_event_queue would actually be
related. Would be a good thing to add more checks to the public API
functions for that.
I think I would go with wl_display_roundtrip_queue() here. Would you
agree?
Thanks,
pq
> >> > 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
> >> >> + *
> >> >> + * Bloc
Re: [PATCH 3/3] tests: add one more test for event-loop signal source
On 18 August 2014 12:23, Marek Chalupa wrote:
> Hi,
>
> thanks for reviewing.
>
> The failure you got is not introduced by this patch, I reported it some
> time ago here:
> https://bugs.freedesktop.org/show_bug.cgi?id=80594
>
I put a patch for this bug into bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=80594
>
>
>
> On 18 August 2014 12:18, Pekka Paalanen wrote:
>
>> On Tue, 12 Aug 2014 11:35:07 +0200
>> Marek Chalupa wrote:
>>
>> > Test if when we get a signal, all signal sources for that signal
>> > get dispatched.
>> >
>> > Signed-off-by: Marek Chalupa
>> > ---
>> > tests/event-loop-test.c | 38 ++
>> > 1 file changed, 38 insertions(+)
>> >
>> > diff --git a/tests/event-loop-test.c b/tests/event-loop-test.c
>> > index e327a66..1709a1a 100644
>> > --- a/tests/event-loop-test.c
>> > +++ b/tests/event-loop-test.c
>> > @@ -173,6 +173,44 @@ TEST(event_loop_signal)
>> > wl_event_loop_destroy(loop);
>> > }
>> >
>> > +TEST(event_loop_multiple_same_signals)
>> > +{
>> > + struct wl_event_loop *loop = wl_event_loop_create();
>> > + struct wl_event_source *s1, *s2;
>> > + int calls_no = 0;
>> > + int i;
>> > +
>> > + s1 = wl_event_loop_add_signal(loop, SIGUSR1,
>> > + signal_callback, &calls_no);
>> > + assert(s1);
>> > +
>> > + s2 = wl_event_loop_add_signal(loop, SIGUSR1,
>> > + signal_callback, &calls_no);
>> > + assert(s2);
>> > +
>> > + assert(wl_event_loop_dispatch(loop, 0) == 0);
>> > + assert(!calls_no);
>> > +
>> > + /* Try it more times */
>> > + for (i = 0; i < 5; ++i) {
>> > + calls_no = 0;
>> > + kill(getpid(), SIGUSR1);
>> > + assert(wl_event_loop_dispatch(loop, 0) == 0);
>> > + assert(calls_no == 2);
>> > + }
>> > +
>> > + wl_event_source_remove(s1);
>> > +
>> > + /* Try it again with one source */
>> > + calls_no = 0;
>> > + kill(getpid(), SIGUSR1);
>> > + assert(wl_event_loop_dispatch(loop, 0) == 0);
>> > + assert(calls_no == 1);
>> > +
>> > + wl_event_source_remove(s2);
>> > +
>> > + wl_event_loop_destroy(loop);
>> > +}
>> >
>> > static int
>> > timer_callback(void *data)
>>
>> The first two of the three patches pushed. We have an explicit configure
>> check from SFD_CLOEXEC, but I suppose we don't need to add one for
>> SFD_NONBLOCK, because the two were supposedly introduced at the same
>> time in glibc.
>>
>> I did not push this third patch, because in my testing, the test failed
>> once. It was very hard, but I did manage to trigger it a second time
>> too, by having lots of CPU and IO load on the machine and running the
>> test in loop until it failed:
>>
>> test "event_loop_destroy": exit status 0, pass.
>> event-loop-test: tests/event-loop-test.c:298: event_loop_timer_updates:
>> Assertion `context.count == 2' failed.
>> test "event_loop_timer_updates":signal 6, fail.
>> test "event_loop_timer":exit status 0, pass.
>> test "event_loop_multiple_same_signals":exit status 0, pass.
>> test "event_loop_signal": exit status 0, pass.
>> test "event_loop_free_source_with_data":exit status 0, pass.
>> test "event_loop_post_dispatch_check": exit status 0, pass.
>> 7 tests, 6 pass, 1 fail
>>
>> I would like to see some fix on that, even if only theoretical, before
>> I push this one.
>>
>> Or an ack from someone else that we should just push this and wait for
>> the fallout if any.
>>
>>
>> Thanks,
>> pq
>>
>
> Regards,
> Marek
>
Regards,
Marek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] configure.ac: use libinput by default
From: Pekka Paalanen Libinput is stabilizing soon, so let's flip the default switch now. The old input code will still be carried as an option for a while. Cc: Peter Hutterer Cc: Jonas Ådahl Signed-off-by: Pekka Paalanen --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 354db14..bc5c88a 100644 --- a/configure.ac +++ b/configure.ac @@ -155,8 +155,8 @@ if test x$enable_drm_compositor = xyes; then fi -AC_ARG_ENABLE(libinput-backend, [ --enable-libinput-backend],, - enable_libinput_backend=no) +AC_ARG_ENABLE(libinput-backend, [ --disable-libinput-backend],, + enable_libinput_backend=yes) AM_CONDITIONAL([ENABLE_LIBINPUT_BACKEND], [test x$enable_libinput_backend = xyes]) if test x$enable_libinput_backend = xyes; then AC_DEFINE([BUILD_LIBINPUT_BACKEND], [1], [Build the libinput input device backend]) -- 1.8.5.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/19] Basic tablet support in Weston
On Wed, 6 Aug 2014 19:07:50 -0400 Stephen Chandler Paul wrote: > Hi! As some of you have been aware, I have been working on implementing tablet > ssupport in libinput, the wayland protocol and weston. This patchset adds > basic > tablet support to weston, along with support in the shell and the window > manager. It should be noted that these patches rely on one of the earlier > patches to libinput that I posted on the mailing list: "tablet: Add > libinput_tablet_has_axis()", along with the tablet-support branch in the git > repository for libinput. > > As of right now, the following things are still missing/haven't been finished > yet: > * Tablet objects don't ever send a removed event, right now it's up to the > clients to free the resources for each tool object. > * Tablet tool objects should be separate for each tablet connected that > doesn't > report serial numbers. Right now tablet objects are shared by all tablets > connected to the system unconditionally. > * The tablet cursor disappears occasionally when moving a window and causing > the mouse pointer to change images, but reappears the next time a client > sets > a cursor image. > * weston-flower can crash the shell for some reason. It seems that if a tablet > is turned on, and the first surface the tool comes into focus on belongs to > a > weston-flower instance, the desktop-shell runs into an error and exits. I > haven't noticed this with anything other then weston-flower though. > * Held down buttons are released when the tool changes focus from one surface > to another, instead of being held down until they're released. > * Some of the declarations for structs in my code might need to be moved > around, I'm not sure what the expected guidelines for this in weston's code > are though. > * A surface argument needs to be added to the proximity_out event, so we can > tell if the tablet tool is leaving proximity to switch focus to another > surface, or if it's just exiting proximity. > > Review/critique would be appreciated, thank you! ^^ > > Cheers, > Lyude > > Stephen Chandler Paul (19): > tablet: Add XML for wl_tablet and wl_tablet_manager > tablet: Add initial tablet support to weston > client: Add support for handling motion events in toytoolkit > client: Add support for handling proximity_in/out events in > libtoytoolkit > tablet: Add support for setting/changing the tablet cursor in weston > client: Add tablet cursor support into libtoytoolkit > tablet: Add support for tablet tool objects > client: Add support for tool objects in libtoytoolkit > client: Add support for tablet cursor motion to window frames in > libtoytoolkit > tablet: Add support for button presses to weston > client: Add support for handling button presses to libtoytoolkit > tablet: Add support for up/down events to weston > client: Add up/down event support into libtoytoolkit > tablet: Add support for moving windows around using the stylus > tablet: Add support for reporting pressure, distance, and tilt in > weston > client: Add support for pressure, distance, and tilt into > libtoytoolkit > tablet: Add tablet support to the top panel of the desktop shell > tablet: Add binding to activate surfaces using the tablet tool > tablet: Add demo application for tablets > > .gitignore | 1 + > Makefile.am | 23 +- > clients/desktop-shell.c | 55 > clients/tablet.c| 341 > clients/window.c| 607 > clients/window.h| 102 ++ > desktop-shell/shell.c | 282 + > protocol/wayland-tablet.xml | 310 +++ > shared/cairo-util.h | 4 + > shared/frame.c | 38 +++ > src/bindings.c | 37 +++ > src/compositor.c| 1 + > src/compositor.h| 171 ++ > src/input.c | 736 > > src/libinput-device.c | 317 +++ > src/libinput-device.h | 4 +- > 16 files changed, 3024 insertions(+), 5 deletions(-) > create mode 100644 clients/tablet.c > create mode 100644 protocol/wayland-tablet.xml > Hi, just a heads-up, do I get the right impression that this is not yet in a shape to merge into Weston, so won't be included in 1.6? Could an input person review this and suggest whether this should in his opinion get merged for 1.6 and is it reasonable to assume, that all the remaining known bugs can be sufficiently fixed within the couple of weeks or so that our alpha and RC phase lasts? I still haven't read the latest protocol discussion thread, so I'm not sure where the design is atm. Personally I cannot even test this, since I don't have a tablet device here. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop
Re: [PATCH] cliptest: Avoid use of uninitialized memory when regions don't intersect
On Mon, 18 Aug 2014 16:13:41 -0500
Derek Foreman wrote:
> Prevent attempting to draw the intersection polygon when it contains no
> vertices.
>
> Signed-off-by: Derek Foreman
> ---
> clients/cliptest.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/clients/cliptest.c b/clients/cliptest.c
> index a1928f4..dd0ea5c 100644
> --- a/clients/cliptest.c
> +++ b/clients/cliptest.c
> @@ -570,12 +570,14 @@ draw_geometry(cairo_t *cr, struct weston_surface
> *surface,
Hi Derek,
looks like your email client decided to wrap the patch and it didn't
apply, so I fixed it and applied.
> cairo_set_source_rgba(cr, 0.0, 0.0, 1.0, 0.4);
> cairo_fill(cr);
>
> - draw_polygon_closed(cr, ex, ey, n);
> - cairo_set_source_rgb(cr, 0.0, 1.0, 0.0);
> - cairo_stroke(cr);
> + if (n) {
> + draw_polygon_closed(cr, ex, ey, n);
> + cairo_set_source_rgb(cr, 0.0, 1.0, 0.0);
> + cairo_stroke(cr);
>
> - cairo_set_source_rgba(cr, 0.0, 1.0, 0.0, 0.5);
> - draw_polygon_labels(cr, ex, ey, n);
> + cairo_set_source_rgba(cr, 0.0, 1.0, 0.0, 0.5);
> + draw_polygon_labels(cr, ex, ey, n);
> + }
> }
>
> static void
Looks good, pushed.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Fixes to parse_options, help info from display
On Fri, 8 Aug 2014 12:59:49 -0700 Bill Spitzak wrote: > These are a series of changes, you can pick and choose from them if you don't > like them all. > > There are fixes to the parser so that "x=5mm" and "bool=false" and other > constucts are errors > rather than doing unintuitive things. > > Also I tried to get most of the weston demo programs to print some help if -h > is given or > if there is an error in the command line. The eventdemo one in particular, > since the web > page for building claims --help will give you some help. Note this is just > done quickly > without extensive rewrite, so in most cases it does not distinguish -h from > errors and > returns an error code in both cases. I don't think it is necessary to > complicate the > demo programs more than this. Hi, comments on the patches I did not apply have already been sent: 1, 12v2. Patches 7 and 8 I amended to fix minor style issues. Patch 2 should really have been split into two, a separate one to fix the erroneous -0 option, but I let it in. Patches 2-11 pushed. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 01/12] Fixes to parse_options
On Fri, 8 Aug 2014 12:59:50 -0700
Bill Spitzak wrote:
> Fail on malformed numbers, such as --width=100mm
Good.
> Fail on = after booleans, such as --flag=false
Okay.
> Multiple single-letter booleans in one switch allowed, ie
> -xyz is the same as -x -y -z. For wayland modules they all have
> to belong to the same module.
This was not accepted before, right? It is confusing that one needs to
know that they are from the same module, so I'd rather just not accept
combined single letter booleans at all.
> Previous version could use text after the null at the end of
> an argv entry. Now requires the = sign.
What does this mean? I mean, how could one have ever used the old
behaviour? Nothing comes to my mind, so I suppose that is ok.
There are some style issues. First is the patch subject, it should be
prefixed with the component the patch is touching. To get a feeling
what the components are, look at the git-log of the file your are
changing, and there should be a pattern.
Though, I see that option-parser.c doesn't really have any pattern. Oh
well, "shared:" should do then.
More style issues below.
> ---
> shared/option-parser.c | 82
> +++-
> 1 file changed, 53 insertions(+), 29 deletions(-)
>
> diff --git a/shared/option-parser.c b/shared/option-parser.c
> index c00349a..22bcf2f 100644
> --- a/shared/option-parser.c
> +++ b/shared/option-parser.c
> @@ -30,53 +30,77 @@
>
> #include "config-parser.h"
>
> -static void
> +static int
> handle_option(const struct weston_option *option, char *value)
> {
> + char* p;
Need empty line between declarations and code.
> switch (option->type) {
> case WESTON_OPTION_INTEGER:
> - * (int32_t *) option->data = strtol(value, NULL, 0);
> - return;
> + * (int32_t *) option->data = strtol(value, &p, 0);
> + return p > value && !*p;
Took me a couple of times to read this return statement.
How about:
return *value != '\0' && *p == '\0';
Just a suggestion, doesn't matter.
> case WESTON_OPTION_UNSIGNED_INTEGER:
> - * (uint32_t *) option->data = strtoul(value, NULL, 0);
> - return;
> + * (uint32_t *) option->data = strtoul(value, &p, 0);
> + return p > value && !*p;
> case WESTON_OPTION_STRING:
> * (char **) option->data = strdup(value);
> - return;
> - case WESTON_OPTION_BOOLEAN:
> - * (int32_t *) option->data = 1;
> - return;
> + return 1;
> default:
> assert(0);
> }
> }
>
> +static int
> +long_option(const struct weston_option *options, int count, char* arg)
> +{
> + int k, len;
Need empty line between declarations and code.
> + for (k = 0; k < count; k++) {
> + if (! options[k].name) continue;
No space after in (! options[k].name).
'continue' should be on a new line
> + len = strlen(options[k].name);
> + if (strncmp(options[k].name, arg+2, len) != 0) continue;
add spaces: arg + 2
'continue' should be on a new line
> + if (options[k].type == WESTON_OPTION_BOOLEAN) {
> + if (! arg[len+2]) {
Extra space.
> + * (int32_t *) options[k].data = 1;
> + return 1;
> + }
> + } else if (arg[len+2] == '=') {
spaces: len + 2
> + return handle_option(options+k, arg+len+3);
spaces: options + k, arg + len + 3
> + }
> + }
> + return 0;
> +}
> +
> +static int
> +short_option(const struct weston_option *options, int count, char* arg)
> +{
> + int i, k;
Need empty line between declarations and code.
> + for (i = 1; arg[i]; i++) {
> + for (k = 0; ; k++) {
> + if (k >= count) return 0;
'return' to a new line.
> + if (options[k].short_name == arg[i]) break;
'break' to a new line.
> + }
> + if (options[k].type == WESTON_OPTION_BOOLEAN)
> + * (int32_t *) options[k].data = 1;
> + else
> + return handle_option(options+k, arg+i+1);
missing spaces
> + }
> + return arg[1]; /* error on just '-' */
Implicit cast to a "boolean" is kind of surprising, a comparison would
be more obvious:
return arg[1] != '\0';
Or better yet, just exit the function in the first lines, if arg[1] ==
'\0'.
> +}
> +
> +
> int
> parse_options(const struct weston_option *options,
> int count, int *argc, char *argv[])
> {
> - int i, j, k, len = 0;
> -
> + int i, j;
Need empty line between declarations and code.
> for (i = 1, j = 1; i < *argc; i++) {
> - for (k = 0; k < count; k++) {
> - if (options[k].name)
> - len = strlen(options[k].name);
> - if (options[k].na
Re: [PATCH] V2: load_image always prints a message on failure if filename is not empty
On Mon, 11 Aug 2014 14:28:38 -0700
Bill Spitzak wrote:
> Small change to remove the trailing whitespace error.
>
> It was rather inconsistent before. This may help users figure out why
> backgrounds and icons don't show up. A better api where the error can
> be queried might be nice, but this seems sufficient for current Weston use.
> ---
> clients/image.c |1 -
> shared/image-loader.c | 11 +--
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/clients/image.c b/clients/image.c
> index 573117c..aee8112 100644
> --- a/clients/image.c
> +++ b/clients/image.c
> @@ -373,7 +373,6 @@ image_create(struct display *display, const char
> *filename,
> image->image = load_cairo_surface(filename);
>
> if (!image->image) {
> - fprintf(stderr, "could not find the image %s!\n", b);
This is an unrelated change, and needs to be in a different patch.
> free(image->filename);
> free(image);
> return NULL;
> diff --git a/shared/image-loader.c b/shared/image-loader.c
> index 35dadd3..f04fb48 100644
> --- a/shared/image-loader.c
> +++ b/shared/image-loader.c
> @@ -23,6 +23,7 @@
>
> #include "config.h"
>
> +#include
> #include
> #include
> #include
> @@ -374,12 +375,15 @@ load_image(const char *filename)
> FILE *fp;
> unsigned int i;
>
> + if (! filename || ! *filename) return NULL;
Extra spaces, needs new line for 'return'.
> +
> fp = fopen(filename, "rb");
> - if (fp == NULL)
> - return NULL;
> + if (fp == NULL) goto ERROR;
Needs new line for 'goto'.
>
> if (fread(header, sizeof header, 1, fp) != 1) {
> fclose(fp);
> + ERROR:
Jump into a block? Looks nasty, usually we do this like
return ...;
foofoo:
fclose();
foobar:
fprintf(...);
return NULL;
}
> + fprintf(stderr, "%s: %s\n", filename, strerror(errno));
> return NULL;
> }
>
> @@ -399,6 +403,9 @@ load_image(const char *filename)
> "0x%02x 0x%02x 0x%02x 0x%02x\n",
> filename, header[0], header[1], header[2], header[3]);
> image = NULL;
> + } else if (!image) {
> + /* load probably printed something, but just in case */
> + fprintf(stderr, "error reading image file %s!\n", filename);
> }
>
> return image;
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v2] protocol: define the concept of wl_surface role
On Tue, 19 Aug 2014 10:29:21 +0300 Pekka Paalanen wrote: > From: Pekka Paalanen > > Define what a role is, and what restrictions there are. > > A change to existing behaviour is that a role cannot be changed at all > once set. However, this is unlikely to cause problems, as there is no > reason to re-use wl_surfaces in clients. > > v2: give more concrete examples of roles, define losing a role, Jasper > rewrote the paragraph on how a role is set. > > Signed-off-by: Pekka Paalanen > --- > protocol/wayland.xml | 26 -- > 1 file changed, 24 insertions(+), 2 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 2d57f69..d3fcaec 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -973,8 +973,30 @@ >local coordinates of the pixel content, in case a buffer_transform >or a buffer_scale is used. > > - Surfaces are also used for some special purposes, e.g. as > - cursor images for pointers, drag icons, etc. > + A surface without a "role" is fairly useless, a compositor does > + not know where, when or how to present it. The role is the > + purpose of a wl_surface. Examples of roles are a cursor for a > + pointer (as set by wl_pointer.set_cursor), a drag icon > + (wl_data_device.start_drag), a sub-surface > + (wl_subcompositor.get_subsurface), and a window as defined by a > + shell protocol (e.g. wl_shell.get_shell_surface). > + > + A surface can have only one role at a time. Initially a > + wl_surface does not have a role. Once a wl_surface is given a > + role, it can never be given a different role again, even if the > + wl_surface loses the role in between. > + > + Surface roles are set by requests in other interfaces such as Bah... forgot to save one tiny change: "Surface roles are given by ..." ---^ Thanks, pq > + wl_pointer.set_cursor. The request should explicitly mention > + that this request gives a role to a wl_surface. Often, this > + request also creates a new protocol object that represents the > + role and adds additional functionality to wl_surface. When a > + client wants to destroy a wl_surface, they must destroy this 'role > + object' before the wl_surface. > + > + A wl_surface may lose its role as specified in the interface > + that gave it the role or in the interface of the role object. > + Losing a role means losing all the role-specific state. > > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The road to Wayland/Weston 1.6 and 1.5.1
On Tue, 19 Aug 2014 16:38:42 +0900 "Tanibata, Nobuhiko \(ADITJ/SWG\)" wrote: > > -Original Message- > > From: wayland-devel > [mailto:wayland-devel-boun...@lists.freedesktop.org] > > On Behalf Of Pekka Paalanen > > Sent: Monday, August 18, 2014 8:36 PM > > To: wayland-devel@lists.freedesktop.org; k...@bitplanet.net > > Cc: Jasper St. Pierre; U. Artie Eoff > > Subject: The road to Wayland/Weston 1.6 and 1.5.1 > > > > Hi all, > > > > in the release announcement of 1.5.0[1] it was said that the alpha > release > > towards 1.6 should come out mid-August. That time is now, so how about > we > > target Friday, Aug 22nd (European time)? > > > > I know the review process has been lagging behind badly, and we > probably won't > > see e.g. IVI-shell merged for 1.6, but I try to do what I can. What > major > > features have been forgotten on the mailing list unmerged, that you > would > > like to see included in 1.6? > [ntanibata] Hi pq, > Thank you for notification. Patches of ivi-shell were improved with your > comment and the latest patch set is sent to the mailing list. > http://lists.freedesktop.org/archives/wayland-devel/2014-June/015616.htm > l > http://lists.freedesktop.org/archives/wayland-devel/2014-July/015968.htm > l > http://lists.freedesktop.org/archives/wayland-devel/2014-July/015969.htm > l > http://lists.freedesktop.org/archives/wayland-devel/2014-July/015970.htm > l > I will try to verify them on > > Trankyo, Manuel, provides them in his github for trial as well: > https://github.com/Tarnyko/weston-ivi-shell > These ones are reviewed in upstream branch of TIZEN gerrit and verified. > This would be good opportunity to merge them to 1.6. > I am also working enabling ivi-shell support with efl and Qt, getting > help with Manuel and his colleges. Thanks for keeping up. For the record, I am deliberately keeping your IVI-shell comments and patches marked in my inbox with the hope that one day I get back to it. :-) I think there are still some things that need fixing, but my review has to wait as I need to prioritize. Sorry. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: The road to Wayland/Weston 1.6 and 1.5.1
> -Original Message- > From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] > On Behalf Of Pekka Paalanen > Sent: Monday, August 18, 2014 8:36 PM > To: wayland-devel@lists.freedesktop.org; k...@bitplanet.net > Cc: Jasper St. Pierre; U. Artie Eoff > Subject: The road to Wayland/Weston 1.6 and 1.5.1 > > Hi all, > > in the release announcement of 1.5.0[1] it was said that the alpha release > towards 1.6 should come out mid-August. That time is now, so how about we > target Friday, Aug 22nd (European time)? > > I know the review process has been lagging behind badly, and we probably won't > see e.g. IVI-shell merged for 1.6, but I try to do what I can. What major > features have been forgotten on the mailing list unmerged, that you would > like to see included in 1.6? [ntanibata] Hi pq, Thank you for notification. Patches of ivi-shell were improved with your comment and the latest patch set is sent to the mailing list. http://lists.freedesktop.org/archives/wayland-devel/2014-June/015616.htm l http://lists.freedesktop.org/archives/wayland-devel/2014-July/015968.htm l http://lists.freedesktop.org/archives/wayland-devel/2014-July/015969.htm l http://lists.freedesktop.org/archives/wayland-devel/2014-July/015970.htm l I will try to verify them on Trankyo, Manuel, provides them in his github for trial as well: https://github.com/Tarnyko/weston-ivi-shell These ones are reviewed in upstream branch of TIZEN gerrit and verified. This would be good opportunity to merge them to 1.6. I am also working enabling ivi-shell support with efl and Qt, getting help with Manuel and his colleges. BR, Nobuhiko Tanibata > > I can't promise anything, and I know at least none of my new features > (Presentation extension, new repaint scheduling algorithm, repaint timeline > logging, DRM universal planes & nuclear pageflip support, linux_dmabuf > protocol sketch, and some smaller things) brewing in my personal 'next' branch > will not make it. > > Obviously a stable first version of xdg_shell would be great to see in 1.6, > but we shall see if we can beat it into shape in time. When I reviewed the > XML spec not long ago, it was close but not ready in my opinion. > > When xdg_shell does stabilize, we will move xdg_shell.xml into Wayland > repository and it will be installed, but all build-time users of it must > generate their own wrappers with wayland-scanner or equivalent. This means > that libwayland-client will not contain any xdg_shell symbols or headers > pre-generated. I asked Kristian and he was ok with this plan, and I have also > talked a little on #wayland-devel, that maybe this would be a good idea. If > this turns out a bad idea, we can always fix it later. Doing it the other > way around would be near impossible. > > Should we make libinput the default for 1.6, so that in 1.7 we can remove > the old input code, or is libinput API still too much in flux? > > > Also, it was said that 1.5.1 should have come out in "a few weeks" and it > has been 3 months now. I will try and check the patches already in 'master' > of both Wayland and Weston and pick them to the 1.5 branches, but if you know > of patches that should be in stable, especially ones without review or not > in 'master', let me know and I try do something. > My selection, especially for Wayland, will probably be very conservative, > though, as my priority is 1.6. > > > Thanks, > pq > > [1] > http://lists.freedesktop.org/archives/wayland-devel/2014-May/014955.html > ___ > 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
[PATCH wayland v2] protocol: define the concept of wl_surface role
From: Pekka Paalanen Define what a role is, and what restrictions there are. A change to existing behaviour is that a role cannot be changed at all once set. However, this is unlikely to cause problems, as there is no reason to re-use wl_surfaces in clients. v2: give more concrete examples of roles, define losing a role, Jasper rewrote the paragraph on how a role is set. Signed-off-by: Pekka Paalanen --- protocol/wayland.xml | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..d3fcaec 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -973,8 +973,30 @@ local coordinates of the pixel content, in case a buffer_transform or a buffer_scale is used. - Surfaces are also used for some special purposes, e.g. as - cursor images for pointers, drag icons, etc. + A surface without a "role" is fairly useless, a compositor does + not know where, when or how to present it. The role is the + purpose of a wl_surface. Examples of roles are a cursor for a + pointer (as set by wl_pointer.set_cursor), a drag icon + (wl_data_device.start_drag), a sub-surface + (wl_subcompositor.get_subsurface), and a window as defined by a + shell protocol (e.g. wl_shell.get_shell_surface). + + A surface can have only one role at a time. Initially a + wl_surface does not have a role. Once a wl_surface is given a + role, it can never be given a different role again, even if the + wl_surface loses the role in between. + + Surface roles are set by requests in other interfaces such as + wl_pointer.set_cursor. The request should explicitly mention + that this request gives a role to a wl_surface. Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. + + A wl_surface may lose its role as specified in the interface + that gave it the role or in the interface of the role object. + Losing a role means losing all the role-specific state. -- 1.8.5.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Help]Question about graphics architecture for weson/wayland
On Tue, 19 Aug 2014 06:59:22 + Yang Andy said: > Hi Pekka > > Thank you very much for your reply. > > > If you have a DRM kernel driver supporting KMS, use Weston's drm-backend > > but pass --use-pixman on the command line. > > DRM kernel driver is for display device? Not for GPU? > > In other words,i can use drm-backend even though i have no GPU device. you may not have a drm driver for your hardware, but nothing stops you having fdrm and kms drivers even without a 3d gpu. you may havd 2d accel hardware that you want to manage or just simply buffer allocation/management (a lot of older hardware requires display buffers to be in linear/physical (not virtual) memory and thus requires a specialized allocator. some requires it to be in specific physical memory ranges (an older soc i know requires all gfx buffers for display and 2d accel to be inside the first physical 16mb of ram - on even older hardware before my linux days all gfx primitives, sprites, cursors, audio data, fb scanout control commands and floppy disk i/o data had to reside in the same 512kb and if it didn't it was the cpu's job to get it to/from there). if clients software rendered, but used drm buffers to render into, then it might be possible for the compositor (eg weston) if it knows it can, to program hardware layers or fbs to point directly to these buffers to scan-out from. this is how you get truly zero-copy display/output, but it would require that client uses drm directly to allocate buffers, use software to render (or whatever it likes actually), then sends compositor drm buffers. as such this is on a "eventually we will do this" plan for efl, but as it is not easy to support drm in a universal way to allocate buffers for scanout/display (not the last time i looked), we've got that on the back-burner. if one day there are api's we could use where we can allocate "drm buffers" an d ensure they are linear (or of a specific format) or query them for the layouts we do support (tiled vs linear), and can request properties on allocation - eg "can scan out" "can be used as pointer" "can be used as texture" etc. then that'd be awesome and we'd use it for our software rendering (and have a wayland_software_drm engine or something - or maybe make the shm engine detect this if it is available and auto use if it works). but we don't have that today because last i looked.. no such thing exists that we can use - someone correct me if something has changed... please! :) > Andy > > Date: Tue, 19 Aug 2014 09:44:14 +0300 > > From: ppaala...@gmail.com > > To: williamyan...@hotmail.com > > CC: ras...@rasterman.com; wayland-devel@lists.freedesktop.org > > Subject: Re: [Help]Question about graphics architecture for weson/wayland > > > > On Tue, 19 Aug 2014 02:20:58 + > > Yang Andy wrote: > > > > > My senario is that my target device do not support hardware > > > accelerate.(do not use gpu) But i have to use EFL to develop > > > application in wayland/weston platform. > > > > > > In order to achieve my task,how do i setup weston? > > > > Oh, so this was your real question. > > > > If you have a DRM kernel driver supporting KMS, use Weston's drm-backend > > but pass --use-pixman on the command line. > > > > If you do not have a DRM driver, but you do have /dev/fb0, use Weston's > > fbdev-backend. > > > > > > Thanks, > > pq > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: define the concept of wl_surface role
On Mon, 18 Aug 2014 10:32:28 -0400 "Jasper St. Pierre" wrote: > On Mon, Aug 18, 2014 at 10:14 AM, Pekka Paalanen > wrote: > > > From: Pekka Paalanen > > > > Define what a role is, and what restrictions there are. > > > > A change to existing behaviour is that a role cannot be changed at all > > once set. However, this is unlikely to cause problems, as there is no > > reason to re-use wl_surfaces in clients. > > > > Thanks for this. I was going to add it in the Publican docs, but those are > significantly out of date and I spent more time laughing at them than > writing things in them. We should fix that. :( Yeah... > Looks good overall. I'm going to be a terrible person and nitpick your > grammar. Sorry about that in advance! Ha! Good that someone cares about that once in a while. :-) > > Signed-off-by: Pekka Paalanen > > --- > > protocol/wayland.xml | 20 ++-- > > 1 file changed, 18 insertions(+), 2 deletions(-) > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 2d57f69..39af61f 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -973,8 +973,24 @@ > >local coordinates of the pixel content, in case a buffer_transform > >or a buffer_scale is used. > > > > - Surfaces are also used for some special purposes, e.g. as > > - cursor images for pointers, drag icons, etc. > > + A surface without a "role" is fairly useless, a compositor does not > > + know where, when or how to present it. The role is the purpose of a > > + wl_surface. Examples of roles are a cursor for a pointer, a drag > > icon, > > + a sub-surface, and a window as defined by a shell protocol. > > > > I'd give more concrete examples. "Examples of surface roles include the > pointer icon (as set by wl_pointer.set_cursor), a drag icon (as set by > wl_data_device.start_drag), ..." I actually though of that but didn't bother, will add. > + A surface can have only one role at a time. Initially a wl_surface > > + does not have a role. Once a role is set, it can never be set to a > > + different role again. > > > > There is an important clarification here. If I have two surfaces like > "pointer cursor", "I-beam cursor", I can call wl_pointer.set_cursor on > either of them in succession. I could imagine someone being confused that > "the pointer icon" role is a singleton, and when the I-beam cursor gains > it, the pointer cursor loses it, and she might think that you would have to > create a new wl_surface since it's illegal to set the wl_pointer.set_cursor > role on the pointer cursor surface again. Hmm, I thought the "different" was enough to say that. Roles are not singletons either. > What we're trying to do is prevent surface reuse, so you can't transform > something that was once a pointer cursor into a wl_subsurface or anything > like that. Exactly. > I'm not really sure how to describe this, though. I'm not too happy with > this, but it's the best I came up with. > > "A surface can only have one role at a time. When you first make a request > to set a surface's role, the surface can then only have that role forever, > even if it loses the role. For instance, if somebody sets the 'subsurface' > role on a wl_surface, then it can only ever be a subsurface, even if you > destroy the associated wl_subsurface object" > > We should probably describe the concept of "losing the role" from e.g. > wl_subsurface.destroy, wl_pointer.set_cursor above. I'll think about it. > + A role is set by a request in another interface than wl_surface > > + itself. The protocol specification of the other interface > > + defines, that the request gives a specific role to a wl_surface. > > + Often, this request also creates a new protocol object, that > > + represents the role and extends the interface to the wl_surface. > > + If such a new protocol object is created, clients are > > + recommended to destroy it before they destroy the wl_surface. > > + Whether destroying the wl_surface first is legal, depends on the > > + protocol interface related to the role. > > > > I know you're a non-native speaker, so I won't bash your grammar in-depth. > I'll just offer a replacement paragraph with everything fixed up. I'm also > going to strengthen up the wording here a bit. > > "Surface roles are set by requests in other interfaces such as > wl_pointer.set_cursor. The request should explicitly mention that this > request gives a role to a wl_surface. Often, this request also creates a > new protocol object that represents the role and adds additional > functionality to wl_surface. When clients want to destroy a surface, they > must destroy this 'role object' before the wl_surface, except when > specified otherwise." Okay, that is also compatible with both wl_subsurface and wl_shell_surface. > We should also change the description of wl_subsurface to say that > destroying the wl_surface bef
Re: [PATCH libinput] evdev: allow weird multitouch device without slots
On Tue, Aug 19, 2014 at 06:29:40AM +0300, Leonid Borisenko wrote:
> HID device 'USB HID v1.11 Mouse' provided by Microsoft Wireless Optical
> Desktop® 2.20 (connected to USB and identified as vendor 0x45e, product
> 0xe3, version 0x111) is reported as supporting EV_ABS event with ABS_MT_SLOT
> code, but nevertheless libevdev_get_num_slots returns -1.
yeah, that's intentional. libevdev detects those devices (through guesswork,
but still...) and returns -1 as slot number.
> Furthermore, all connected devices (mouse and keyboard) don't produce any
> EV_ABS events for that HID Mouse device in tests with evtest.
>
> Before this fix mouse didn't work in Weston (but worked in X.Org).
>
> As partially explained by LKML message [1] (Message-Id [2]):
>
> The root of the problem comes from hid-input, which maps unknown axis
> to ABS_MISC. However, when an event code is already in use, hid-input
> uses the one after, leading to uses of ABS_MISC + N, where N is the
> number of unknown axis.
>
> We are encountering a problem with the multitouch protocol here because
> if a device has more than 7 unknown axis (which is the case for the PS3
> Sixaxis controller), then the unknown axis get maps to ABS_MT_SLOT and
> beyond.
>
> [1] https://lkml.org/lkml/2013/11/20/515
> [2] 1384983141-31019-1-git-send-email-benjamin.tissoi...@redhat.com
>
> Signed-off-by: Leonid Borisenko
> ---
> src/evdev.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/src/evdev.c b/src/evdev.c
> index a125510..d6a14b7 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -144,7 +144,7 @@ evdev_flush_pending_event(struct evdev_device *device,
> uint64_t time)
> pointer_notify_motion(base, time, motion.dx, motion.dy);
> break;
> case EVDEV_ABSOLUTE_MT_DOWN:
> - if (!(device->seat_caps & EVDEV_DEVICE_TOUCH))
> + if (slot == -1 || !(device->seat_caps & EVDEV_DEVICE_TOUCH))
> break;
>
> if (device->mt.slots[slot].seat_slot != -1) {
> @@ -167,7 +167,7 @@ evdev_flush_pending_event(struct evdev_device *device,
> uint64_t time)
> touch_notify_touch_down(base, time, slot, seat_slot, x, y);
> break;
> case EVDEV_ABSOLUTE_MT_MOTION:
> - if (!(device->seat_caps & EVDEV_DEVICE_TOUCH))
> + if (slot == -1 || !(device->seat_caps & EVDEV_DEVICE_TOUCH))
> break;
>
> seat_slot = device->mt.slots[slot].seat_slot;
> @@ -180,7 +180,7 @@ evdev_flush_pending_event(struct evdev_device *device,
> uint64_t time)
> touch_notify_touch_motion(base, time, slot, seat_slot, x, y);
> break;
> case EVDEV_ABSOLUTE_MT_UP:
> - if (!(device->seat_caps & EVDEV_DEVICE_TOUCH))
> + if (slot == -1 || !(device->seat_caps & EVDEV_DEVICE_TOUCH))
> break;
>
> seat_slot = device->mt.slots[slot].seat_slot;
> @@ -680,6 +680,16 @@ evdev_configure_device(struct evdev_device *device)
> active_slot = libevdev_get_current_slot(evdev);
> }
>
> + if (num_slots <= 0) {
> + log_bug_kernel(libinput,
> +"multitouch input device %s "
> +"has %s slots\n",
> +device->devnode,
> +num_slots == 0 ? "0" : "no");
> + num_slots = 0;
> + active_slot = -1;
> + }
> +
so, as I said above the libevdev behaviour is intentional and our indicator
that this isn't a MT device after all. We should integrate that knowledge
better so that we don't label a device as touch device when it isn't, and so
that we process events from those axes as normal ABS events instead of MT
events.
Cheers,
Peter
> slots = calloc(num_slots, sizeof(struct mt_slot));
> if (!slots)
> return -1;
> --
> 2.1.0.rc1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [Help]Question about graphics architecture for weson/wayland
Hi Pekka Thank you very much for your reply. > If you have a DRM kernel driver supporting KMS, use Weston's drm-backend > but pass --use-pixman on the command line. DRM kernel driver is for display device? Not for GPU? In other words,i can use drm-backend even though i have no GPU device. Andy > Date: Tue, 19 Aug 2014 09:44:14 +0300 > From: ppaala...@gmail.com > To: williamyan...@hotmail.com > CC: ras...@rasterman.com; wayland-devel@lists.freedesktop.org > Subject: Re: [Help]Question about graphics architecture for weson/wayland > > On Tue, 19 Aug 2014 02:20:58 + > Yang Andy wrote: > > > My senario is that my target device do not support hardware > > accelerate.(do not use gpu) But i have to use EFL to develop > > application in wayland/weston platform. > > > > In order to achieve my task,how do i setup weston? > > Oh, so this was your real question. > > If you have a DRM kernel driver supporting KMS, use Weston's drm-backend > but pass --use-pixman on the command line. > > If you do not have a DRM driver, but you do have /dev/fb0, use Weston's > fbdev-backend. > > > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
