Not able to build Weston.
Hi, I followed the instruction from http://wayland.freedesktop.org/building.html and was able to build Wayland, Mesa, libxkbcommon, cairo-gl, libunwind. But got struck while building Weston. When I do a make, I get the following error: sri.hebbar@sri-hebbar:~/Wayland/weston$ make GENprotocol/text-cursor-position-server-protocol.h :6: unknown type make: *** [protocol/text-cursor-position-server-protocol.h] Error 1 Can anybody pls help me in resolving this issue. Am building on Ubuntu 12.04 32 bit machine. Thank-you, Sri ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 0/5] test: static and modifieable device descriptions
With 1/5, the descriptions are already pretty much limited to just a static description of a device. This set pushes this further, truly reducing each test device to a bunch of arrays with the device-specific data, everything else that used to be boilerplate is now handled by the litest framework. This makes it easier to create a new device based on an existing one, but override a few values instead (4/5). Overrides for event codes and properties at the moment are additive only, and overrides for abs events can only modify or add codes, not remove. Likewise, this is currently only for device creation, no APIs for using litest_touch_down() with overrides exist yet. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 libinput 1/5] test: add litest helper functions for creating uinput devices
Both functions accept a series of event types/codes tuples, terminated by -1.
For the even type INPUT_PROP_MAX (an invalid type otherwise) the code is used
as a property to enable.
The _abs function als takes an array of absinfo, with absinfo.value
determining the axis to change. If none are given, abs axes are initialized
with default settings.
Both functions abort on failure, so the caller does not need to check the
return value.
Example code for creating a rel device:
struct libevdev_uinput *uinput;
struct input_id id = { ... };
uinput = litest_create_uinput_device("foo", &id,
EV_REL, REL_X,
EV_REL, REL_Y,
EV_KEY, BTN_LEFT,
INPUT_PROP_MAX, INPUT_PROP_BUTTONPAD,
-1);
libevdev_uinput_write_event(uinput, EV_REL, REL_X, -1);
libevdev_uinput_write_event(uinput, EV_SYN, SYN_REPORT, 0);
...
libevdev_uinput_destroy(uinput);
Signed-off-by: Peter Hutterer
---
Changes to v1:
- make absinfo a -1-terminated list as well
test/litest-bcm5974.c | 45 +++-
test/litest-generic-highres-touch.c | 34 +++---
test/litest-synaptics-st.c | 37 +++
test/litest-synaptics.c | 45 +++-
test/litest-trackpoint.c| 32 +++---
test/litest-wacom-touch.c | 33 ++
test/litest.c | 88 +++
test/litest.h | 8 ++
test/path.c | 207
9 files changed, 244 insertions(+), 285 deletions(-)
diff --git a/test/litest-bcm5974.c b/test/litest-bcm5974.c
index 5a8ce8a..6b7a22b 100644
--- a/test/litest-bcm5974.c
+++ b/test/litest-bcm5974.c
@@ -95,7 +95,6 @@ static struct litest_device_interface interface = {
void
litest_create_bcm5974(struct litest_device *d)
{
- struct libevdev *dev;
struct input_absinfo abs[] = {
{ ABS_X, 1472, 5472, 75 },
{ ABS_Y, 1408, 4448, 129 },
@@ -105,36 +104,26 @@ litest_create_bcm5974(struct litest_device *d)
{ ABS_MT_POSITION_X, 1472, 5472, 75 },
{ ABS_MT_POSITION_Y, 1408, 4448, 129 },
{ ABS_MT_TRACKING_ID, 0, 65535, 0 },
- { ABS_MT_PRESSURE, 0, 255, 0 }
+ { ABS_MT_PRESSURE, 0, 255, 0 },
+ { .value = -1 },
+ };
+ struct input_id id = {
+ .bustype = 0x3,
+ .vendor = 0x5ac,
+ .product = 0x249,
};
- struct input_absinfo *a;
- int rc;
d->interface = &interface;
-
- dev = libevdev_new();
- ck_assert(dev != NULL);
-
- libevdev_set_name(dev, "bcm5974");
- libevdev_set_id_bustype(dev, 0x3);
- libevdev_set_id_vendor(dev, 0x5ac);
- libevdev_set_id_product(dev, 0x249);
- libevdev_enable_event_code(dev, EV_KEY, BTN_LEFT, NULL);
- libevdev_enable_event_code(dev, EV_KEY, BTN_TOOL_FINGER, NULL);
- libevdev_enable_event_code(dev, EV_KEY, BTN_TOOL_QUINTTAP, NULL);
- libevdev_enable_event_code(dev, EV_KEY, BTN_TOUCH, NULL);
- libevdev_enable_event_code(dev, EV_KEY, BTN_TOOL_DOUBLETAP, NULL);
- libevdev_enable_event_code(dev, EV_KEY, BTN_TOOL_TRIPLETAP, NULL);
- libevdev_enable_event_code(dev, EV_KEY, BTN_TOOL_QUADTAP, NULL);
-
- ARRAY_FOR_EACH(abs, a)
- libevdev_enable_event_code(dev, EV_ABS, a->value, a);
-
- rc = libevdev_uinput_create_from_device(dev,
- LIBEVDEV_UINPUT_OPEN_MANAGED,
- &d->uinput);
- ck_assert_int_eq(rc, 0);
- libevdev_free(dev);
+ d->uinput = litest_create_uinput_abs_device("bcm5974", &id,
+ abs,
+ EV_KEY, BTN_LEFT,
+ EV_KEY, BTN_TOOL_FINGER,
+ EV_KEY, BTN_TOOL_QUINTTAP,
+ EV_KEY, BTN_TOUCH,
+ EV_KEY, BTN_TOOL_DOUBLETAP,
+ EV_KEY, BTN_TOOL_TRIPLETAP,
+ EV_KEY, BTN_TOOL_QUADTAP,
+ -1, -1);
}
struct litest_test_device litest_bcm5974_device = {
diff --git a/test/litest-generic-highres-touch.c
b/test/litest-generic-highres-touch.c
index 68615c3..bb226d6 100644
--- a/test/litest-generic-highres-touch.c
+++ b/test/litest-generic-highres-touch.c
@@ -94,9 +94,6 @@ static struct litest_device_interface interface = {
void
litest_create_generic_highres_touch(struct litest_device *d)
{
- struct libevdev *dev;
- int rc;
- struct input_absinfo *a;
str
[PATCH libinput 4/5] test: allow partial overriding the test devices
For specific tests we need something that e.g. looks like a touchpad, but has
a different name, a different number of slots, etc. In this case, the
following code will do exactly that:
struct input_absinfo overrides[] = {
{ .value = ABS_MT_SLOT, .minimum = 0, .maximum = 100 },
{ .value = -1 },
};
litest_create_device_with_overrides(LITEST_SYNAPTICS_CLICKPAD,
NULL, NULL, &overrides, NULL);
For general event codes, overrides can only add to the set of events, they
can't remove.
Signed-off-by: Peter Hutterer
---
test/litest.c | 158 ++
test/litest.h | 7 +++
2 files changed, 144 insertions(+), 21 deletions(-)
diff --git a/test/litest.c b/test/litest.c
index 23ba76b..3a69a09 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -334,39 +334,149 @@ const struct libinput_interface interface = {
.close_restricted = close_restricted,
};
-struct litest_device *
-litest_create_device(enum litest_device_type which)
+
+static struct input_absinfo *
+merge_absinfo(const struct input_absinfo *orig,
+ const struct input_absinfo *override)
{
- struct litest_device *d = zalloc(sizeof(*d));
- int fd;
- int rc;
- const char *path;
+ struct input_absinfo *abs;
+ int nelem, i;
+ size_t sz = ABS_MAX + 1;
+
+ if (!orig)
+ return NULL;
+
+ abs = calloc(sz, sizeof(*abs));
+ ck_assert(abs != NULL);
+
+ nelem = 0;
+ while(orig[nelem].value != -1) {
+ abs[nelem] = orig[nelem];
+ nelem++;
+ ck_assert_int_lt(nelem, sz);
+ }
+
+ /* just append, if the same axis is present twice, libevdev will
+ only use the last value anyway */
+ i = 0;
+ while(override && override[i].value != -1) {
+ abs[nelem++] = override[i++];
+ ck_assert_int_lt(nelem, sz);
+ }
+
+ ck_assert_int_lt(nelem, sz);
+ abs[nelem].value = -1;
+
+ return abs;
+}
+
+static int*
+merge_events(const int *orig, const int *override)
+{
+ int *events;
+ int nelem, i;
+ size_t sz = KEY_MAX * 3;
+
+ if (!orig)
+ return NULL;
+
+ events = calloc(sz, sizeof(int));
+ ck_assert(events != NULL);
+
+ nelem = 0;
+ while(orig[nelem] != -1) {
+ events[nelem] = orig[nelem];
+ nelem++;
+ ck_assert_int_lt(nelem, sz);
+ }
+
+ /* just append, if the same axis is present twice, libevdev will
+* ignore the double definition anyway */
+ i = 0;
+ while(override && override[i] != -1) {
+ events[nelem++] = override[i++];
+ ck_assert_int_le(nelem, sz);
+ }
+
+ ck_assert_int_lt(nelem, sz);
+ events[nelem] = -1;
+
+ return events;
+}
+
+
+static struct litest_device *
+litest_create(enum litest_device_type which,
+ const char *name_override,
+ struct input_id *id_override,
+ const struct input_absinfo *abs_override,
+ const int *events_override)
+{
+ struct litest_device *d = NULL;
struct litest_test_device **dev;
-
- ck_assert(d != NULL);
+ const char *name;
+ const struct input_id *id;
+ struct input_absinfo *abs;
+ int *events;
dev = devices;
while (*dev) {
- if ((*dev)->type == which) {
- if ((*dev)->create)
- (*dev)->create(d);
- else {
- d->uinput =
litest_create_uinput_device_from_description((*dev)->name,
-
(*dev)->id,
-
(*dev)->absinfo,
-
(*dev)->events);
- d->interface = (*dev)->interface;
- }
+ if ((*dev)->type == which)
break;
- }
dev++;
}
- if (!dev) {
+ if (!dev)
ck_abort_msg("Invalid device type %d\n", which);
- return NULL;
+
+ d = zalloc(sizeof(*d));
+ ck_assert(d != NULL);
+
+ /* device has custom create method */
+ if ((*dev)->create) {
+ (*dev)->create(d);
+ if (abs_override || events_override)
+ ck_abort_msg("Custom create cannot"
+"be overridden");
+
+ return d;
}
+ abs = merge_absinfo((*dev)->absinfo, abs_override);
+ events = merge_events((*dev)->events, events_override);
+ name = name_override ? name_override : (*dev)->name;
+ id = id_override ? id_override :
[PATCH libinput 3/5] test: allow for description-based test devices
Most of the test devices now are static descriptions anyway, make them fully
static now, including for touch events.
Switch the synaptics device now as example, the rest comes later for easier
patch review.
Signed-off-by: Peter Hutterer
---
test/litest-int.h | 47 ++-
test/litest-synaptics.c | 151
test/litest.c | 141 ++--
3 files changed, 231 insertions(+), 108 deletions(-)
diff --git a/test/litest-int.h b/test/litest-int.h
index b515b6c..19e6e68 100644
--- a/test/litest-int.h
+++ b/test/litest-int.h
@@ -23,19 +23,52 @@
#if HAVE_CONFIG_H
#include "config.h"
#endif
+#include
#ifndef LITEST_INT_H
#define LITEST_INT_H
#include "litest.h"
+/* Use as designater for litest to change the value */
+#define LITEST_AUTO_ASSIGN INT_MIN
+
struct litest_test_device {
enum litest_device_type type;
enum litest_device_feature features;
const char *shortname;
void (*setup)(void); /* test fixture, used by check */
void (*teardown)(void); /* test fixture, used by check */
-
+ /**
+ * If create is non-NULL it will be called to initialize the device.
+ * For such devices, no overrides are possible. If create is NULL,
+ * the information in name, id, events, absinfo is used to
+ * create the device instead.
+ */
void (*create)(struct litest_device *d);
+
+ /**
+ * The device name. Only used when create is NULL.
+ */
+ const char *name;
+ /**
+ * The device id. Only used when create is NULL.
+ */
+ const struct input_id *id;
+ /**
+ * List of event type/code tuples, terminated with -1, e.g.
+ * EV_REL, REL_X, EV_KEY, BTN_LEFT, -1
+ * Special tuple is INPUT_PROP_MAX, to set.
+ *
+ * Any EV_ABS codes in this list will be initialized with a default
+ * axis range.
+ */
+ int *events;
+ /**
+ * List of abs codes to enable, with absinfo.value determining the
+ * code to set. List must be terminated with absinfo.value -1
+ */
+ struct input_absinfo *absinfo;
+ struct litest_device_interface *interface;
};
struct litest_device_interface {
@@ -43,6 +76,18 @@ struct litest_device_interface {
void (*touch_move)(struct litest_device *d, unsigned int slot, int x,
int y);
void (*touch_up)(struct litest_device *d, unsigned int slot);
+ /**
+* Set of of events to execute on touch down, terminated by a .type
+* and .code value of -1. If the event value is LITEST_AUTO_ASSIGN,
+* it will be automatically assigned by the framework (valid for x,
+* y, tracking id and slot).
+*
+* These events are only used if touch_down is NULL.
+*/
+ struct input_event *touch_down_events;
+ struct input_event *touch_move_events;
+ struct input_event *touch_up_events;
+
int min[2];
int max[2];
};
diff --git a/test/litest-synaptics.c b/test/litest-synaptics.c
index c960db2..f220858 100644
--- a/test/litest-synaptics.c
+++ b/test/litest-synaptics.c
@@ -34,105 +34,78 @@ void litest_synaptics_clickpad_setup(void)
litest_set_current_device(d);
}
-void
-litest_synaptics_clickpad_touch_down(struct litest_device *d,
-unsigned int slot,
-int x, int y)
-{
- static int tracking_id;
- struct input_event *ev;
- struct input_event down[] = {
- { .type = EV_KEY, .code = BTN_TOOL_FINGER, .value = 1 },
- { .type = EV_KEY, .code = BTN_TOUCH, .value = 1 },
- { .type = EV_ABS, .code = ABS_X, .value = x },
- { .type = EV_ABS, .code = ABS_Y, .value = y },
- { .type = EV_ABS, .code = ABS_PRESSURE, .value = 30 },
- { .type = EV_ABS, .code = ABS_MT_SLOT, .value = slot },
- { .type = EV_ABS, .code = ABS_MT_TRACKING_ID, .value =
++tracking_id },
- { .type = EV_ABS, .code = ABS_MT_POSITION_X, .value = x },
- { .type = EV_ABS, .code = ABS_MT_POSITION_Y, .value = y },
- { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
- };
+static struct input_event down[] = {
+ { .type = EV_KEY, .code = BTN_TOOL_FINGER, .value = 1 },
+ { .type = EV_KEY, .code = BTN_TOUCH, .value = 1 },
+ { .type = EV_ABS, .code = ABS_X, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_Y, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_PRESSURE, .value = 30 },
+ { .type = EV_ABS, .code = ABS_MT_SLOT, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_TRACKING_ID, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_X, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_POSI
[PATCH libinput 2/5] test: if no teardown func is set, use the default
Reduces the amount of boilerplate code.
Signed-off-by: Peter Hutterer
---
test/litest-bcm5974.c | 2 +-
test/litest-generic-highres-touch.c | 2 +-
test/litest-keyboard.c | 2 +-
test/litest-mouse.c | 2 +-
test/litest-synaptics-st.c | 2 +-
test/litest-trackpoint.c| 2 +-
test/litest-wacom-touch.c | 2 +-
test/litest.c | 3 ++-
8 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/test/litest-bcm5974.c b/test/litest-bcm5974.c
index 6b7a22b..ff822f9 100644
--- a/test/litest-bcm5974.c
+++ b/test/litest-bcm5974.c
@@ -131,6 +131,6 @@ struct litest_test_device litest_bcm5974_device = {
.features = LITEST_TOUCHPAD | LITEST_CLICKPAD | LITEST_BUTTON,
.shortname = "bcm5974",
.setup = litest_bcm5974_setup,
- .teardown = litest_generic_device_teardown,
+ .teardown = NULL,
.create = litest_create_bcm5974,
};
diff --git a/test/litest-generic-highres-touch.c
b/test/litest-generic-highres-touch.c
index bb226d6..4d21b0d 100644
--- a/test/litest-generic-highres-touch.c
+++ b/test/litest-generic-highres-touch.c
@@ -123,6 +123,6 @@ struct litest_test_device
litest_generic_highres_touch_device = {
.features = LITEST_TOUCH,
.shortname = "generic-highres-touch",
.setup = litest_generic_highres_touch_setup,
- .teardown = litest_generic_device_teardown,
+ .teardown = NULL,
.create = litest_create_generic_highres_touch,
};
diff --git a/test/litest-keyboard.c b/test/litest-keyboard.c
index dd91158..ab05014 100644
--- a/test/litest-keyboard.c
+++ b/test/litest-keyboard.c
@@ -109,6 +109,6 @@ struct litest_test_device litest_keyboard_device = {
.features = LITEST_KEYS,
.shortname = "default keyboard",
.setup = litest_keyboard_setup,
- .teardown = litest_generic_device_teardown,
+ .teardown = NULL,
.create = litest_create_keyboard,
};
diff --git a/test/litest-mouse.c b/test/litest-mouse.c
index 2fde095..2f70767 100644
--- a/test/litest-mouse.c
+++ b/test/litest-mouse.c
@@ -70,6 +70,6 @@ struct litest_test_device litest_mouse_device = {
.features = LITEST_POINTER | LITEST_BUTTON | LITEST_WHEEL,
.shortname = "mouse",
.setup = litest_mouse_setup,
- .teardown = litest_generic_device_teardown,
+ .teardown = NULL,
.create = litest_create_mouse,
};
diff --git a/test/litest-synaptics-st.c b/test/litest-synaptics-st.c
index d13d9a2..de56c22 100644
--- a/test/litest-synaptics-st.c
+++ b/test/litest-synaptics-st.c
@@ -126,6 +126,6 @@ struct litest_test_device litest_synaptics_touchpad_device
= {
.features = LITEST_TOUCHPAD | LITEST_BUTTON | LITEST_SINGLE_TOUCH,
.shortname = "synaptics ST",
.setup = litest_synaptics_touchpad_setup,
- .teardown = litest_generic_device_teardown,
+ .teardown = NULL,
.create = litest_create_synaptics_touchpad,
};
diff --git a/test/litest-trackpoint.c b/test/litest-trackpoint.c
index e0b79c5..1c0fb0a 100644
--- a/test/litest-trackpoint.c
+++ b/test/litest-trackpoint.c
@@ -61,6 +61,6 @@ struct litest_test_device litest_trackpoint_device = {
.features = LITEST_POINTER | LITEST_BUTTON,
.shortname = "trackpoint",
.setup = litest_trackpoint_setup,
- .teardown = litest_generic_device_teardown,
+ .teardown = NULL,
.create = litest_create_trackpoint,
};
diff --git a/test/litest-wacom-touch.c b/test/litest-wacom-touch.c
index 01a5a5d..e9119a9 100644
--- a/test/litest-wacom-touch.c
+++ b/test/litest-wacom-touch.c
@@ -122,6 +122,6 @@ struct litest_test_device litest_wacom_touch_device = {
.features = LITEST_TOUCH,
.shortname = "wacom-touch",
.setup = litest_wacom_touch_setup,
- .teardown = litest_generic_device_teardown,
+ .teardown = NULL,
.create = litest_create_wacom_touch,
};
diff --git a/test/litest.c b/test/litest.c
index f7fe24e..6767952 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -119,7 +119,8 @@ litest_add_tcase_for_device(struct suite *suite,
t->name = strdup(test_name);
t->tc = tcase_create(test_name);
list_insert(&suite->tests, &t->node);
- tcase_add_checked_fixture(t->tc, dev->setup, dev->teardown);
+ tcase_add_checked_fixture(t->tc, dev->setup,
+ dev->teardown ? dev->teardown :
litest_generic_device_teardown);
tcase_add_test(t->tc, func);
suite_add_tcase(suite->suite, t->tc);
}
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 5/5] test: switch the remaining devices to a description-based device
Signed-off-by: Peter Hutterer
---
test/litest-bcm5974.c | 147 ++-
test/litest-generic-highres-touch.c | 128
test/litest-keyboard.c | 231 +---
test/litest-mouse.c | 48
test/litest-synaptics-st.c | 131
test/litest-trackpoint.c| 39 +++---
test/litest-wacom-touch.c | 127
7 files changed, 419 insertions(+), 432 deletions(-)
diff --git a/test/litest-bcm5974.c b/test/litest-bcm5974.c
index ff822f9..ab944a7 100644
--- a/test/litest-bcm5974.c
+++ b/test/litest-bcm5974.c
@@ -34,97 +34,66 @@ static void litest_bcm5974_setup(void)
litest_set_current_device(d);
}
-static void
-litest_bcm5974_touch_down(struct litest_device *d,
- unsigned int slot,
- int x, int y)
-{
- static int tracking_id;
- struct input_event *ev;
- struct input_event down[] = {
- { .type = EV_KEY, .code = BTN_TOOL_FINGER, .value = 1 },
- { .type = EV_KEY, .code = BTN_TOUCH, .value = 1 },
- { .type = EV_ABS, .code = ABS_X, .value = x },
- { .type = EV_ABS, .code = ABS_Y, .value = y },
- { .type = EV_ABS, .code = ABS_PRESSURE, .value = 30 },
- { .type = EV_ABS, .code = ABS_MT_SLOT, .value = slot },
- { .type = EV_ABS, .code = ABS_MT_TRACKING_ID, .value =
++tracking_id },
- { .type = EV_ABS, .code = ABS_MT_POSITION_X, .value = x },
- { .type = EV_ABS, .code = ABS_MT_POSITION_Y, .value = y },
- { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
- };
+struct input_event down[] = {
+ { .type = EV_KEY, .code = BTN_TOOL_FINGER, .value = 1 },
+ { .type = EV_KEY, .code = BTN_TOUCH, .value = 1 },
+ { .type = EV_ABS, .code = ABS_X, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_Y, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_PRESSURE, .value = 30 },
+ { .type = EV_ABS, .code = ABS_MT_SLOT, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_TRACKING_ID, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_X, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_Y, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
+ { .type = -1, .code = -1 },
+};
- down[2].value = litest_scale(d, ABS_X, x);
- down[3].value = litest_scale(d, ABS_Y, y);
- down[7].value = litest_scale(d, ABS_X, x);
- down[8].value = litest_scale(d, ABS_Y, y);
-
- ARRAY_FOR_EACH(down, ev)
- litest_event(d, ev->type, ev->code, ev->value);
-}
-
-void
-litest_bcm5974_move(struct litest_device *d, unsigned int slot, int x, int y)
-{
- struct input_event *ev;
- struct input_event move[] = {
- { .type = EV_ABS, .code = ABS_MT_SLOT, .value = slot },
- { .type = EV_ABS, .code = ABS_X, .value = x },
- { .type = EV_ABS, .code = ABS_Y, .value = y },
- { .type = EV_ABS, .code = ABS_MT_POSITION_X, .value = x },
- { .type = EV_ABS, .code = ABS_MT_POSITION_Y, .value = y },
- { .type = EV_KEY, .code = BTN_TOOL_FINGER, .value = 1 },
- { .type = EV_KEY, .code = BTN_TOUCH, .value = 1 },
- { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
- };
-
- move[1].value = litest_scale(d, ABS_X, x);
- move[2].value = litest_scale(d, ABS_Y, y);
- move[3].value = litest_scale(d, ABS_X, x);
- move[4].value = litest_scale(d, ABS_Y, y);
-
- ARRAY_FOR_EACH(move, ev)
- litest_event(d, ev->type, ev->code, ev->value);
-}
+static struct input_event move[] = {
+ { .type = EV_ABS, .code = ABS_MT_SLOT, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_X, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_Y, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_X, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_Y, .value =
LITEST_AUTO_ASSIGN },
+ { .type = EV_KEY, .code = BTN_TOOL_FINGER, .value = 1 },
+ { .type = EV_KEY, .code = BTN_TOUCH, .value = 1 },
+ { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
+ { .type = -1, .code = -1 },
+};
static struct litest_device_interface interface = {
- .touch_down = litest_bcm5974_touch_down,
- .touch_move = litest_bcm5974_move,
+ .touch_down_events = down,
+ .touch_move_events = move,
};
-void
-litest_create_bcm5974(struct litest_device *d)
-{
- struct input_absinfo abs[] = {
- { ABS_X, 1472, 5472, 75 },
- { ABS_Y, 1408, 4448, 129 },
- { ABS_PRESSURE, 0,
Re: [RFC PATCH 1/6] Add colorcorrection protocol
Am 31.03.2014 16:10, schrieb Pekka Paalanen: > On Mon, 31 Mar 2014 11:29:03 +0200 > Kai-Uwe Behrmann wrote: > >> Am 31.03.2014 09:46, schrieb Pekka Paalanen: >>> On Sun, 30 Mar 2014 13:36:32 +0200 >>> Niels Ole Salscheider wrote: >>> The color correction protocol allows to attach an ICC profile to a surface. It also tells the client about the blending color space and the color spaces of all outputs. Signed-off-by: Niels Ole Salscheider --- Makefile.am | 15 ++-- protocol/colorcorrection.xml | 87 2 files changed, 98 insertions(+), 4 deletions(-) create mode 100644 protocol/colorcorrection.xml diff --git a/Makefile.am b/Makefile.am index 5ff4f83..ec0a30b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -76,7 +76,9 @@ nodist_weston_SOURCES = \ protocol/workspaces-protocol.c \ protocol/workspaces-server-protocol.h \ protocol/scaler-protocol.c \ - protocol/scaler-server-protocol.h + protocol/scaler-server-protocol.h \ + protocol/colorcorrection-protocol.c \ + protocol/colorcorrection-server-protocol.h BUILT_SOURCES += $(nodist_weston_SOURCES) @@ -426,7 +428,9 @@ nodist_libtoytoolkit_la_SOURCES = \ protocol/workspaces-protocol.c \ protocol/workspaces-client-protocol.h \ protocol/xdg-shell-protocol.c \ - protocol/xdg-shell-client-protocol.h + protocol/xdg-shell-client-protocol.h\ + protocol/colorcorrection-protocol.c \ + protocol/colorcorrection-client-protocol.h BUILT_SOURCES += $(nodist_libtoytoolkit_la_SOURCES) @@ -606,7 +610,9 @@ BUILT_SOURCES += \ protocol/workspaces-client-protocol.h \ protocol/workspaces-protocol.c \ protocol/xdg-shell-protocol.c \ - protocol/xdg-shell-client-protocol.h + protocol/xdg-shell-client-protocol.h\ + protocol/colorcorrection-protocol.c \ + protocol/colorcorrection-client-protocol.h westondatadir = $(datadir)/weston @@ -920,7 +926,8 @@ EXTRA_DIST += \ protocol/text-cursor-position.xml \ protocol/wayland-test.xml \ protocol/xdg-shell.xml \ - protocol/scaler.xml + protocol/scaler.xml \ + protocol/colorcorrection.xml man_MANS = weston.1 weston.ini.5 diff --git a/protocol/colorcorrection.xml b/protocol/colorcorrection.xml new file mode 100644 index 000..7986e93 --- /dev/null +++ b/protocol/colorcorrection.xml @@ -0,0 +1,87 @@ + + + + +Copyright © 2014 Niels Ole Salscheider + +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. + + + + + This interface allows to attach a color profile to a wl_surface. + This is used by the compositor to display the colors correctly. + The client is informed by two events about the blending space used + by the compositor and the color spaces of the outputs. + + + + + With this request, the color profile of a wl_surface can be set. + When mode is set to "profile", an ICC profile can be passed in the + "profile_data" argum
Re: [ANNOUNCE] libxkbcommon-0.4.1
Hi,
On 27 March 2014 22:41, Ran Benita wrote:
> On Thu, Mar 27, 2014 at 09:04:07PM +0100, David Herrmann wrote:
> > On Thu, Mar 27, 2014 at 8:22 PM, Ran Benita wrote:
> > > - Added two new functions, xkb_state_key_get_utf{8,32}(). They
> > > combine the operations of xkb_state_key_get_syms() and
> > > xkb_keysym_to_utf{8,32}(), and provide a nicer interface for it
> > > (espcially for multiple-keysyms-per-level).
> >
> > Slightly off-topic, but looking at the code, you ignore any multi-sym
> > values (nsyms != 1). Users of that API might rely on that behavior, so
> > have we at some point defined what exactly multi-sym means? Because if
> > we add more and more APIs and if the user-base grows, we might at some
> > point be unable to make use of multi-symbol behavior. I'm still not
> > sure whether nsyms > 1 just means multiple sequential keysyms, or
> > whether they should be handled as _one_ atomic combined keysym?
>
> First, the reason I added these functions is that
> https://bugs.freedesktop.org/show_bug.cgi?id=75892 made it necessary, I
> would otherwise like to avoid adding new API at this point. But given
> the situation, I tried to make the best of it.
>
> I only ignore multiple-keysyms for the utf32 function -- I only added
> it to match the existing xkb_keysym_to_utf32() function. I don't think
> it makes sense to encode multiple-keysyms into a UTF-32 string, nobody
> uses it. A better name would be xkb_keysym_to_unicode_codepoint() or
> whatever, but I wanted to keep the existing name.
>
> For the utf8 function, it is handled correctly, and is actually much
> easier to use for multiple-keysyms than the old function. It builds the
> string internally and finally ensures it's valid UTF-8.
>
> Another advantage of adding new functions is that existing users don't
> break due to the new behavior, they must opt-in.
>
> Regarding intended use-case for multiple-keysyms, I consider it mainly
> to be for sequences with combining characters - not everything has
> precomposed codepoints, so if you want one of these, you don't have a
> way to do it with single-keysym, but it still conceptually fits in a
> keymap. However for the original intent you have to ask Daniel.
Yes, it is supposed to be atomic: the usecase was for keymaps (there was
one from central Asia - can't remember off the top of my head), where
Unicode no longer adds precomposed characters, so some key presses need to
generate multiple symbols which should be processed all at once.
> > I'm not saying the patch is wrong, in fact, the layout-search logic is
> > actually what you wrote for kmscon and I appreciate that. I'm just
> > saying that it's a really subtle API difference that can introduce
> > weird bugs. Lets see how it works out, but if people start using
> > xkb_state_key_get_utf32(), I might send a patch adding an xkb-state
> > flag that disables this transformation. Or just force users to not use
> > it (which would be unfortunate).
>
> A flag makes sense; I try to to add stuff when someone really needs it,
> not preemptively. Btw, xkb_state_new() doesn't take a flags arg - argh.
>
Yeah, I'm now regretting not adding that flag param! One for 1.0 perhaps ...
> But in general this stuff should be the default, we initially tried to
> avoid these nonsensical US-centric behavior (let's say intentionally :),
> but both the keymaps and existing users actually depend on them, like
> the capitalization and Control thing (and they are also there in the
> spec).
Indeed - there've been quite a few people surprised by this, who were
expecting the Xlib-style behaviour.
> > Btw., same is true for the implicit caps-lock magic in
> > xkb_state_key_get_one_sym(). I'm now quite confused whether
> > xkb_state_key_get_syms() users have to do caps-lock handling
> > explicitly? Or is that done by keymaps?
>
> Currently to get the implicit capitalization with get_syms(), you have
> to do this:
>
> int nsyms;
> const xkb_keysym_t *syms;
> xkb_keysym_t sym;
>
> nsyms = xkb_state_key_get_syms(..., &syms);
> if (nsyms == 1) {
> sym = xkb_state_key_get_one_sym(...);
> syms = &sym;
> }
>
> I imagine the disgust, but given the set of constraints we had I
> couldn't think of any way to make this work. New API is still possible,
> but then we'd have *three* ways to get keysyms...
>
> As I may have mentioned, I wanted to change the *keymaps* so the
> difference doesn't matter here. I still plan to send some patches for
> easy cases, but fixing other cases would require major xkeyboard-config
> surgery. So we're stuck with it.
It's indeed really unpleasant, and definitely the worst corner of our API
right now. FWIW, the reason this evolved this way is because
xkb_state_key_get_syms returns a pointer which will remain valid and
pointing to the same symbols for the life of the state object. Having to
do mapping on the fly obviously blows that out of the water, unless we
allocate an area for composed symbol
Re: [RFC PATCH 1/6] Add colorcorrection protocol
Niels Ole Salscheider wrote: The color correction protocol allows to attach an ICC profile to a surface. It also tells the client about the blending color space and the color spaces of all outputs. As you pointed out, it does look like this has to be done by the compositor, because a different color correction has to be applied to a surface for each output. Since a surface can appear on more than one output simultaneously, and that information is not available to a client, the compositor must do this. + + + With this request, the color profile of a wl_surface can be set. + When mode is set to "profile", an ICC profile can be passed in the + "profile_data" argument. In all other cases, "profile_data" is + ignored. + "mode" should only be set to "uncorrected" for fullscreen applications + or applications that really require uncorrected output (e. g. color + profiling tools). + + + + + This should be double-buffered: it does not happen until a commit. I would make the profile be an object, not a block of data, so it can be reused easily. (this is in addition to the other discussion of how the data is conveyed between client and compositor). The "mode" can be eliminated by making special profile objects for each mode. + + + This event will be sent when the blending space of the compositor + is changed. A client can use this information to output its surface + in the blending space of the compositor so that only one color + transform (from blending to output space) has to be performed by the + compositor. This can result in better performance. + + + I don't like this description. There may be a "linear" blending space, but the purpose is not to describe some "faster" space. In fact sending the buffer as a linear color space may be much slower and look much worse. A compositor does not have to implement a linear blend by converting the source to linear space and building a buffer of linear values. Instead it can do it with amazingly crude approximations. For instance replacing a+b with sqrt(a^2+b^2) will do a pretty good job of adding two sRGB images together, indistinguishable by eye from the accurate result. And the source and destination are all in sRGB space. The reason clients want to know the blending space is because it changes how partially-transparent areas, in particular shadows, are stored in the source, especially if the client wants to draw internal shadows in the buffer that "match", or set the drag&drop cursor to am image that actually composites correctly into the drop target. I suspect also the blending space may vary depending on the surface: it may do a subsurface different than a parent (especially for remote display), and if overlay planes are used it may change the blending space. Maybe it would be sufficient to send this per-surface. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH 1/6] Add colorcorrection protocol
Pekka Paalanen wrote: > On Mon, 31 Mar 2014 09:25:34 +0100 > Richard Hughes wrote: > >> On 31 March 2014 08:46, Pekka Paalanen >> wrote: >> > how much data can an ICC profile be? >> >> Printer profiles can be several megabytes in size, but display >> profiles (what will be seen here) are usually in the 20-30kb size >> range. > > I do wonder if we will have a problem with the maximum message > size in Wayland. I'm not sure how the maximum is determined, and since > profiles could in theory be very big, I'd propose using an out-of-band > method for transferring that data. > >> > Also, what if a client has several surfaces all with the same ICC >> > profile, would it not be useful to have some notion of re-using an >> > already sent and parsed color profile? Otherwise I would imagine lots >> > of overhead if every surface has a private copy of the profile >> > sent over the wire, parsed, and stored in the compositor's renderer. >> >> I don't think typically they'll be many different profiles in use, on >> a typical system most things will just be (assumed) sRGB to 'n' >> display profiles, where n is the number of outputs. > > I take that as "yes, explicit re-use would be very useful" to avoid > parsing, comparing and coalescing at every turn. Well, with FD passing couldn't fstat be used with comparing st_dev and st_inode? That'd give comparison without parsing (although depending on how you use the FD you might want the SEAL_* stuff as well.) >> > Is that a reasonable requirement for all compositors that support >> > per-output ICC profiles? >> >> I think it's a very little amount of work, IMO doing it centrally >> makes a lot of sense as some bits are tricky to do correctly. > > "Tricky" should be solve by shared libraries rather than a daemon, > IMHO. I'm more concerned about the amount of work the compositor will > be doing, not the work for implementing it. I think such color space > conversion should be accounted for the client, i.e. done in the client. > It would be wasteful, if a compositor needs to compute the source > conversion every time it just repaints the screen, even if the content > for a color-managed surface has not changed. I'm assuming a compositor > would be texturing directly out of a client's buffer. > > I would also like to have room for compositors that blend in a > non-ideal color space. Having a separate blending color space is > essentially an additional copy, AFAIU, which is a pretty high cost for > something, whose result any single client cannot assume at all, anyway. > I still think that if a client needs the result of blending non-opaque > pixels to be guaranteed, it should do it itself and not rely on the > server. > >> Overall, I'm very happy to see someone pick up this work. Thanks. > > Indeed. > > > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH 1/6] Add colorcorrection protocol
On Mon, 31 Mar 2014 11:29:03 +0200 Kai-Uwe Behrmann wrote: > Am 31.03.2014 09:46, schrieb Pekka Paalanen: > > On Sun, 30 Mar 2014 13:36:32 +0200 > > Niels Ole Salscheider wrote: > > > >> The color correction protocol allows to attach an ICC profile to a > >> surface. It also tells the client about the blending color space and > >> the color spaces of all outputs. > >> > >> Signed-off-by: Niels Ole Salscheider > >> --- > >> Makefile.am | 15 ++-- > >> protocol/colorcorrection.xml | 87 > >> > >> 2 files changed, 98 insertions(+), 4 deletions(-) > >> create mode 100644 protocol/colorcorrection.xml > >> > >> diff --git a/Makefile.am b/Makefile.am > >> index 5ff4f83..ec0a30b 100644 > >> --- a/Makefile.am > >> +++ b/Makefile.am > >> @@ -76,7 +76,9 @@ nodist_weston_SOURCES = > >> \ > >>protocol/workspaces-protocol.c \ > >>protocol/workspaces-server-protocol.h \ > >>protocol/scaler-protocol.c \ > >> - protocol/scaler-server-protocol.h > >> + protocol/scaler-server-protocol.h \ > >> + protocol/colorcorrection-protocol.c \ > >> + protocol/colorcorrection-server-protocol.h > >> > >> BUILT_SOURCES += $(nodist_weston_SOURCES) > >> > >> @@ -426,7 +428,9 @@ nodist_libtoytoolkit_la_SOURCES = > >> \ > >>protocol/workspaces-protocol.c \ > >>protocol/workspaces-client-protocol.h \ > >>protocol/xdg-shell-protocol.c \ > >> - protocol/xdg-shell-client-protocol.h > >> + protocol/xdg-shell-client-protocol.h\ > >> + protocol/colorcorrection-protocol.c \ > >> + protocol/colorcorrection-client-protocol.h > >> > >> BUILT_SOURCES += $(nodist_libtoytoolkit_la_SOURCES) > >> > >> @@ -606,7 +610,9 @@ BUILT_SOURCES += > >> \ > >>protocol/workspaces-client-protocol.h \ > >>protocol/workspaces-protocol.c \ > >>protocol/xdg-shell-protocol.c \ > >> - protocol/xdg-shell-client-protocol.h > >> + protocol/xdg-shell-client-protocol.h\ > >> + protocol/colorcorrection-protocol.c \ > >> + protocol/colorcorrection-client-protocol.h > >> > >> > >> westondatadir = $(datadir)/weston > >> @@ -920,7 +926,8 @@ EXTRA_DIST += \ > >>protocol/text-cursor-position.xml \ > >>protocol/wayland-test.xml \ > >>protocol/xdg-shell.xml \ > >> - protocol/scaler.xml > >> + protocol/scaler.xml \ > >> + protocol/colorcorrection.xml > >> > >> man_MANS = weston.1 weston.ini.5 > >> > >> diff --git a/protocol/colorcorrection.xml b/protocol/colorcorrection.xml > >> new file mode 100644 > >> index 000..7986e93 > >> --- /dev/null > >> +++ b/protocol/colorcorrection.xml > >> @@ -0,0 +1,87 @@ > >> + > >> + > >> + > >> + > >> +Copyright © 2014 Niels Ole Salscheider > >> + > >> +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. > >> + > >> + > >> + > >> + > >> + This interface allows to attach a color profile to a wl_surface. > >> + This is used by the compositor to display the colors correctly. > >> + The client is informed by two events about the blending space used > >> + by the compositor and the color spaces of the outputs. > >> + > >> + > >> + > >> + > >> + With this request, the color profile of a wl_surface can be set. > >> + When mode is set to "profile", an ICC profile can be passed in the > >> + "profile_data" argument. In all other cases, "profile_data" is > >> +
Re: [RFC PATCH 1/6] Add colorcorrection protocol
On 31 March 2014 12:13, Kai-Uwe Behrmann wrote: > In many cases a client is not remotely able to compute per output > regions without much information about scaling, positioning, (warping?) To explain a little here, different outputs need different ICC profiles (and thus a different color table) that usually have different primaries to adapt to. I have a wide gamut DreamColor attached to my low-gamut T510 laptop. Putting this logic in the compositor makes it two order of magnitude simpler when you have more than one output attached. Richard ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH 1/6] Add colorcorrection protocol
Am 31.03.2014 11:43, schrieb Pekka Paalanen: > On Mon, 31 Mar 2014 09:25:34 +0100 > Richard Hughes wrote: > >> On 31 March 2014 08:46, Pekka Paalanen wrote: >>> how much data can an ICC profile be? >> Printer profiles can be several megabytes in size, but display >> profiles (what will be seen here) are usually in the 20-30kb size >> range. > I do wonder if we will have a problem with the maximum message > size in Wayland. I'm not sure how the maximum is determined, and since > profiles could in theory be very big, I'd propose using an out-of-band > method for transferring that data. > >>> Also, what if a client has several surfaces all with the same ICC >>> profile, would it not be useful to have some notion of re-using an >>> already sent and parsed color profile? Otherwise I would imagine lots >>> of overhead if every surface has a private copy of the profile >>> sent over the wire, parsed, and stored in the compositor's renderer. >> I don't think typically they'll be many different profiles in use, on >> a typical system most things will just be (assumed) sRGB to 'n' >> display profiles, where n is the number of outputs. > I take that as "yes, explicit re-use would be very useful" to avoid > parsing, comparing and coalescing at every turn. > >>> Is that a reasonable requirement for all compositors that support >>> per-output ICC profiles? >> I think it's a very little amount of work, IMO doing it centrally >> makes a lot of sense as some bits are tricky to do correctly. > "Tricky" should be solve by shared libraries rather than a daemon, > IMHO. I'm more concerned about the amount of work the compositor will > be doing, not the work for implementing it. I think such color space > conversion should be accounted for the client, i.e. done in the client. The concerns of KWin's Martin where at time of implementing CM, that colour conversions shall be done in one place. Pro inside KWin was mentioned to have only few LUTs applied to many textures. In the logical opposite, contra client side conversions was the need to compute store and cache all LUTs per client, without much sharing among different clients running under one compositor. Feature wise, the only output aware colour correcting applications I know of under Linux are two compositors, with Niels path three, and some client side example code in Oyranos. So moving stuff to the clients will very likely loose those valuable features like per output correction, speedy ICC colour corrected movie displaying, consitency etc. > It would be wasteful, if a compositor needs to compute the source > conversion every time it just repaints the screen, even if the content > for a color-managed surface has not changed. I'm assuming a compositor > would be texturing directly out of a client's buffer. In many cases a client is not remotely able to compute per output regions without much information about scaling, positioning, (warping?) etc. In the past very few clients used that informations even if available. See my comment above. Client side colour correction (early colour binding) was and is a corner case - even sometimes a very valuable one. With more features going inside compositors, it becomes for clients harder to predict on which output a pixel will appear. Practical clients would need to analyse all effects a compositor performs on a clients buffer, for that to work correctly. > I would also like to have room for compositors that blend in a > non-ideal color space. Having a separate blending color space is > essentially an additional copy, AFAIU, which is a pretty high cost for > something, whose result any single client cannot assume at all, anyway. > I still think that if a client needs the result of blending non-opaque > pixels to be guaranteed, it should do it itself and not rely on the > server. > >> Overall, I'm very happy to see someone pick up this work. Thanks. > Indeed. kind regards Kai-Uwe ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH 1/6] Add colorcorrection protocol
On Mon, 31 Mar 2014 09:25:34 +0100 Richard Hughes wrote: > On 31 March 2014 08:46, Pekka Paalanen wrote: > > how much data can an ICC profile be? > > Printer profiles can be several megabytes in size, but display > profiles (what will be seen here) are usually in the 20-30kb size > range. I do wonder if we will have a problem with the maximum message size in Wayland. I'm not sure how the maximum is determined, and since profiles could in theory be very big, I'd propose using an out-of-band method for transferring that data. > > Also, what if a client has several surfaces all with the same ICC > > profile, would it not be useful to have some notion of re-using an > > already sent and parsed color profile? Otherwise I would imagine lots > > of overhead if every surface has a private copy of the profile > > sent over the wire, parsed, and stored in the compositor's renderer. > > I don't think typically they'll be many different profiles in use, on > a typical system most things will just be (assumed) sRGB to 'n' > display profiles, where n is the number of outputs. I take that as "yes, explicit re-use would be very useful" to avoid parsing, comparing and coalescing at every turn. > > Is that a reasonable requirement for all compositors that support > > per-output ICC profiles? > > I think it's a very little amount of work, IMO doing it centrally > makes a lot of sense as some bits are tricky to do correctly. "Tricky" should be solve by shared libraries rather than a daemon, IMHO. I'm more concerned about the amount of work the compositor will be doing, not the work for implementing it. I think such color space conversion should be accounted for the client, i.e. done in the client. It would be wasteful, if a compositor needs to compute the source conversion every time it just repaints the screen, even if the content for a color-managed surface has not changed. I'm assuming a compositor would be texturing directly out of a client's buffer. I would also like to have room for compositors that blend in a non-ideal color space. Having a separate blending color space is essentially an additional copy, AFAIU, which is a pretty high cost for something, whose result any single client cannot assume at all, anyway. I still think that if a client needs the result of blending non-opaque pixels to be guaranteed, it should do it itself and not rely on the server. > Overall, I'm very happy to see someone pick up this work. Thanks. Indeed. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH 2/6] Attach input profiles and build corresponding LUTs
Am 30.03.2014 13:36, schrieb Niels Ole Salscheider: > This implements the functionality to attach a profile to a surface > in weston. An LUT is built from the profile that can be used to > transform colors from the input color space to the blending color > space. > This patch uses the sRGB color space as blending space because it > uses 8 bit LUTs for now and I want to avoid additional banding. In > the long term we should use a linear blending space though to get > correct results. Banding will be serious with a pure linear gamma in 8-bit encoded 3D-LUT. pre- and post per channel processing can help to reduce the artefacts. kind regards Kai-Uwe ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH 1/6] Add colorcorrection protocol
Am 31.03.2014 09:46, schrieb Pekka Paalanen: > On Sun, 30 Mar 2014 13:36:32 +0200 > Niels Ole Salscheider wrote: > >> The color correction protocol allows to attach an ICC profile to a >> surface. It also tells the client about the blending color space and >> the color spaces of all outputs. >> >> Signed-off-by: Niels Ole Salscheider >> --- >> Makefile.am | 15 ++-- >> protocol/colorcorrection.xml | 87 >> >> 2 files changed, 98 insertions(+), 4 deletions(-) >> create mode 100644 protocol/colorcorrection.xml >> >> diff --git a/Makefile.am b/Makefile.am >> index 5ff4f83..ec0a30b 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> @@ -76,7 +76,9 @@ nodist_weston_SOURCES = >> \ >> protocol/workspaces-protocol.c \ >> protocol/workspaces-server-protocol.h \ >> protocol/scaler-protocol.c \ >> -protocol/scaler-server-protocol.h >> +protocol/scaler-server-protocol.h \ >> +protocol/colorcorrection-protocol.c \ >> +protocol/colorcorrection-server-protocol.h >> >> BUILT_SOURCES += $(nodist_weston_SOURCES) >> >> @@ -426,7 +428,9 @@ nodist_libtoytoolkit_la_SOURCES = >> \ >> protocol/workspaces-protocol.c \ >> protocol/workspaces-client-protocol.h \ >> protocol/xdg-shell-protocol.c \ >> -protocol/xdg-shell-client-protocol.h >> +protocol/xdg-shell-client-protocol.h\ >> +protocol/colorcorrection-protocol.c \ >> +protocol/colorcorrection-client-protocol.h >> >> BUILT_SOURCES += $(nodist_libtoytoolkit_la_SOURCES) >> >> @@ -606,7 +610,9 @@ BUILT_SOURCES += \ >> protocol/workspaces-client-protocol.h \ >> protocol/workspaces-protocol.c \ >> protocol/xdg-shell-protocol.c \ >> -protocol/xdg-shell-client-protocol.h >> +protocol/xdg-shell-client-protocol.h\ >> +protocol/colorcorrection-protocol.c \ >> +protocol/colorcorrection-client-protocol.h >> >> >> westondatadir = $(datadir)/weston >> @@ -920,7 +926,8 @@ EXTRA_DIST +=\ >> protocol/text-cursor-position.xml \ >> protocol/wayland-test.xml \ >> protocol/xdg-shell.xml \ >> -protocol/scaler.xml >> +protocol/scaler.xml \ >> +protocol/colorcorrection.xml >> >> man_MANS = weston.1 weston.ini.5 >> >> diff --git a/protocol/colorcorrection.xml b/protocol/colorcorrection.xml >> new file mode 100644 >> index 000..7986e93 >> --- /dev/null >> +++ b/protocol/colorcorrection.xml >> @@ -0,0 +1,87 @@ >> + >> + >> + >> + >> +Copyright © 2014 Niels Ole Salscheider >> + >> +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. >> + >> + >> + >> + >> + This interface allows to attach a color profile to a wl_surface. >> + This is used by the compositor to display the colors correctly. >> + The client is informed by two events about the blending space used >> + by the compositor and the color spaces of the outputs. >> + >> + >> + >> + >> +With this request, the color profile of a wl_surface can be set. >> +When mode is set to "profile", an ICC profile can be passed in the >> +"profile_data" argument. In all other cases, "profile_data" is >> +ignored. >> +"mode" should only be set to "uncorrected" for fullscreen applications >> +or applications that really require uncorrected output (e. g. color >> +profiling tools). >> + >> + >> + >> +
Re: [RFC PATCH 1/6] Add colorcorrection protocol
On 31 March 2014 08:46, Pekka Paalanen wrote: > how much data can an ICC profile be? Printer profiles can be several megabytes in size, but display profiles (what will be seen here) are usually in the 20-30kb size range. > Also, what if a client has several surfaces all with the same ICC > profile, would it not be useful to have some notion of re-using an > already sent and parsed color profile? Otherwise I would imagine lots > of overhead if every surface has a private copy of the profile > sent over the wire, parsed, and stored in the compositor's renderer. I don't think typically they'll be many different profiles in use, on a typical system most things will just be (assumed) sRGB to 'n' display profiles, where n is the number of outputs. > Is that a reasonable requirement for all compositors that support > per-output ICC profiles? I think it's a very little amount of work, IMO doing it centrally makes a lot of sense as some bits are tricky to do correctly. Overall, I'm very happy to see someone pick up this work. Thanks. Richard. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [libinput] AC_PROG_CXX missing in libinput/configure.ac
On Mon, Mar 31, 2014 at 08:08:32AM +1000, Peter Hutterer wrote: > note that the only binary that needs a C++ compiler is the C++ build test. > the library itself only needs a C compiler. A good thing, would be to compile the lib with tinycc and/or open64 to kind of be sure it's not hard dependent on gcc. -- Sylvain ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH 1/6] Add colorcorrection protocol
On Sun, 30 Mar 2014 13:36:32 +0200 Niels Ole Salscheider wrote: > The color correction protocol allows to attach an ICC profile to a > surface. It also tells the client about the blending color space and > the color spaces of all outputs. > > Signed-off-by: Niels Ole Salscheider > --- > Makefile.am | 15 ++-- > protocol/colorcorrection.xml | 87 > > 2 files changed, 98 insertions(+), 4 deletions(-) > create mode 100644 protocol/colorcorrection.xml > > diff --git a/Makefile.am b/Makefile.am > index 5ff4f83..ec0a30b 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -76,7 +76,9 @@ nodist_weston_SOURCES = > \ > protocol/workspaces-protocol.c \ > protocol/workspaces-server-protocol.h \ > protocol/scaler-protocol.c \ > - protocol/scaler-server-protocol.h > + protocol/scaler-server-protocol.h \ > + protocol/colorcorrection-protocol.c \ > + protocol/colorcorrection-server-protocol.h > > BUILT_SOURCES += $(nodist_weston_SOURCES) > > @@ -426,7 +428,9 @@ nodist_libtoytoolkit_la_SOURCES = \ > protocol/workspaces-protocol.c \ > protocol/workspaces-client-protocol.h \ > protocol/xdg-shell-protocol.c \ > - protocol/xdg-shell-client-protocol.h > + protocol/xdg-shell-client-protocol.h\ > + protocol/colorcorrection-protocol.c \ > + protocol/colorcorrection-client-protocol.h > > BUILT_SOURCES += $(nodist_libtoytoolkit_la_SOURCES) > > @@ -606,7 +610,9 @@ BUILT_SOURCES += \ > protocol/workspaces-client-protocol.h \ > protocol/workspaces-protocol.c \ > protocol/xdg-shell-protocol.c \ > - protocol/xdg-shell-client-protocol.h > + protocol/xdg-shell-client-protocol.h\ > + protocol/colorcorrection-protocol.c \ > + protocol/colorcorrection-client-protocol.h > > > westondatadir = $(datadir)/weston > @@ -920,7 +926,8 @@ EXTRA_DIST += \ > protocol/text-cursor-position.xml \ > protocol/wayland-test.xml \ > protocol/xdg-shell.xml \ > - protocol/scaler.xml > + protocol/scaler.xml \ > + protocol/colorcorrection.xml > > man_MANS = weston.1 weston.ini.5 > > diff --git a/protocol/colorcorrection.xml b/protocol/colorcorrection.xml > new file mode 100644 > index 000..7986e93 > --- /dev/null > +++ b/protocol/colorcorrection.xml > @@ -0,0 +1,87 @@ > + > + > + > + > +Copyright © 2014 Niels Ole Salscheider > + > +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. > + > + > + > + > + This interface allows to attach a color profile to a wl_surface. > + This is used by the compositor to display the colors correctly. > + The client is informed by two events about the blending space used > + by the compositor and the color spaces of the outputs. > + > + > + > + > + With this request, the color profile of a wl_surface can be set. > + When mode is set to "profile", an ICC profile can be passed in the > + "profile_data" argument. In all other cases, "profile_data" is > + ignored. > + "mode" should only be set to "uncorrected" for fullscreen applications > + or applications that really require uncorrected output (e. g. color > + profiling tools). > + > + > + > + Hi, how much data can an ICC profile be? I'm wondering whether it makes sense to send it inline in the protocol stream like this. E
Re: [PATCH V2 1/8] wesston: Add weston randr protocol
On Mon, 31 Mar 2014 02:48:09 + "Wang, Quanxian" wrote: > > > >-Original Message- > >From: Pekka Paalanen [mailto:ppaala...@gmail.com] > >Sent: Friday, March 28, 2014 11:00 PM > >To: Wang, Quanxian > >Cc: wayland-devel@lists.freedesktop.org > >Subject: Re: [PATCH V2 1/8] wesston: Add weston randr protocol > > > >On Mon, 24 Mar 2014 19:39:13 +0800 > >Quanxian Wang wrote: > > > >> Weston protocol wrandr will provide interface to > >> 1) Mode set of output (scale, transform, mode) > >> 2) Position of output (currently support leftof, rightof) > >> 3) New a custom mode > >> 4) Delete mode > >> > >> This protocol is not expose public. It is only for QA testing and > >> Admin configuration currently. > >> > >> Signed-off-by: Quanxian Wang > >> --- > >> protocol/Makefile.am | 1 + > >> protocol/randr.xml | 228 > >+++ > >> 2 files changed, 229 insertions(+) > >> create mode 100644 protocol/randr.xml > >> > >> diff --git a/protocol/Makefile.am b/protocol/Makefile.am index > >> 5e331a7..df2e070 100644 > >> --- a/protocol/Makefile.am > >> +++ b/protocol/Makefile.am > >> @@ -5,6 +5,7 @@ protocol_sources = \ > >>text.xml\ > >>input-method.xml\ > >>workspaces.xml \ > >> + randr.xml \ > >>text-cursor-position.xml\ > >>wayland-test.xml\ > >>xdg-shell.xml \ > >> diff --git a/protocol/randr.xml b/protocol/randr.xml new file mode > >> 100644 index 000..07f83a4 > >> --- /dev/null > >> +++ b/protocol/randr.xml > >> @@ -0,0 +1,228 @@ > >> + > >> + > >> + > >> +Copyright (c) 2014 Quanxian Wang > >> +Copyright (c) 2014 Intel Corporation > >> + > >> +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. > >> + > >> + > >> + > >> + > >> + The global interface exposing randr capabilities. > >> + As a weston_randr, that provides the interfaces for apps to more > >operations > >> + on output. > >> + > >> + The aim of weston_randr is to get modes list, choose preferred mode, > >> + layout the output including position, rotate, and en/disable. > >> + The idea is from xrandr protocoal of xserver. It is very convenient > >> for > >> + weston/wayland user to operates on mode setting of output. > >> + > >> + > >> + > >> + > >> + Informs the server that the client will not be using this > >> + protocol object anymore. This does not affect any other > >> + objects, weston_randr objects included. > >> + > >> + > >> + > >> + > >> + > >> + It is request notification when the next output randr commit > >> + is coming and is useful for notifying client the result of > >> + operations on the output. The randr request will take effect > >> + on the next weston_randr.commit. The notification will only be > >> + posted for one randr request unless requested again. > >> + > >> + > >> + >> +interface="wrandr_callback"/> > > > >Ok, the reply object is created as the first thing. What happens if you > >create > >multiple of them without sending commit in between? They all return the same > >result? > > > >Why do you have an output argument here? > >Are you explicitly forbidding the very useful case, where one could gather > >changes > >to multiple outputs into the same batch to be committed? > > > >I think that would be a misfeature. I don't see any reason to not allow > >changing > >multiple outputs in the same batch. Quite the contrary, when atomic > >modesetting > >becomes available in the kernel, we will be able to use it
