Re: [PATCH v7 wayland-protocols] Add the tablet protocol

[Peter Hutterer]

On Thu, Mar 31, 2016 at 02:17:02PM +0200, Carlos Garnacho wrote:
> Hey :),
> 
> On Thu, Mar 31, 2016 at 9:32 AM, Peter Hutterer
>  wrote:
> > sorry about the delay, this one slipped through
> >
> > On Fri, Mar 11, 2016 at 04:12:55PM -0800, Jason Gerecke wrote:
> >> On 03/08/2016 10:10 PM, Peter Hutterer wrote:
> >> > Signed-off-by: Peter Hutterer 
> >> > Reviewed-by: Daniel Stone 
> >> > Reviewed-by: Jonas Ådahl 
> >> > ---
> >> > Changes to v6:
> >> > - a bunch of typos/grammar fixes
> >> > - clarified the "down" event on enter
> >> > - clarified the "up" event, specifically: the up event isn't sent when 
> >> > the
> >> >   tool leaves the input region but rather when the compositor deems it's 
> >> > up
> >> >
> >
> > [...]
> >
> >> > +
> >> > +   Clients should choose either value and avoid mixing degrees and
> >> > +   clicks. The compositor may accumulate values smaller than a logical
> >> > +   click and emulate click events when a certain threshold is met.
> >> > +   Thus, wl_tablet_tool.wheel events with non-zero clicks values may
> >> > +   have different degrees values.
> >> > +  
> >> > +  
> >> > +  
> >> > +
> >>
> >> I just noticed this while working on the Xwayland implementation -- is
> >> there a reason the angles (in tilt, rotation, and here in wheel) aren't
> >> just using the "fixed" type? If its a wart, it might be one to remove
> >> before too long now that v1 has made it upstream...
> >
> > hmm, good point, not sure why I didn't use wl_fixed other than "i didn't
> > think of it". It has finer granularity and provides the required range, so
> > it would be the better choice. This is something to fix in a new version
> > though :(
> >
> > Carlos, any yay/nay comments for the GTK side?
> 
> It indeed makes sense, I also missed this after we started using
> angles for those. I guess this just means v2 will get its own file to
> keep ahead with the incompatible change, so be it...

I'll do that, but after we merged the pad protocol, I think. That one is
backwards-compat.

Cheers,
   Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Collaboration on standard Wayland protocol extensions

[Peter Hutterer]

On Thu, Mar 31, 2016 at 05:37:10PM +0200, Benoit Gschwind wrote:
> Hello Drew,
> 
> After reading the thread stream, I think there is two mixed questions in
> your email that is missleading. And most reply try to address both in
> one reply. I thing Daniel get the point (if I understood him well).
> 
> I read the two following questions:
> 
> [1] As almost all compositor will need the following features:
> - Screen capture
> - Output configuration
> - More detailed surface roles (should it be floating, is it a modal,
>   does it want to draw its own decorations, etc)
> - Input device configuration.
> 
> It would be nice if we go around a table to define some shared protocol.
> For those interested I will start writing an XML spec. you are welcome
> to contribute.

I'm mostly talking about the input device configuration here but an XML is
the wrong place to start, imo. As I said above, it won't add anything much
and you still have to do the implementation everywhere. The only meaningful
thing you can do is write a library that compositors *want* to use that
reads the configuration items from some magic place and applies them to the
libinput device.

and for those that must be handled in the compostior (key remappings, for
example) you'll essentially end up writing a libcompositorinput. but now
you're quite close to internal compositor semantics so making this a generic
thing is not going to be trivial.

Cheers,
   Peter

> 
> [2] This features are mandatory and should be in the core protocol.
> 
> 
> If my reading is correct, I reply to [1]:
> 
> I'm in, I would like to avoid implements tools that setup screen layout,
> keymaping and screen capture. Thus having a protocol to handle those
> case is welcome. From my point of view of WM developer (in opposition of
> DE developer)
> 
> 
> For [2], I suggest that you starting with not-adopted protocol
> specification and if they gather enough approval, you try to push it as
> _optionnal_ standard protocol. By optionnal I mean the compositor
> developer can choose to implement it or not. by standard I mean if a
> developer want implement those feature we strongly encouraged developper
> to use them instead of providing a new one.
> 
> Best regards.
> 
> --
> Benoit (blocage) Gschwind
> 
> Le 27/03/2016 22:34, Drew DeVault a écrit :
> > Greetings! I am the maintainer of the Sway Wayland compositor.
> > 
> > http://swaywm.org
> > 
> > It's almost the Year of Wayland on the Desktop(tm), and I have
> > reached out to each of the projects this message is addressed to (GNOME,
> > Kwin, and wayland-devel) to collaborate on some shared protocol
> > extensions for doing a handful of common tasks such as display
> > configuration and taking screenshots. Life will be much easier for
> > projects like ffmpeg and imagemagick if they don't have to implement
> > compositor-specific code for capturing the screen!
> > 
> > I want to start by establishing the requirements for these protocols.
> > Broadly speaking, I am looking to create protocols for the following
> > use-cases:
> > 
> > - Screen capture
> > - Output configuration
> > - More detailed surface roles (should it be floating, is it a modal,
> >   does it want to draw its own decorations, etc)
> > - Input device configuration
> > 
> > I think that these are the core protocols necessary for
> > cross-compositor compatability and to support most existing tools for
> > X11 like ffmpeg. Considering the security goals of Wayland, it will also
> > likely be necessary to implement some kind of protocol for requesting
> > and granting sensitive permissions to clients.
> > 
> > How does this list look? What sorts of concerns do you guys have with
> > respect to what features each protocol needs to support? Have I missed
> > any major protocols that we'll have to work on? Once we have a good list
> > of requirements I'll start writing some XML.
> > 
> > --
> > Drew DeVault
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > 
> ___
> desktop-devel-list mailing list
> desktop-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: history/semantics of uint32_t name

[Jonas Ådahl]

On Thu, Mar 31, 2016 at 06:48:06PM -0500, Yong Bakos wrote:
> Hi,
> I've been investigating the semantics of the name parameter within the 
> wl_registry interface, prompted by a recent dialog regarding my patch of arg 
> summary attributes in wayland.xml.
> 
> I've dug around the Weston source to see what values are passed as the name 
> argument, and where it goes... and I'm at a bit of a loss. This argument is 
> always an integer, and seems like it's just passed around and never even used 
> for anything! I feel like I must be missing something, hence this question: 
> what is this `name` argument in wl_registry_bind, wl_registry_send_global, 
> and wl_registry_send_global_remove? Why is it called name when it is merely a 
> numeric identifier? Shouldn't it be called `id`? 
> 
> I'd love to see where this argument is used within the weston source, so if 
> you know a file:line you can point me to, I'll add one beer to your queue.
> 

Each global object has a unique "name" used for identifying them. There
may be multiple objects of the same interface, but they'll all have
unique names. For example there may be multiple wl_output's and multiple
wl_seat's, all with different "names".

When the client binds a global, it will pass the "name" (the uint32_t
identifier) so that the server can know which of the globals it tries to
bind. Just an interface name would not be enough because, as I
mentioned, there may be multiple globals with the same interface, but
the client is binding just one of the advertised globals.

You are not finding the use of "name" anywhere in the weston source code
because the registry is implemented in libwayland-server.so. See
registry_bind() in wayland-server.c.

I can't say for sure the reason behind using "name", but using "id"
would potentially be confused with the object "id"'s.


Jonas

> Thank you,
> yong
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] scanner: Fix spacing of @param

[Peter Hutterer]

On Thu, Mar 31, 2016 at 06:55:54PM -0500, Yong Bakos wrote:
> From: Yong Bakos 
> 
> Adds one space to the @param lines in generated .h files,
> aligning the indentation with the rest of the comment block.
> 
> Signed-off-by: Yong Bakos 

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  src/scanner.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/scanner.c b/src/scanner.c
> index a895f92..65df3ae 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -1148,7 +1148,7 @@ emit_event_wrappers(struct wl_list *message_list, 
> struct interface *interface)
>  " * Sends an %s event to the client owning the 
> resource.\n",
>  interface->name,
>  m->name);
> - printf("* @param resource_ The client's resource\n");
> + printf(" * @param resource_ The client's resource\n");
>   wl_list_for_each(a, &m->arg_list, link) {
>   if (a->summary)
>   printf(" * @param %s %s\n", a->name, 
> a->summary);
> -- 
> 2.7.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 3/4] test: add a test for the T450 dropped motion events

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 test/touchpad.c | 67 +
 1 file changed, 67 insertions(+)

diff --git a/test/touchpad.c b/test/touchpad.c
index be9c566..4651b7a 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -3924,6 +3924,72 @@ START_TEST(touchpad_tool_tripletap_touch_count)
 }
 END_TEST
 
+START_TEST(touchpad_t450_motion_drops)
+{
+   struct litest_device *dev = litest_current_device();
+   struct libinput *li = dev->libinput;
+   struct libinput_event *event;
+   struct libinput_event_pointer *ptrev;
+   int i;
+   double d;
+
+   /* In some areas on the touchpad we only get pressure events.
+* https://bugs.freedesktop.org/show_bug.cgi?id=94379
+*/
+   litest_drain_events(li);
+
+   litest_touch_down(dev, 0, 50, 50);
+
+   for (i = 0; i < 10; i++) {
+   litest_event(dev, EV_ABS, ABS_MT_SLOT, 0);
+   litest_event(dev, EV_ABS, ABS_MT_POSITION_X, 3000 - i);
+   litest_event(dev, EV_ABS, ABS_MT_POSITION_Y, 3000 - i);
+   litest_event(dev, EV_ABS, ABS_MT_PRESSURE, 30);
+   litest_event(dev, EV_ABS, ABS_X, 3000 - i);
+   litest_event(dev, EV_ABS, ABS_Y, 3000 - i);
+   litest_event(dev, EV_ABS, ABS_PRESSURE, 30);
+   litest_event(dev, EV_SYN, SYN_REPORT, 0);
+   litest_drain_events(li);
+   }
+
+   /* several pressure-only events */
+
+   for (i = 0; i< 20; i++) {
+   litest_event(dev, EV_ABS, ABS_MT_PRESSURE, 30 + i % 2);
+   litest_event(dev, EV_ABS, ABS_PRESSURE, 30 + i % 2);
+   litest_event(dev, EV_SYN, SYN_REPORT, 0);
+   litest_assert_empty_queue(li);
+   }
+
+   /* a 100 unit jump followed by fine-grained motion, we expect small
+* motions without the jump */
+
+   for (i = 0; i < 10; i++) {
+   litest_event(dev, EV_ABS, ABS_MT_SLOT, 0);
+   litest_event(dev, EV_ABS, ABS_MT_POSITION_X, 3100 + i);
+   litest_event(dev, EV_ABS, ABS_MT_POSITION_Y, 3100 + i);
+   litest_event(dev, EV_ABS, ABS_X, 3100 + i);
+   litest_event(dev, EV_ABS, ABS_Y, 3100 + i);
+   litest_event(dev, EV_ABS, ABS_PRESSURE, 30);
+   litest_event(dev, EV_SYN, SYN_REPORT, 0);
+   libinput_dispatch(li);
+   }
+
+   event = libinput_get_event(li);
+   ck_assert_notnull(event);
+   while (event) {
+   ptrev = litest_is_motion_event(event);
+   d = libinput_event_pointer_get_dx(ptrev);
+   litest_assert_double_lt(d, 1.0);
+   d = libinput_event_pointer_get_dy(ptrev);
+   litest_assert_double_lt(d, 1.0);
+   libinput_event_destroy(event);
+
+   event = libinput_get_event(li);
+   }
+}
+END_TEST
+
 START_TEST(touchpad_time_usec)
 {
struct litest_device *dev = litest_current_device();
@@ -4075,6 +4141,7 @@ litest_setup_tests(void)
litest_add("touchpad:thumb", touchpad_thumb_tap_hold_2ndfg_tap, 
LITEST_CLICKPAD, LITEST_SINGLE_TOUCH);
 
litest_add_for_device("touchpad:bugs", 
touchpad_tool_tripletap_touch_count, LITEST_SYNAPTICS_TOPBUTTONPAD);
+   litest_add_for_device("touchpad:bugs", touchpad_t450_motion_drops, 
LITEST_SYNAPTICS_TRACKPOINT_BUTTONS);
 
litest_add("touchpad:time", touchpad_time_usec, LITEST_TOUCHPAD, 
LITEST_ANY);
 }
-- 
2.5.0

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

[PATCH libinput 4/4] touchpad: reset the motion history on significant negative pressure changes

[Peter Hutterer]

Resetting the motion history has the side-effect of swallowing movements, we
don't calculate deltas until we have 4 motion events. During a finger release,
we're likely to get a large pressure change between two events, resetting the
motion history prevents the cursor from jumping on release.

The value of 7 found by trial-and-error, tested on the T440 and T450 hardware.
The absolute value is highly variable but recordings show that the pressure
changes only by 1 or 2 units during normal interaction. Higher pressure
changes are during finger position changes but since those should not cause a
jump anyway, we tend to win there too.

Currently only enabled for negative pressure changes, let's see how we go with
that.

https://bugs.freedesktop.org/show_bug.cgi?id=94379

Signed-off-by: Peter Hutterer 
---
 src/evdev-mt-touchpad.c |  4 
 src/evdev-mt-touchpad.h |  1 +
 test/litest.c   | 38 +++---
 test/litest.h   |  7 +++
 test/touchpad.c |  2 +-
 5 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index e16aecb..0640974 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -335,6 +335,7 @@ tp_process_absolute(struct tp_dispatch *tp,
tp_end_sequence(tp, t, time);
break;
case ABS_MT_PRESSURE:
+   t->pressure_delta = e->value - t->pressure;
t->pressure = e->value;
t->dirty = true;
tp->queued |= TOUCHPAD_EVENT_OTHERAXIS;
@@ -946,6 +947,9 @@ tp_process_state(struct tp_dispatch *tp, uint64_t time)
if (!t->dirty)
continue;
 
+   if (t->pressure_delta < -7)
+   tp_motion_history_reset(t);
+
tp_thumb_detect(tp, t, time);
tp_palm_detect(tp, t, time);
 
diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
index 1f05a03..d1dae83 100644
--- a/src/evdev-mt-touchpad.h
+++ b/src/evdev-mt-touchpad.h
@@ -154,6 +154,7 @@ struct tp_touch {
uint64_t millis;
int distance;   /* distance == 0 means touch */
int pressure;
+   int pressure_delta;
 
struct {
/* A quirk mostly used on Synaptics touchpads. In a
diff --git a/test/litest.c b/test/litest.c
index f679652..1d729ef 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -1494,23 +1494,39 @@ litest_touch_move_extended(struct litest_device *d,
 }
 
 void
+litest_touch_move_to_extended(struct litest_device *d,
+ unsigned int slot,
+ double x_from, double y_from,
+ double x_to, double y_to,
+ struct axis_replacement *axes,
+ int steps, int sleep_ms)
+{
+   for (int i = 0; i < steps - 1; i++) {
+   litest_touch_move_extended(d, slot,
+  x_from + (x_to - x_from)/steps * i,
+  y_from + (y_to - y_from)/steps * i,
+  axes);
+   if (sleep_ms) {
+   libinput_dispatch(d->libinput);
+   msleep(sleep_ms);
+   libinput_dispatch(d->libinput);
+   }
+   }
+   litest_touch_move_extended(d, slot, x_to, y_to, axes);
+}
+
+void
 litest_touch_move_to(struct litest_device *d,
 unsigned int slot,
 double x_from, double y_from,
 double x_to, double y_to,
 int steps, int sleep_ms)
 {
-   for (int i = 0; i < steps - 1; i++) {
-   litest_touch_move(d, slot,
- x_from + (x_to - x_from)/steps * i,
- y_from + (y_to - y_from)/steps * i);
-   if (sleep_ms) {
-   libinput_dispatch(d->libinput);
-   msleep(sleep_ms);
-   libinput_dispatch(d->libinput);
-   }
-   }
-   litest_touch_move(d, slot, x_to, y_to);
+   litest_touch_move_to_extended(d, slot,
+ x_from, y_from,
+ x_to, y_to,
+ NULL,
+ steps, sleep_ms);
 }
 
 static int
diff --git a/test/litest.h b/test/litest.h
index e854210..c218361 100644
--- a/test/litest.h
+++ b/test/litest.h
@@ -403,6 +403,13 @@ litest_touch_move_to(struct litest_device *d,
 double x_from, double y_from,
 double x_to, double y_to,
 int steps, int sleep_ms);
+void
+litest_touch_move_to_extended(struct litest_device *d,
+ unsigned int slot,
+ double x_from, double y_from,
+ 

[PATCH libinput 1/4] test: apply the new t450 model flag to our X1 3rd test device

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 test/litest-device-synaptics-x1-carbon-3rd.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/test/litest-device-synaptics-x1-carbon-3rd.c 
b/test/litest-device-synaptics-x1-carbon-3rd.c
index 718d108..23d9c5b 100644
--- a/test/litest-device-synaptics-x1-carbon-3rd.c
+++ b/test/litest-device-synaptics-x1-carbon-3rd.c
@@ -114,6 +114,16 @@ static struct input_absinfo absinfo[] = {
{ .value = -1 }
 };
 
+static const char udev_rule[] =
+"ACTION==\"remove\", GOTO=\"touchpad_end\"\n"
+"KERNEL!=\"event*\", GOTO=\"touchpad_end\"\n"
+"ENV{ID_INPUT_TOUCHPAD}==\"\", GOTO=\"touchpad_end\"\n"
+"\n"
+"ATTRS{name}==\"litest SynPS/2 Synaptics TouchPad X1C3rd\","
+"ENV{LIBINPUT_MODEL_LENOVO_T450_TOUCHPAD}=\"1\"\n"
+"\n"
+"LABEL=\"touchpad_end\"";
+
 struct litest_test_device litest_synaptics_carbon3rd_device = {
.type = LITEST_SYNAPTICS_TRACKPOINT_BUTTONS,
.features = LITEST_TOUCHPAD | LITEST_CLICKPAD | LITEST_BUTTON,
@@ -125,4 +135,5 @@ struct litest_test_device litest_synaptics_carbon3rd_device 
= {
.id = &input_id,
.events = events,
.absinfo = absinfo,
+   .udev_rule = udev_rule,
 };
-- 
2.5.0

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

[PATCH libinput 2/4] touchpad: only post motion events if we have motion

[Peter Hutterer]

Because our delta calculation factors in previous events on touchpads (to
reduce jitter) we may get a nonzero delta if we have an event that doesn't
actually change x or y.

Drop the t->dirty workaround introduced in a608d9d, an event that virtually
disappears can mess up our state machines.

Signed-off-by: Peter Hutterer 
---
 src/evdev-mt-touchpad-gestures.c | 3 ++-
 src/evdev-mt-touchpad.c  | 5 +
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/src/evdev-mt-touchpad-gestures.c b/src/evdev-mt-touchpad-gestures.c
index 3c8f5a7..7bbd3b8 100644
--- a/src/evdev-mt-touchpad-gestures.c
+++ b/src/evdev-mt-touchpad-gestures.c
@@ -500,7 +500,8 @@ tp_gesture_post_events(struct tp_dispatch *tp, uint64_t 
time)
 
switch (tp->gesture.finger_count) {
case 1:
-   tp_gesture_post_pointer_motion(tp, time);
+   if (tp->queued & TOUCHPAD_EVENT_MOTION)
+   tp_gesture_post_pointer_motion(tp, time);
break;
case 2:
case 3:
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index f634ec8..e16aecb 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -904,10 +904,7 @@ tp_need_motion_history_reset(struct tp_dispatch *tp)
if (tp->device->model_flags & EVDEV_MODEL_LENOVO_T450_TOUCHPAD) {
if (tp->queued & TOUCHPAD_EVENT_MOTION) {
if (tp->quirks.nonmotion_event_count > 10) {
-   struct tp_touch *t;
-
-   tp_for_each_touch(tp, t)
-   t->dirty = false;
+   tp->queued &= ~TOUCHPAD_EVENT_MOTION;
rc = true;
}
tp->quirks.nonmotion_event_count = 0;
-- 
2.5.0

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

[PATCH wayland] scanner: Fix spacing of @param

[Yong Bakos]

From: Yong Bakos 

Adds one space to the @param lines in generated .h files,
aligning the indentation with the rest of the comment block.

Signed-off-by: Yong Bakos 
---
 src/scanner.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/scanner.c b/src/scanner.c
index a895f92..65df3ae 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1148,7 +1148,7 @@ emit_event_wrappers(struct wl_list *message_list, struct 
interface *interface)
   " * Sends an %s event to the client owning the 
resource.\n",
   interface->name,
   m->name);
-   printf("* @param resource_ The client's resource\n");
+   printf(" * @param resource_ The client's resource\n");
wl_list_for_each(a, &m->arg_list, link) {
if (a->summary)
printf(" * @param %s %s\n", a->name, 
a->summary);
-- 
2.7.2

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

Re: history/semantics of uint32_t name

[Jasper St. Pierre]

wl_registry and wl_registry.bind are about globals and creating new
instances of globals.

A compositor can opt to provide a new global interface by using the
wl_global_create API. Immediately, an event is broadcasted to all
clients: the wl_registry.global event, which contains a name (the
uint32_t parameter), an interface (which is a string). If the user
wants to bind such a global, it passes that back to wl_registry.bind,
to get an instance of that global.

Why wasn't the interface used instead? I'm not sure. I imagine it was
to enforce that binding is done through the global event rather than
allowing a client to attempt to bind random objects through strings.

On Thu, Mar 31, 2016 at 4:48 PM, Yong Bakos  wrote:
> Hi,
> I've been investigating the semantics of the name parameter within the 
> wl_registry interface, prompted by a recent dialog regarding my patch of arg 
> summary attributes in wayland.xml.
>
> I've dug around the Weston source to see what values are passed as the name 
> argument, and where it goes... and I'm at a bit of a loss. This argument is 
> always an integer, and seems like it's just passed around and never even used 
> for anything! I feel like I must be missing something, hence this question: 
> what is this `name` argument in wl_registry_bind, wl_registry_send_global, 
> and wl_registry_send_global_remove? Why is it called name when it is merely a 
> numeric identifier? Shouldn't it be called `id`?
>
> I'd love to see where this argument is used within the weston source, so if 
> you know a file:line you can point me to, I'll add one beer to your queue.
>
> Thank you,
> yong
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

history/semantics of uint32_t name

[Yong Bakos]

Hi,
I've been investigating the semantics of the name parameter within the 
wl_registry interface, prompted by a recent dialog regarding my patch of arg 
summary attributes in wayland.xml.

I've dug around the Weston source to see what values are passed as the name 
argument, and where it goes... and I'm at a bit of a loss. This argument is 
always an integer, and seems like it's just passed around and never even used 
for anything! I feel like I must be missing something, hence this question: 
what is this `name` argument in wl_registry_bind, wl_registry_send_global, and 
wl_registry_send_global_remove? Why is it called name when it is merely a 
numeric identifier? Shouldn't it be called `id`? 

I'd love to see where this argument is used within the weston source, so if you 
know a file:line you can point me to, I'll add one beer to your queue.

Thank you,
yong


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

Collaboration on standard Wayland protocol extensions

[Ladislav Igrec]

hello, i have a proposal for this
first time using a mailing list so i hope i do it right-ish


protocol for screenshots:

client -> server: "can i get a screenshot ?"
server -> client: "sure, here it is" / "no"
server would send the screenshot via memfd or write() or something.
something like [type/format][length][data] (bit more futureproof then that, 
though)

for hotkeys:
client -> server: "can i get all alt+F5 events ?"
server -> client: "sure, i'l send them to you" / "no"

for streaming, i don't know how exactly does it work under wayland.
if a compositor can close the stream, then there is no problem

i suggest the transport layer to be UDS for 3 reasons
1. if the file is not in the predetermined place (example 
/run/wayland-ext/$COMPOSITOR_PID) then the compositor obviously doesn't support 
the extensions
(while at it, this doesn't have to be wayland exclusive)
2. the compositor can check the PID of the client
3. the compositor can send fds


rationales:
the list of supported features does not have to be gotten as the compositor 
saying "no" means "no", for whatever reason.
ofc the "what do you support" should be part of the protocol anyway
(the "no" can also be "NO_PRIVILEDGE" or "IDK_WHAT_YOU_ARE_TALKING_ABOUT")

it being UDS the compositor can get the PID, UID and GID of the client.
the compositor can then verify the client by looking at its /proc/$PID/exe.

this minimizes the whole priviledges thing in the protocol and lets the 
compositor writers choose how they will implement it.
examples:
a compositor that always does/allows what it can.
a compositor that asks the user then (optionally) remembers the answer
a compositor that asks some priviledges daemon "can this process do this?"

i would suggest that the compositor makes a list in human readable format in a 
file that only the "wayland_compositor" GID can read or write to.
something like:
$EXE_FROM_PROC $UID $GID PERMISSION1 PERMISSION2 etc..



Ladislav Igrec

"hope-ing he is making sense"
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Collaboration on standard Wayland protocol extensions

[Benoit Gschwind]

Hello Drew,

After reading the thread stream, I think there is two mixed questions in
your email that is missleading. And most reply try to address both in
one reply. I thing Daniel get the point (if I understood him well).

I read the two following questions:

[1] As almost all compositor will need the following features:
- Screen capture
- Output configuration
- More detailed surface roles (should it be floating, is it a modal,
  does it want to draw its own decorations, etc)
- Input device configuration.

It would be nice if we go around a table to define some shared protocol.
For those interested I will start writing an XML spec. you are welcome
to contribute.

[2] This features are mandatory and should be in the core protocol.


If my reading is correct, I reply to [1]:

I'm in, I would like to avoid implements tools that setup screen layout,
keymaping and screen capture. Thus having a protocol to handle those
case is welcome. From my point of view of WM developer (in opposition of
DE developer)


For [2], I suggest that you starting with not-adopted protocol
specification and if they gather enough approval, you try to push it as
_optionnal_ standard protocol. By optionnal I mean the compositor
developer can choose to implement it or not. by standard I mean if a
developer want implement those feature we strongly encouraged developper
to use them instead of providing a new one.

Best regards.

--
Benoit (blocage) Gschwind

Le 27/03/2016 22:34, Drew DeVault a écrit :
> Greetings! I am the maintainer of the Sway Wayland compositor.
> 
> http://swaywm.org
> 
> It's almost the Year of Wayland on the Desktop(tm), and I have
> reached out to each of the projects this message is addressed to (GNOME,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
> 
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:
> 
> - Screen capture
> - Output configuration
> - More detailed surface roles (should it be floating, is it a modal,
>   does it want to draw its own decorations, etc)
> - Input device configuration
> 
> I think that these are the core protocols necessary for
> cross-compositor compatability and to support most existing tools for
> X11 like ffmpeg. Considering the security goals of Wayland, it will also
> likely be necessary to implement some kind of protocol for requesting
> and granting sensitive permissions to clients.
> 
> How does this list look? What sorts of concerns do you guys have with
> respect to what features each protocol needs to support? Have I missed
> any major protocols that we'll have to work on? Once we have a good list
> of requirements I'll start writing some XML.
> 
> --
> Drew DeVault
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] protocol: Add summaries to event parameters

[Yong Bakos]

> On Mar 30, 2016, at 12:53 PM, Bryce Harrington  wrote:
> 
> On Tue, Mar 29, 2016 at 06:04:49PM -0500, Yong Bakos wrote:
>> From: Yong Bakos 
>> 
>> All event arg elements now have an appropriate summary attribute.
>> This was conducted mostly in response to the undocumented parameter
>> warnings generated during 'make check'.
>> 
>> Signed-off-by: Yong Bakos 
> 
> Will be nice to see fewer warnings!  :-)
> 
> My review is a cursory doublecheck of each line against the
> corresponding description field in wayland.xml.  Everything looks fine,
> but I have a few suggestions/comments below.
> 
>> ---
>> protocol/wayland.xml | 128 
>> ++-
>> 1 file changed, 65 insertions(+), 63 deletions(-)
>> 
>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> index 8739cd3..dffb708 100644
>> --- a/protocol/wayland.xml
>> +++ b/protocol/wayland.xml
>> @@ -70,9 +70,9 @@
>>  own set of error codes.  The message is an brief description
>>  of the error, for (debugging) convenience.
>>   
>> -  
>> -  
>> -  
>> +  
>> +  
>> +  
>> 
>> 
>> 
>> @@ -96,7 +96,7 @@
>>  When the client receive this event, it will know that it can
>>  safely reuse the object ID.
>>   
>> -  
>> +  
>> 
>>   
>> 
>> @@ -141,9 +141,9 @@
>> the given name is now available, and it implements the
>> given version of the given interface.
>>   
>> -  
>> -  
>> -  
>> +  
>> +  
>> +  
>> 
>> 
>> 
>> @@ -159,7 +159,7 @@
>>  ignored until the client destroys it, to avoid races between
>>  the global going away and a client sending a request to it.
>>   
>> -  
>> +  
> 
> Generally names are strings, so might be worth in this case indicating
> that this is something different?  I'm not actually sure what this uint
> name parameter is exactly, is it an index into a list of strings?  Or is
> it not really a name but more like an ID number?

I'll dig into this to clarify; I believe I based this off another similar
property description elsewhere.


>> 
>>   
>> 
>> @@ -367,7 +367,7 @@
>>  can be used for buffers. Known formats include
>>  argb and xrgb.
>>   
>> -  
>> +  
>> 
>>   
>> 
>> @@ -485,7 +485,7 @@
>>  event per offered mime type.
>>   
>> 
>> -  
>> +  
>> 
>> 
>> 
>> @@ -550,7 +550,7 @@
>>  will be sent right after wl_data_device.enter, or anytime the source
>>  side changes its offered actions through wl_data_source.set_actions.
>>   
>> -  
>> +  
>> 
>> 
>> 
>> @@ -591,7 +591,7 @@
>>  final wl_data_offer.set_actions and wl_data_offer.accept requests
>>  must happen before the call to wl_data_offer.finish.
>>   
>> -  
>> +  
>> 
>>   
>> 
>> @@ -633,7 +633,7 @@
>>  Used for feedback during drag-and-drop.
>>   
>> 
>> -  
>> +  
>> 
>> 
>> 
>> @@ -643,8 +643,8 @@
>>  close it.
>>   
>> 
>> -  
>> -  
>> +  
>> +  
>> 
>> 
>> 
>> @@ -746,7 +746,7 @@
>>  Clients can trigger cursor surface changes from this point, so
>>  they reflect the current action.
>>   
>> -  
>> +  
>> 
>>   
>> 
>> @@ -821,7 +821,7 @@
>>  mime types it offers.
>>   
>> 
>> -  
>> +  
>> 
>> 
>> 
>> @@ -832,11 +832,12 @@
>>  local coordinates.
>>   
>> 
>> -  
>> -  
>> -  
>> -  
>> -  > allow-null="true"/>
>> +  
>> +  > summary="client surface entered"/>
>> +  
>> +  
>> +  > allow-null="true"
>> +   summary="source data_offer object"/>
> 
> I don't know if it really matters, but the description uses the phrasing
> "surface local coordinates" so I wonder if the x and y coordinate
> summaries should follow suit?

/Yes/! But in this patch I forced myself to stick to precedent for all
summary additions. I have a separate patch coming that standardizes the
use of "surface local," along with numerous grammar/spelling corrections.


>> 
>> 
>> 
>> @@ -855,8 +856,8 @@
>>  coordinates.
>>   
>>   
>> -  
>> -  
>> +  
>> +  
>> 
>> 
>> 
>> @@ -891,7 +892,8 @@
>>  destroy the previous selection data_offer, if any, upon receiving
>>  this event.
>>   
>> -  > allow-null="true"/>
>> +  > allow-null="true"
>> +   summary="selection data_offer object"/>
>> 
>> 
>> 
>> @@ -1231,7 +1233,7 @@
>>  Ping a client to check if it is receiving events and sending
>>  requests. A client is expected to reply with a pong request.
>>   
>> -  
>> +  
>> 
> 
> "serial number of the ping"

Got it, for all subsequent occurrences too.


>> 
>> @@ -1255,9 +1257,9 @@
>>  in surface local coordinates.
>>   
>> 
>> -  
>> -  
>> -  
>> +  
>> +  
>> +  
>> 
>> 
>> 
>> @@ -1533,7 +1535,7 @@
>> 
>>  Note t

Re: [PATCH v7 wayland-protocols] Add the tablet protocol

[Carlos Garnacho]

Hey :),

On Thu, Mar 31, 2016 at 9:32 AM, Peter Hutterer
 wrote:
> sorry about the delay, this one slipped through
>
> On Fri, Mar 11, 2016 at 04:12:55PM -0800, Jason Gerecke wrote:
>> On 03/08/2016 10:10 PM, Peter Hutterer wrote:
>> > Signed-off-by: Peter Hutterer 
>> > Reviewed-by: Daniel Stone 
>> > Reviewed-by: Jonas Ådahl 
>> > ---
>> > Changes to v6:
>> > - a bunch of typos/grammar fixes
>> > - clarified the "down" event on enter
>> > - clarified the "up" event, specifically: the up event isn't sent when the
>> >   tool leaves the input region but rather when the compositor deems it's up
>> >
>
> [...]
>
>> > +
>> > +   Clients should choose either value and avoid mixing degrees and
>> > +   clicks. The compositor may accumulate values smaller than a logical
>> > +   click and emulate click events when a certain threshold is met.
>> > +   Thus, wl_tablet_tool.wheel events with non-zero clicks values may
>> > +   have different degrees values.
>> > +  
>> > +  
>> > +  
>> > +
>>
>> I just noticed this while working on the Xwayland implementation -- is
>> there a reason the angles (in tilt, rotation, and here in wheel) aren't
>> just using the "fixed" type? If its a wart, it might be one to remove
>> before too long now that v1 has made it upstream...
>
> hmm, good point, not sure why I didn't use wl_fixed other than "i didn't
> think of it". It has finer granularity and provides the required range, so
> it would be the better choice. This is something to fix in a new version
> though :(
>
> Carlos, any yay/nay comments for the GTK side?

It indeed makes sense, I also missed this after we started using
angles for those. I guess this just means v2 will get its own file to
keep ahead with the incompatible change, so be it...

Cheers,
  Carlos

>
> Cheers,
>Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Spice-devel] Questions about experimental Spice compositor rebase

[Christophe Fergeau]

Hey,

On Sun, Feb 28, 2016 at 03:36:58PM +0100, Fabio Fantoni wrote:
> 
> I did fast build tests, I fixed one my mistake in Makefile.am and after I
> had this error:
> >src/spice/weston_basic_event_loop.h:27:31: fatal error: weston/compositor.h: 
> >No such file or directory
> I fixed with this even if I'm not sure it is correct:
> https://github.com/Fantu/compositor-spice/commit/92f8eeb50e593a489e23b5ddeb38edf0985603f2
> 
> Now I had these errors:
> >src/spice/compositor-spice.c: In function
> >'spice_output_start_repaint_loop':
> >src/spice/compositor-spice.c:66:5: warning: 'start' is deprecated
> >[-Wdeprecated-declarations]
> > c->worker->start(c->worker);
> > ^
> >In file included from /usr/include/spice-server/spice.h:26:0,
> > from src/spice/compositor-spice.c:27:
> >/usr/include/spice-server/spice-qxl.h:46:12: note: declared here
> > void (*start)(QXLWorker *worker) SPICE_GNUC_DEPRECATED;
> >^
> >src/spice/compositor-spice.c: In function 'on_wakeup':
> >src/spice/compositor-spice.c:118:5: warning: 'wakeup' is deprecated
> >[-Wdeprecated-declarations]
> > c->worker->wakeup(c->worker);
> > ^
> >In file included from /usr/include/spice-server/spice.h:26:0,
> > from src/spice/compositor-spice.c:27:
> >/usr/include/spice-server/spice-qxl.h:44:12: note: declared here
> > void (*wakeup)(QXLWorker *worker) SPICE_GNUC_DEPRECATED;
> >^
> >src/spice/compositor-spice.c: In function 'spice_destroy':
> >src/spice/compositor-spice.c:262:5: warning: 'stop' is deprecated
> >[-Wdeprecated-declarations]
> > c->worker->stop (c->worker);
> > ^
> >In file included from /usr/include/spice-server/spice.h:26:0,
> > from src/spice/compositor-spice.c:27:
> >/usr/include/spice-server/spice-qxl.h:47:12: note: declared here
> > void (*stop)(QXLWorker *worker) SPICE_GNUC_DEPRECATED;
> >^

> About spice deprecated functions I did a fast search and I found spice-gtk
> api docs:
> http://www.spice-space.org/spice-gtk.html
> but not the spice-server one.
> @Spice developers: can someone tell me where I can found needed spice-server
> api documentation to make update faster and easier as possible please?

Note that these deprecated functions are not triggering errors, but are
just warnings.
These were deprecated a while ago in
https://cgit.freedesktop.org/spice/spice/commit/?id=c04d60631e91ce9f61d417fb017d94d9a1e78dc1

The replacement for
c->worker->start(c->worker);
should be spice_qxl_start(c->worker); (but this specific one was later replaced
with spice_server_vm_start())

Christophe


signature.asc
Description: PGP signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Collaboration on standard Wayland protocol extensions

[Emmanuele Bassi]

Hi;

On 28 March 2016 at 15:55, Drew DeVault  wrote:

> You're still not grasping the scope of this. I want you to run this
> command right now:
>
> man ffmpeg-all
>
> Just read it for a while. You're delusional if you think you can
> feasibly implement all of these features in the compositor. Do you
> honestly want your screen capture tool to be able to add a watermark?
> How about live streaming, some people add a sort of extra UI to read off
> donations and such. The scope of your screen capture tool is increasing
> at an alarming rate if you intend to support all of the features
> currently possible with ffmpeg. How about instead we make a simple
> wayland protocol extension that we can integrate with ffmpeg and OBS and
> imagemagick and so on in a single C file.

Wait, what?

Why do we need an extension protocol for Wayland to add stuff to screen casts?

If you want to add watermarks, use a video editor on the output file.

If you want to add additional stuff on top of a live stream, use
something with a programmable pipeline that can add effects to the
stream coming from the compositor. Why do we need negotiation, or user
interation, or exchange of metadata for this stuff?

[…]

This thread is rapidly approaching escape velocity from all the
architecture astronauting…

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Collaboration on standard Wayland protocol extensions

[Simon McVittie]

On 29/03/16 13:11, Drew DeVault wrote:
> I see what you're getting at now. We can get the pid of a wayland
> client, though, and from that we can look at /proc/cmdline, from which
> we can get the binary path.

This line of thinking is a trap: rummaging in /proc/$pid is not suitable
for use as a security mechanism. If a client can queue up a malicious
privileged action (stuff it into the socket's send-buffer), and then
race with the compositor to exec() something that would legitimately be
allowed to take that action before the request is processed, then you lose.

See  for details of
the equivalent in D-Bus. Mainline dbus on Unix was never vulnerable to
this (because we use credentials-passing to get the uid), but there used
to be an out-of-tree LSM integration patch set (for Maemo) that was.
(That bug was about documenting the attack so that we never accidentally
introduce it.)

If you want to map processes to executable-based privilege domains in a
way that cannot be faked, you will have to use their LSM labels
(SELinux, Smack or other xattr-based labelling, or AppArmor or other
path-based labelling) which are specifically designed to do this. A
Wayland equivalent of D-Bus' GetConnectionCredentials() would probably
be useful.

S
-- 
Simon McVittie
Collabora Ltd. 

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

[PATCH v2 wayland-web] Updated build instructions for wayland-protocols and libwacom

[spitzak]

From: Bill Spitzak 

The Mint instructions have been tested, I had to guess at the Ubuntu12
instructions as I no longer have that machine.

v2: Use MAKEFLAGS instead of switches
Use & instead of &
Some rewording of Ubuntu instructions to point out they are old

Signed-off-by: Bill Spitzak 
---
 building.html|  2 ++
 mint17.html  | 58 
 ubuntu12.04.html | 31 ++
 3 files changed, 58 insertions(+), 33 deletions(-)

diff --git a/building.html b/building.html
index 7bfcd8b..b5a83dc 100644
--- a/building.html
+++ b/building.html
@@ -238,6 +238,8 @@ $ cd ..
   http://www.freedesktop.org/wiki/Software/libevdev/";>libevdev,
   this is in http://cgit.freedesktop.org/libevdev";>git://anongit.freedesktop.org/libevdev
 
+https://sourceforge.net/projects/linuxwacom/";>libwacom source 
is in git://git.code.sf.net/p/linuxwacom/libwacom
+
 http://xkbcommon.org/";>libxkbcommon source is
 in http://github.com/xkbcommon/libxkbcommon";>git://github.com/xkbcommon/libxkbcommon.
 
diff --git a/mint17.html b/mint17.html
index ae1c5a8..a1f8341 100644
--- a/mint17.html
+++ b/mint17.html
@@ -12,7 +12,7 @@
 Building Weston on Linux Mint 17
 
 The following sequence of commands successfully built Weston and
-XWayland on a Linux Mint 17 Cinnamon system, on October 28 2014. These
+XWayland on a Linux Mint 17.3 Cinnamon system, on March 2, 2016. These
 commands will probably work on any system based on Ubuntu 14.04.
 
 This is considerably easier than earlier systems as the distributed
@@ -29,26 +29,42 @@ export PATH=$WLD/bin:$PATH
 export ACLOCAL_PATH=$WLD/share/aclocal
 export ACLOCAL="aclocal -I $ACLOCAL_PATH"
 mkdir -p $ACLOCAL_PATH
+export MAKEFLAGS="j9" # or use your own flags
 
 # libwayland:
 
-apt install libffi-dev libexpat-dev
+apt install libffi-dev libexpat-dev libxml2-dev
 apt install doxygen xmlto # or use 
--disable-documentation
 
 git clone git://anongit.freedesktop.org/wayland/wayland
 cd wayland
 ./autogen.sh --prefix=$WLD
-make -j 9 && make install
+make && make install
+cd ..
+
+# wayland-protocols:
+
+git clone git://anongit.freedesktop.org/wayland/wayland-protocols
+cd wayland-protocols
+./autogen.sh --prefix=$WLD
+make && make install
 cd ..
 
 # libinput:
 
 apt install libmtdev-dev libudev-dev libevdev-dev
 
+# newer version of libwacom is needed than in apt
+apt install libgudev-1.0-dev
+git clone git://git.code.sf.net/p/linuxwacom/libwacom
+cd libwacom
+make && make install
+cd ..
+
 git clone git://anongit.freedesktop.org/wayland/libinput
 cd libinput
 ./autogen.sh --prefix=$WLD
-make -j 9 && make install
+make && make install
 cd ..
 
 # weston:
@@ -60,7 +76,7 @@ apt install libegl1-mesa-dev libgles2-mesa-dev libxcursor-dev 
libcairo2-dev \
 git clone git://anongit.freedesktop.org/wayland/weston
 cd weston
 ./autogen.sh --prefix=$WLD --disable-setuid-install
-make -j 9 && make install
+make && make install
 cd ..
 
 # X Server:
@@ -71,91 +87,91 @@ apt install libgl1-mesa-dri-dev libgcrypt11-dev 
libxkbfile-dev libxfont-dev \
 git clone git://anongit.freedesktop.org/xorg/util/macros
 cd macros
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/xcmiscproto
 cd xcmiscproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/lib/libxtrans
 cd libxtrans
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/bigreqsproto
 cd bigreqsproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/xproto
 cd xproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/randrproto
 cd randrproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/fontsproto
 cd fontsproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/videoproto
 cd videoproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/compositeproto
 cd compositeproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/recordproto
 cd recordproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/scrnsaverproto
 cd scrnsaverproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/resourceproto
 cd resourceproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git 

Re: [PATCH wayland-protocols v5] text: Create second version of text input protocol

[Bill Spitzak]

On Fri, Mar 25, 2016 at 12:16 AM, Daiki Ueno  wrote:

>
> > +  
> > + Allows to atomically send state updates from client.
> > +
> > + This request should follow after a batch of state updating requests
> > + like set_surrounding_text, set_content_type, set_cursor_rectangle
> and
> > + set_preferred_language.
>
> This sentence indicates that the request is used for some sort of
> synchronization between the client and compositor.  I'm wondering if it
> could perform a roundtrip using wl_callback, instead of generating a
> serial on the client side.  Then the serial could later be obtained from
> the compositor through wl_callback.done.  Would that cause any race
> conditions?
>

It's not a synchronization, all the requests are going from client to
server. It is to batch them or make them atomic, or as the wl_surface calls
it, it is to double-buffer the requests.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 3/7] gl-renderer: Implement & use check_extension

[Bill Spitzak]

On Mon, Mar 21, 2016 at 9:37 AM, Miguel A. Vico 
wrote:

> Using strstr(3) for checking for extensions is an error-prone mechanism
> as extension names can be prefixes of other extension names (see
> https://www.opengl.org/registry/doc/rules.html#using).
>
> This change implements the check_extension() function to properly check
> for an extension and replaces all usages of strstr(3).
>
> Signed-off-by: Miguel A Vico Moya 
> Reviewed-by: Andy Ritger 
> ---
>  src/gl-renderer.c | 56
> +--
>  1 file changed, 42 insertions(+), 14 deletions(-)
>
> diff --git a/src/gl-renderer.c b/src/gl-renderer.c
> index 1d6d98c..3ca1aed 100644
> --- a/src/gl-renderer.c
> +++ b/src/gl-renderer.c
> @@ -2701,6 +2701,34 @@ gl_renderer_destroy(struct weston_compositor *ec)
> free(gr);
>  }
>
> +static
> +bool check_extension(const char *extensions, const char *extension)
> +{
> +   size_t extlen = strlen(extension);
> +   const char *end = extensions + strlen(extensions);
> +
> +   while (extensions < end) {
> +   size_t n = 0;
> +
> +   /* Skip whitespaces, if any */
> +   if (*extensions == ' ') {
> +   extensions++;
> +   continue;
> +   }
> +
> +   n = strcspn(extensions, " ");
> +
> +   /* Compare strings */
> +   if (n == extlen && strncmp(extension, extensions, n) == 0)
> +   return true; /* Found */
> +
> +   extensions += n;
> +   }
> +
> +   /* Not found */
> +   return false;
> +}
> +
>

Slightly faster version that avoids some temporaries and strlen calls:

static
bool check_extension(const char *extensions, const char *extension)
{
while (*extensions) {
size_t n = strcspn(extensions, " ");

/* Skip whitespaces, if any */
if (n < 1) {
extensions++;
continue;
}

/* Compare strings */
if (strncmp(extension, extensions, n) == 0 && !extension[n])
return true; /* Found */

extensions += n;
}

/* Not found */
return false;
}
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-web] Updated build instructions for wayland-protocols and libwacom

[Bill Spitzak]

On Tue, Mar 8, 2016 at 11:49 PM, Bryce Harrington 
wrote:

> On Wed, Mar 09, 2016 at 12:54:11PM +1000, Peter Hutterer wrote:
> > On Tue, Mar 08, 2016 at 06:39:43PM -0800, Bill Spitzak wrote:
> > > On Tue, Mar 8, 2016 at 6:12 PM, Peter Hutterer <
> peter.hutte...@who-t.net>
> > > wrote:
> > >
> > > > On Fri, Mar 04, 2016 at 10:16:30PM -0800, spit...@gmail.com wrote:
> > > > > From: Bill Spitzak 
> > > > >
> > > > > The Mint instructions have been tested, I had to guess at the
> Ubuntu12
> > > > > instructions as I no longer have that machine.
> > > >
> > > > fwiw, I do question the need for build instructions for a new
> graphics
> > > > stack
> > > > on a >3 year old release.
> > >
> > > I am unsure, but for a lot of people trying to use work machines they
> are
> > > stuck with such old versions. I know my previous job (Oblong
> Industries) is
> > > still using this version of Ubuntu. Here at Dreamworks they are even
> older
> > > RHEL6 and I cannot compile it at all.
> >
> > I don't doubt that some people are trying to compile it, but as I said, I
> > question the need to provide build instructions (which look official when
> > they're on the wayland website). especially if they're untested.
>
> Personally I don't see a problem with it, it's just keeping already
> published documentation updated as stuff changes.
>

I think it should be kept as it contains the hair needed to get Mesa to
compile, which was by far the biggest sticking point in getting Wayland
working. That problem may come up again if Wayland is changed to depend on
a bleeding-edge Mesa dependency.


> That said, I agree with 12.04 we're probably pretty deep into the long
> tail for users.  Especially with 16.04 coming out next month I wouldn't
> see a problem just dropping the 12.04 directions at this point.
>
> Bryce
>
> > > > ---
> > > > >  mint17.html  | 21 ++---
> > > > >  ubuntu12.04.html | 13 +++--
> > > > >  2 files changed, 29 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/mint17.html b/mint17.html
> > > > > index ae1c5a8..f32ef9e 100644
> > > > > --- a/mint17.html
> > > > > +++ b/mint17.html
> > > > > @@ -12,7 +12,7 @@
> > > > >  Building Weston on Linux Mint 17
> > > > >
> > > > >  The following sequence of commands successfully built Weston
> and
> > > > > -XWayland on a Linux Mint 17 Cinnamon system, on October 28 2014.
> These
> > > > > +XWayland on a Linux Mint 17.3 Cinnamon system, on March 2, 2016.
> These
> > > > >  commands will probably work on any system based on Ubuntu
> 14.04.
> > > > >
> > > > >  This is considerably easier than earlier systems as the
> distributed
> > > > > @@ -32,7 +32,7 @@ mkdir -p $ACLOCAL_PATH
> > > > >
> > > > >  # libwayland:
> > > > >
> > > > > -apt install libffi-dev libexpat-dev
> > > > > +apt install libffi-dev libexpat-dev libxml2-dev
> > > > >  apt install doxygen xmlto # or use
> > > > --disable-documentation
> > > > >
> > > > >  git clone git://anongit.freedesktop.org/wayland/wayland
> > > > > @@ -41,10 +41,25 @@ cd wayland
> > > > >  make -j 9 && make install
> > > > >  cd ..
> > > > >
> > > > > +# wayland-protocols:
> > > > > +
> > > > > +git clone git://anongit.freedesktop.org/wayland/wayland-protocols
> > > > > +cd wayland-protocols
> > > > > +./autogen.sh --prefix=$WLD
> > > > > +make -j 9 && make install
> > > > > +cd ..
> > > > > +
> > > > >  # libinput:
> > > > >
> > > > >  apt install libmtdev-dev libudev-dev libevdev-dev
> > > > >
> > > > > +# newer version of libwacom is needed than
> in apt
> > > > > +apt install libgudev-1.0-dev
> > > > > +git clone git://git.code.sf.net/p/linuxwacom/libwacom
> > > > > +cd libwacom
> > > > > +make -j 9 && make install
> > > > > +cd ..
> > > > > +
> > > > >  git clone git://anongit.freedesktop.org/wayland/libinput
> > > > >  cd libinput
> > > > >  ./autogen.sh --prefix=$WLD
> > > > > @@ -163,7 +178,7 @@ cd xserver
> > > > >  ./autogen.sh --prefix=$WLD --disable-docs --disable-devel-docs \
> > > > >--enable-xwayland --disable-xorg --disable-xvfb --disable-xnest
> \
> > > > >--disable-xquartz --disable-xwin
> > > > > -make && make install
> > > > > +make -j 9 && make install
> > > >
> > > > what's the reason we hardcode -j9 everywhere instead of relying on
> users to
> > > > set their MAKEFLAGS?
> > > >
> > >
> > > It might work now for Mint. I don't think Mesa compiled correctly with
> > > parallel make so I had to leave it out of that one.
> >
> > I'd say override it there with a forced -j1 and file a bug upstream.
> >
> > > Would you think it best to insert the setenv in the Mint instructions?
> >
> > No, you don't insert a setenv, you can point out that people should have
> > that set, but don't override their local settings. They may have other
> > makeflags that matter.
>

Actually it was Wayland that had a problem with parallel make, the
documentation failed, but I fixed that some time ago.

I believe Mesa's problem was that you sometimes had to do a "git clean" in
order to get a cor

Re: [PATCH 1/2] clients & tests: Unify multiple definitions of x*alloc and related functions

[Bill Spitzak]

On Tue, Mar 15, 2016 at 3:23 PM, Bryce Harrington 
wrote:

>
> --- a/clients/ivi-shell-user-interface.c
> +++ b/clients/ivi-shell-user-interface.c
> @@ -40,6 +40,7 @@
>  #include "shared/config-parser.h"
>  #include "shared/helpers.h"
>  #include "shared/os-compatibility.h"
> +#include "shared/xalloc.h"
>  #include "shared/zalloc.h"
>  #include "ivi-application-client-protocol.h"
>  #include "ivi-hmi-controller-client-protocol.h"
> @@ -164,18 +165,6 @@ hmi_homescreen_setting {
>  };
>
>  static void *
> -fail_on_null(void *p, size_t size, char *file, int32_t line)
> -{
> -   if (size && !p) {
> -   fprintf(stderr, "%s(%d) %zd: out of memory\n",
> -   file, line, size);
> -   exit(EXIT_FAILURE);
> -   }
> -
> -   return p;
> -}
>

The deleted ones in ivi purposely does not fail if size==0. But it appears
they are only called by the MEM_ALLOC macro and that is only called with
sizeof() which is not going to be zero, so this is ok.

>
> -   fail_on_null(window->xdg_surface);
> +   fail_on_null(window->xdg_surface, 1, __FILE__, __LINE__);
>

I think you either want to use sizeof(*window->xdg_surface) or 0 for the
size.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-web] Updated build instructions for wayland-protocols and libwacom

[Bill Spitzak]

>
>
>> > > > > +# newer version of libwacom is needed than
>> in apt
>> > > > > +apt install libgudev-1.0-dev
>> > > > > +git clone git://git.code.sf.net/p/linuxwacom/libwacom
>> > > > > +cd libwacom
>> > > > > +make -j 9 && make install
>> > > > > +cd ..
>>
>
Is the git repository for libwacom correct here, or did I find some mirror?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 wayland-web] Updated build instructions for wayland-protocols and libwacom

[spitzak]

From: Bill Spitzak 

The Mint instructions have been tested, I had to guess at the Ubuntu12
instructions as I no longer have that machine.

v2: Use MAKEFLAGS instead of switches
Use & instead of &
Some rewording of Ubuntu instructions to point out they are old

Signed-off-by: Bill Spitzak 
---
 building.html|  2 ++
 mint17.html  | 58 
 ubuntu12.04.html | 31 ++
 3 files changed, 58 insertions(+), 33 deletions(-)

diff --git a/building.html b/building.html
index 7bfcd8b..b5a83dc 100644
--- a/building.html
+++ b/building.html
@@ -238,6 +238,8 @@ $ cd ..
   http://www.freedesktop.org/wiki/Software/libevdev/";>libevdev,
   this is in http://cgit.freedesktop.org/libevdev";>git://anongit.freedesktop.org/libevdev
 
+https://sourceforge.net/projects/linuxwacom/";>libwacom source 
is in git://git.code.sf.net/p/linuxwacom/libwacom
+
 http://xkbcommon.org/";>libxkbcommon source is
 in http://github.com/xkbcommon/libxkbcommon";>git://github.com/xkbcommon/libxkbcommon.
 
diff --git a/mint17.html b/mint17.html
index ae1c5a8..a1f8341 100644
--- a/mint17.html
+++ b/mint17.html
@@ -12,7 +12,7 @@
 Building Weston on Linux Mint 17
 
 The following sequence of commands successfully built Weston and
-XWayland on a Linux Mint 17 Cinnamon system, on October 28 2014. These
+XWayland on a Linux Mint 17.3 Cinnamon system, on March 2, 2016. These
 commands will probably work on any system based on Ubuntu 14.04.
 
 This is considerably easier than earlier systems as the distributed
@@ -29,26 +29,42 @@ export PATH=$WLD/bin:$PATH
 export ACLOCAL_PATH=$WLD/share/aclocal
 export ACLOCAL="aclocal -I $ACLOCAL_PATH"
 mkdir -p $ACLOCAL_PATH
+export MAKEFLAGS="j9" # or use your own flags
 
 # libwayland:
 
-apt install libffi-dev libexpat-dev
+apt install libffi-dev libexpat-dev libxml2-dev
 apt install doxygen xmlto # or use 
--disable-documentation
 
 git clone git://anongit.freedesktop.org/wayland/wayland
 cd wayland
 ./autogen.sh --prefix=$WLD
-make -j 9 && make install
+make && make install
+cd ..
+
+# wayland-protocols:
+
+git clone git://anongit.freedesktop.org/wayland/wayland-protocols
+cd wayland-protocols
+./autogen.sh --prefix=$WLD
+make && make install
 cd ..
 
 # libinput:
 
 apt install libmtdev-dev libudev-dev libevdev-dev
 
+# newer version of libwacom is needed than in apt
+apt install libgudev-1.0-dev
+git clone git://git.code.sf.net/p/linuxwacom/libwacom
+cd libwacom
+make && make install
+cd ..
+
 git clone git://anongit.freedesktop.org/wayland/libinput
 cd libinput
 ./autogen.sh --prefix=$WLD
-make -j 9 && make install
+make && make install
 cd ..
 
 # weston:
@@ -60,7 +76,7 @@ apt install libegl1-mesa-dev libgles2-mesa-dev libxcursor-dev 
libcairo2-dev \
 git clone git://anongit.freedesktop.org/wayland/weston
 cd weston
 ./autogen.sh --prefix=$WLD --disable-setuid-install
-make -j 9 && make install
+make && make install
 cd ..
 
 # X Server:
@@ -71,91 +87,91 @@ apt install libgl1-mesa-dri-dev libgcrypt11-dev 
libxkbfile-dev libxfont-dev \
 git clone git://anongit.freedesktop.org/xorg/util/macros
 cd macros
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/xcmiscproto
 cd xcmiscproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/lib/libxtrans
 cd libxtrans
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/bigreqsproto
 cd bigreqsproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/xproto
 cd xproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/randrproto
 cd randrproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/fontsproto
 cd fontsproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/videoproto
 cd videoproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/compositeproto
 cd compositeproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/recordproto
 cd recordproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/scrnsaverproto
 cd scrnsaverproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git clone git://anongit.freedesktop.org/xorg/proto/resourceproto
 cd resourceproto
 ./autogen.sh --prefix=$WLD
-make && make install
+make && make install
 cd ..
 
 git 

[PATCH weston 16/16] ivi-shell: remove content_observer leftover

[Ucan, Emre (ADITG/SW1)]

content_observer_notification is removed by the commit:
193e301c740b582f20307e3e08f8373d26ea968f.

Therefore, this callback function is unused.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h |5 -
 1 file changed, 5 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 2ccdff5..afe5001 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -138,11 +138,6 @@ enum ivi_layout_transition_type{
IVI_LAYOUT_TRANSITION_MAX,
 };
 
-typedef void (*ivi_controller_surface_content_callback)(
-   struct ivi_layout_surface *ivisurf,
-   int32_t content,
-   void *userdata);
-
 struct ivi_layout_interface {
 
/**
-- 
1.7.9.5

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

[PATCH weston 14/16] ivi-shell: rework configure_surface notification

[Ucan, Emre (ADITG/SW1)]

The add_notification_configure_surface API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to 
add_listener_configure_surface.

This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
   by controller plugins
3. Remove API is not needed. Controller plugins can easily
   remove the listener link.

Signed-off-by: Emre Ucan 
---
 ivi-shell/hmi-controller.c   |   14 ++---
 ivi-shell/ivi-layout-export.h|4 +--
 ivi-shell/ivi-layout.c   |   62 --
 tests/ivi_layout-internal-test.c |2 +-
 tests/ivi_layout-test-plugin.c   |   17 ++-
 5 files changed, 27 insertions(+), 72 deletions(-)

diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index 49aba81..53ba947 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -129,6 +129,7 @@ struct hmi_controller {
 
struct wl_listener  surface_created;
struct wl_listener  surface_removed;
+   struct wl_listener  surface_configured;
 
struct wl_client   *user_interface;
struct ui_setting   ui_setting;
@@ -612,10 +613,12 @@ set_notification_remove_surface(struct wl_listener 
*listener, void *data)
 }
 
 static void
-set_notification_configure_surface(struct ivi_layout_surface *ivisurf,
-  void *userdata)
+set_notification_configure_surface(struct wl_listener *listener, void *data)
 {
-   struct hmi_controller *hmi_ctrl = userdata;
+   struct hmi_controller *hmi_ctrl =
+   wl_container_of(listener, hmi_ctrl,
+   surface_configured);
+   struct ivi_layout_surface *ivisurf = (struct ivi_layout_surface*) data;
struct hmi_controller_layer *layer_link = NULL;
struct ivi_layout_layer *application_layer = NULL;
struct weston_surface *surface;
@@ -846,8 +849,9 @@ hmi_controller_create(struct weston_compositor *ec)
 
hmi_ctrl->surface_removed.notify = set_notification_remove_surface;

ivi_layout_interface->add_listener_remove_surface(&hmi_ctrl->surface_removed);
-   ivi_layout_interface->add_notification_configure_surface(
-   set_notification_configure_surface, hmi_ctrl);
+
+   hmi_ctrl->surface_configured.notify = 
set_notification_configure_surface;
+   
ivi_layout_interface->add_listener_configure_surface(&hmi_ctrl->surface_configured);
 
hmi_ctrl->destroy_listener.notify = hmi_controller_destroy;
wl_signal_add(&hmi_ctrl->compositor->destroy_signal,
diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index e0beff6..8ff5613 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -175,9 +175,7 @@ struct ivi_layout_interface {
/**
 * \brief register/unregister for notification when ivi_surface is 
configured
 */
-   int32_t (*add_notification_configure_surface)(
-   surface_configure_notification_func callback,
-   void *userdata);
+   int32_t (*add_listener_configure_surface)(struct wl_listener *listener);
 
void (*remove_notification_configure_surface)(
surface_configure_notification_func callback,
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index aa35327..5776279 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -931,46 +931,6 @@ clear_surface_order_list(struct ivi_layout_layer *ivilayer)
 }
 
 static void
-surface_configure_changed(struct wl_listener *listener,
- void *data)
-{
-   struct ivi_layout_surface *ivisurface = data;
-
-   struct listener_layout_notification *notification =
-   container_of(listener,
-struct listener_layout_notification,
-listener);
-
-   struct ivi_layout_notification_callback *configure_changed_callback =
-   notification->userdata;
-
-   
((surface_configure_notification_func)configure_changed_callback->callback)
-   (ivisurface, configure_changed_callback->data);
-}
-
-static int32_t
-add_notification(struct wl_signal *signal,
-wl_notify_func_t callback,
-void *userdata)
-{
-   struct listener_layout_notification *notification = NULL;
-
-   notification = malloc(sizeof *notification);
-   if (notification == NULL) {
-   weston_log("fails to allocate memory\n");
-   free(userdata);
-   return IVI_FAILED;
-   }
-
-   notification->listener.notify = callback;
-   notification->userdata = userdata;
-
-   wl_signal_add(signal, ¬ification->listener);
-
-   return IVI_SUCCEEDED;
-}
-
-static void
 remove_notifi

[PATCH weston 15/16] ivi-shell: remove remove_notification_configure_surface

[Ucan, Emre (ADITG/SW1)]

ivi_layout_remove_notification_configure_surface API is
removed, because it is not needed after the changes to
the ivi_layout_add_notification_configure_surface.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h |8 ---
 ivi-shell/ivi-layout.c|   49 -
 2 files changed, 57 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 8ff5613..2ccdff5 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -138,10 +138,6 @@ enum ivi_layout_transition_type{
IVI_LAYOUT_TRANSITION_MAX,
 };
 
-typedef void (*surface_configure_notification_func)(
-   struct ivi_layout_surface *ivisurf,
-   void *userdata);
-
 typedef void (*ivi_controller_surface_content_callback)(
struct ivi_layout_surface *ivisurf,
int32_t content,
@@ -177,10 +173,6 @@ struct ivi_layout_interface {
 */
int32_t (*add_listener_configure_surface)(struct wl_listener *listener);
 
-   void (*remove_notification_configure_surface)(
-   surface_configure_notification_func callback,
-   void *userdata);
-
/**
 * \brief Get all ivi_surfaces which are currently registered and 
managed
 * by the services
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 5776279..0faf1a6 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -71,11 +71,6 @@
 
 #define max(a, b) ((a) > (b) ? (a) : (b))
 
-struct listener_layout_notification {
-   void *userdata;
-   struct wl_listener listener;
-};
-
 struct ivi_layout;
 
 struct ivi_layout_screen {
@@ -96,11 +91,6 @@ struct ivi_layout_screen {
} order;
 };
 
-struct ivi_layout_notification_callback {
-   void *callback;
-   void *data;
-};
-
 struct ivi_rectangle
 {
int32_t x;
@@ -109,9 +99,6 @@ struct ivi_rectangle
int32_t height;
 };
 
-static void
-remove_notification(struct wl_list *listener_list, void *callback, void 
*userdata);
-
 static struct ivi_layout ivilayout = {0};
 
 struct ivi_layout *
@@ -930,33 +917,6 @@ clear_surface_order_list(struct ivi_layout_layer *ivilayer)
}
 }
 
-static void
-remove_notification(struct wl_list *listener_list, void *callback, void 
*userdata)
-{
-   struct wl_listener *listener = NULL;
-   struct wl_listener *next = NULL;
-
-   wl_list_for_each_safe(listener, next, listener_list, link) {
-   struct listener_layout_notification *notification =
-   container_of(listener,
-struct listener_layout_notification,
-listener);
-
-   struct ivi_layout_notification_callback *notification_callback =
-   notification->userdata;
-
-   if ((notification_callback->callback != callback) ||
-   (notification_callback->data != userdata)) {
-   continue;
-   }
-
-   wl_list_remove(&listener->link);
-
-   free(notification->userdata);
-   free(notification);
-   }
-}
-
 /**
  * Exported APIs of ivi-layout library are implemented from here.
  * Brief of APIs is described in ivi-layout-export.h.
@@ -1036,14 +996,6 @@ ivi_layout_add_listener_configure_surface(struct 
wl_listener *listener)
return IVI_SUCCEEDED;
 }
 
-static void
-ivi_layout_remove_notification_configure_surface(surface_configure_notification_func
 callback,
-void *userdata)
-{
-   struct ivi_layout *layout = get_instance();
-   
remove_notification(&layout->surface_notification.configure_changed.listener_list,
 callback, userdata);
-}
-
 uint32_t
 ivi_layout_get_id_of_surface(struct ivi_layout_surface *ivisurf)
 {
@@ -2039,7 +1991,6 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
.add_listener_create_surface= 
ivi_layout_add_listener_create_surface,
.add_listener_remove_surface= 
ivi_layout_add_listener_remove_surface,
.add_listener_configure_surface = 
ivi_layout_add_listener_configure_surface,
-   .remove_notification_configure_surface  = 
ivi_layout_remove_notification_configure_surface,
.get_surfaces   = ivi_layout_get_surfaces,
.get_id_of_surface  = ivi_layout_get_id_of_surface,
.get_surface_from_id= 
ivi_layout_get_surface_from_id,
-- 
1.7.9.5

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

[PATCH weston 13/16] ivi-shell: remove remove_notification_remove_surface

[Ucan, Emre (ADITG/SW1)]

ivi_layout_remove_notification_remove_surface API is
removed, because it is not needed after the changes to
the ivi_layout_add_notification_remove_surface.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h |8 
 ivi-shell/ivi-layout.c|9 -
 2 files changed, 17 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 0aaf5b3..e0beff6 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -138,10 +138,6 @@ enum ivi_layout_transition_type{
IVI_LAYOUT_TRANSITION_MAX,
 };
 
-typedef void (*surface_remove_notification_func)(
-   struct ivi_layout_surface *ivisurf,
-   void *userdata);
-
 typedef void (*surface_configure_notification_func)(
struct ivi_layout_surface *ivisurf,
void *userdata);
@@ -176,10 +172,6 @@ struct ivi_layout_interface {
 */
int32_t (*add_listener_remove_surface)(struct wl_listener *listener);
 
-   void (*remove_notification_remove_surface)(
-   surface_remove_notification_func callback,
-   void *userdata);
-
/**
 * \brief register/unregister for notification when ivi_surface is 
configured
 */
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 63983c5..aa35327 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -1061,14 +1061,6 @@ ivi_layout_add_listener_remove_surface(struct 
wl_listener *listener)
return IVI_SUCCEEDED;
 }
 
-static void
-ivi_layout_remove_notification_remove_surface(surface_remove_notification_func 
callback,
- void *userdata)
-{
-   struct ivi_layout *layout = get_instance();
-   
remove_notification(&layout->surface_notification.removed.listener_list, 
callback, userdata);
-}
-
 static int32_t
 
ivi_layout_add_notification_configure_surface(surface_configure_notification_func
 callback,
  void *userdata)
@@ -2096,7 +2088,6 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
 */
.add_listener_create_surface= 
ivi_layout_add_listener_create_surface,
.add_listener_remove_surface= 
ivi_layout_add_listener_remove_surface,
-   .remove_notification_remove_surface = 
ivi_layout_remove_notification_remove_surface,
.add_notification_configure_surface = 
ivi_layout_add_notification_configure_surface,
.remove_notification_configure_surface  = 
ivi_layout_remove_notification_configure_surface,
.get_surfaces   = ivi_layout_get_surfaces,
-- 
1.7.9.5

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

[PATCH weston 09/16] ivi-shell: remove remove_notification_create_layer

[Ucan, Emre (ADITG/SW1)]

ivi_layout_remove_notification_create_layer API is
removed, because it is not needed after the changes to
the ivi_layout_add_notification_create_layer.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h |8 
 ivi-shell/ivi-layout.c|9 -
 2 files changed, 17 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index b2c3d2e..5b31733 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -138,10 +138,6 @@ enum ivi_layout_transition_type{
IVI_LAYOUT_TRANSITION_MAX,
 };
 
-typedef void (*layer_create_notification_func)(
-   struct ivi_layout_layer *ivilayer,
-   void *userdata);
-
 typedef void (*layer_remove_notification_func)(
struct ivi_layout_layer *ivilayer,
void *userdata);
@@ -338,10 +334,6 @@ struct ivi_layout_interface {
 */
int32_t (*add_listener_create_layer)(struct wl_listener *listener);
 
-   void (*remove_notification_create_layer)(
-   layer_create_notification_func callback,
-   void *userdata);
-
/**
 * \brief register/unregister for notification when ivi_layer is removed
 */
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index ac96083..0913f43 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -1050,14 +1050,6 @@ ivi_layout_add_listener_create_layer(struct wl_listener 
*listener)
return IVI_SUCCEEDED;
 }
 
-static void
-ivi_layout_remove_notification_create_layer(layer_create_notification_func 
callback,
-   void *userdata)
-{
-   struct ivi_layout *layout = get_instance();
-   remove_notification(&layout->layer_notification.created.listener_list, 
callback, userdata);
-}
-
 static int32_t
 ivi_layout_add_notification_remove_layer(layer_remove_notification_func 
callback,
 void *userdata)
@@ -2189,7 +2181,6 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
 * layer controller interfaces
 */
.add_listener_create_layer  = 
ivi_layout_add_listener_create_layer,
-   .remove_notification_create_layer   = 
ivi_layout_remove_notification_create_layer,
.add_notification_remove_layer  = 
ivi_layout_add_notification_remove_layer,
.remove_notification_remove_layer   = 
ivi_layout_remove_notification_remove_layer,
.layer_create_with_dimension= 
ivi_layout_layer_create_with_dimension,
-- 
1.7.9.5

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

[PATCH weston 12/16] ivi-shell: rework remove_surface notification

[Ucan, Emre (ADITG/SW1)]

The add_notification_remove_surface API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to add_listener_remove_surface.

This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
   by controller plugins
3. Remove API is not needed. Controller plugins can easily
   remove the listener link.

Signed-off-by: Emre Ucan 
---
 ivi-shell/hmi-controller.c   |   14 -
 ivi-shell/ivi-layout-export.h|4 +---
 ivi-shell/ivi-layout.c   |   40 ++
 tests/ivi_layout-internal-test.c |2 +-
 tests/ivi_layout-test-plugin.c   |   19 ++
 5 files changed, 28 insertions(+), 51 deletions(-)

diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index bd38717..49aba81 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -128,6 +128,7 @@ struct hmi_controller {
struct wl_listener  destroy_listener;
 
struct wl_listener  surface_created;
+   struct wl_listener  surface_removed;
 
struct wl_client   *user_interface;
struct ui_setting   ui_setting;
@@ -600,10 +601,12 @@ set_notification_create_surface(struct wl_listener 
*listener, void *data)
 }
 
 static void
-set_notification_remove_surface(struct ivi_layout_surface *ivisurf,
-   void *userdata)
+set_notification_remove_surface(struct wl_listener *listener, void *data)
 {
-   struct hmi_controller *hmi_ctrl = userdata;
+   struct hmi_controller *hmi_ctrl =
+   wl_container_of(listener, hmi_ctrl,
+   surface_removed);
+   (void)data;
 
switch_mode(hmi_ctrl, hmi_ctrl->layout_mode);
 }
@@ -840,8 +843,9 @@ hmi_controller_create(struct weston_compositor *ec)
 
hmi_ctrl->surface_created.notify = set_notification_create_surface;

ivi_layout_interface->add_listener_create_surface(&hmi_ctrl->surface_created);
-   ivi_layout_interface->add_notification_remove_surface(
-   set_notification_remove_surface, hmi_ctrl);
+
+   hmi_ctrl->surface_removed.notify = set_notification_remove_surface;
+   
ivi_layout_interface->add_listener_remove_surface(&hmi_ctrl->surface_removed);
ivi_layout_interface->add_notification_configure_surface(
set_notification_configure_surface, hmi_ctrl);
 
diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 391df55..0aaf5b3 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -174,9 +174,7 @@ struct ivi_layout_interface {
/**
 * \brief register/unregister for notification when ivi_surface is 
removed
 */
-   int32_t (*add_notification_remove_surface)(
-   surface_remove_notification_func callback,
-   void *userdata);
+   int32_t (*add_listener_remove_surface)(struct wl_listener *listener);
 
void (*remove_notification_remove_surface)(
surface_remove_notification_func callback,
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index e7d6583..63983c5 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -931,23 +931,6 @@ clear_surface_order_list(struct ivi_layout_layer *ivilayer)
 }
 
 static void
-surface_removed(struct wl_listener *listener, void *data)
-{
-   struct ivi_layout_surface *ivisurface = data;
-
-   struct listener_layout_notification *notification =
-   container_of(listener,
-struct listener_layout_notification,
-listener);
-
-   struct ivi_layout_notification_callback *removed_callback =
-   notification->userdata;
-
-   ((surface_remove_notification_func)removed_callback->callback)
-   (ivisurface, removed_callback->data);
-}
-
-static void
 surface_configure_changed(struct wl_listener *listener,
  void *data)
 {
@@ -1064,29 +1047,18 @@ ivi_layout_add_listener_create_surface(struct 
wl_listener *listener)
 }
 
 static int32_t
-ivi_layout_add_notification_remove_surface(surface_remove_notification_func 
callback,
-  void *userdata)
+ivi_layout_add_listener_remove_surface(struct wl_listener *listener)
 {
struct ivi_layout *layout = get_instance();
-   struct ivi_layout_notification_callback *removed_callback = NULL;
-
-   if (callback == NULL) {
-   weston_log("ivi_layout_add_notification_remove_surface: invalid 
argument\n");
-   return IVI_FAILED;
-   }
 
-   removed_callback = malloc(sizeof *removed_callback);
-   if (removed_callback == NULL) {
-   weston_log("fails to allocate memory\n");
+   if 

[PATCH weston 11/16] ivi-shell: remove remove_notification_remove_layer

[Ucan, Emre (ADITG/SW1)]

ivi_layout_remove_notification_remove_layer API is
removed, because it is not needed after the changes to
the ivi_layout_add_notification_remove_layer.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h |8 
 ivi-shell/ivi-layout.c|9 -
 2 files changed, 17 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index b7837c6..391df55 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -138,10 +138,6 @@ enum ivi_layout_transition_type{
IVI_LAYOUT_TRANSITION_MAX,
 };
 
-typedef void (*layer_remove_notification_func)(
-   struct ivi_layout_layer *ivilayer,
-   void *userdata);
-
 typedef void (*surface_remove_notification_func)(
struct ivi_layout_surface *ivisurf,
void *userdata);
@@ -339,10 +335,6 @@ struct ivi_layout_interface {
 */
int32_t (*add_listener_remove_layer)(struct wl_listener *listener);
 
-   void (*remove_notification_remove_layer)(
-   layer_remove_notification_func callback,
-   void *userdata);
-
/**
 * \brief Create a ivi_layer which should be managed by the service
 *
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 66f5b02..e7d6583 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -1048,14 +1048,6 @@ ivi_layout_add_listener_remove_layer(struct wl_listener 
*listener)
return IVI_SUCCEEDED;
 }
 
-static void
-ivi_layout_remove_notification_remove_layer(layer_remove_notification_func 
callback,
-   void *userdata)
-{
-   struct ivi_layout *layout = get_instance();
-   remove_notification(&layout->layer_notification.removed.listener_list, 
callback, userdata);
-}
-
 static int32_t
 ivi_layout_add_listener_create_surface(struct wl_listener *listener)
 {
@@ -2155,7 +2147,6 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
 */
.add_listener_create_layer  = 
ivi_layout_add_listener_create_layer,
.add_listener_remove_layer  = 
ivi_layout_add_listener_remove_layer,
-   .remove_notification_remove_layer   = 
ivi_layout_remove_notification_remove_layer,
.layer_create_with_dimension= 
ivi_layout_layer_create_with_dimension,
.layer_destroy  = ivi_layout_layer_destroy,
.get_layers = ivi_layout_get_layers,
-- 
1.7.9.5

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

[PATCH weston 10/16] ivi-shell: rework remove_layer notification

[Ucan, Emre (ADITG/SW1)]

The add_notification_remove_layer API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to add_listener_remove_layer.

This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
   by controller plugins
3. Remove API is not needed. Controller plugins can easily
   remove the listener link.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h|4 +---
 ivi-shell/ivi-layout.c   |   39 ++
 tests/ivi_layout-internal-test.c |   19 ---
 3 files changed, 19 insertions(+), 43 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 5b31733..b7837c6 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -337,9 +337,7 @@ struct ivi_layout_interface {
/**
 * \brief register/unregister for notification when ivi_layer is removed
 */
-   int32_t (*add_notification_remove_layer)(
-   layer_remove_notification_func callback,
-   void *userdata);
+   int32_t (*add_listener_remove_layer)(struct wl_listener *listener);
 
void (*remove_notification_remove_layer)(
layer_remove_notification_func callback,
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 0913f43..66f5b02 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -931,23 +931,6 @@ clear_surface_order_list(struct ivi_layout_layer *ivilayer)
 }
 
 static void
-layer_removed(struct wl_listener *listener, void *data)
-{
-   struct ivi_layout_layer *ivilayer = data;
-
-   struct listener_layout_notification *notification =
-   container_of(listener,
-struct listener_layout_notification,
-listener);
-
-   struct ivi_layout_notification_callback *removed_callback =
-   notification->userdata;
-
-   ((layer_remove_notification_func)removed_callback->callback)
-   (ivilayer, removed_callback->data);
-}
-
-static void
 surface_removed(struct wl_listener *listener, void *data)
 {
struct ivi_layout_surface *ivisurface = data;
@@ -1051,28 +1034,18 @@ ivi_layout_add_listener_create_layer(struct wl_listener 
*listener)
 }
 
 static int32_t
-ivi_layout_add_notification_remove_layer(layer_remove_notification_func 
callback,
-void *userdata)
+ivi_layout_add_listener_remove_layer(struct wl_listener *listener)
 {
struct ivi_layout *layout = get_instance();
-   struct ivi_layout_notification_callback *removed_callback = NULL;
 
-   if (callback == NULL) {
-   weston_log("ivi_layout_add_notification_remove_layer: invalid 
argument\n");
+   if (listener == NULL) {
+   weston_log("ivi_layout_add_listener_remove_layer: invalid 
argument\n");
return IVI_FAILED;
}
 
-   removed_callback = malloc(sizeof *removed_callback);
-   if (removed_callback == NULL) {
-   weston_log("fails to allocate memory\n");
-   return IVI_FAILED;
-   }
+   wl_signal_add(&layout->layer_notification.removed, listener);
 
-   removed_callback->callback = callback;
-   removed_callback->data = userdata;
-   return add_notification(&layout->layer_notification.removed,
-   layer_removed,
-   removed_callback);
+   return IVI_SUCCEEDED;
 }
 
 static void
@@ -2181,7 +2154,7 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
 * layer controller interfaces
 */
.add_listener_create_layer  = 
ivi_layout_add_listener_create_layer,
-   .add_notification_remove_layer  = 
ivi_layout_add_notification_remove_layer,
+   .add_listener_remove_layer  = 
ivi_layout_add_listener_remove_layer,
.remove_notification_remove_layer   = 
ivi_layout_remove_notification_remove_layer,
.layer_create_with_dimension= 
ivi_layout_layer_create_with_dimension,
.layer_destroy  = ivi_layout_layer_destroy,
diff --git a/tests/ivi_layout-internal-test.c b/tests/ivi_layout-internal-test.c
index 500aa99..49a682a 100644
--- a/tests/ivi_layout-internal-test.c
+++ b/tests/ivi_layout-internal-test.c
@@ -44,6 +44,7 @@ struct test_context {
 
struct wl_listener layer_property_changed;
struct wl_listener layer_created;
+   struct wl_listener layer_removed;
 };
 
 static void
@@ -767,11 +768,13 @@ test_layer_create_notification(struct test_context *ctx)
 }
 
 static void
-test_layer_remove_notification_callback(struct ivi_layout_layer *ivilayer,
-   void *userdata)
+test_layer_remove_notification_callback(struct wl_listener *listener

[PATCH weston 08/16] ivi-shell: rework create_layer_notification

[Ucan, Emre (ADITG/SW1)]

The add_notification_create_layer API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to add_listener_create_layer.

This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
   by controller plugins
3. Remove API is not needed. Controller plugins can easily
   remove the listener link.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h|4 +---
 ivi-shell/ivi-layout.c   |   40 ++
 tests/ivi_layout-internal-test.c |   18 ++---
 3 files changed, 18 insertions(+), 44 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index b03fd43..b2c3d2e 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -336,9 +336,7 @@ struct ivi_layout_interface {
/**
 * \brief register/unregister for notification when ivi_layer is created
 */
-   int32_t (*add_notification_create_layer)(
-   layer_create_notification_func callback,
-   void *userdata);
+   int32_t (*add_listener_create_layer)(struct wl_listener *listener);
 
void (*remove_notification_create_layer)(
layer_create_notification_func callback,
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 4b4114f..ac96083 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -931,23 +931,6 @@ clear_surface_order_list(struct ivi_layout_layer *ivilayer)
 }
 
 static void
-layer_created(struct wl_listener *listener, void *data)
-{
-   struct ivi_layout_layer *ivilayer = data;
-
-   struct listener_layout_notification *notification =
-   container_of(listener,
-struct listener_layout_notification,
-listener);
-
-   struct ivi_layout_notification_callback *created_callback =
-   notification->userdata;
-
-   ((layer_create_notification_func)created_callback->callback)
-   (ivilayer, created_callback->data);
-}
-
-static void
 layer_removed(struct wl_listener *listener, void *data)
 {
struct ivi_layout_layer *ivilayer = data;
@@ -1053,29 +1036,18 @@ remove_notification(struct wl_list *listener_list, void 
*callback, void *userdat
  * Brief of APIs is described in ivi-layout-export.h.
  */
 static int32_t
-ivi_layout_add_notification_create_layer(layer_create_notification_func 
callback,
-void *userdata)
+ivi_layout_add_listener_create_layer(struct wl_listener *listener)
 {
struct ivi_layout *layout = get_instance();
-   struct ivi_layout_notification_callback *created_callback = NULL;
-
-   if (callback == NULL) {
-   weston_log("ivi_layout_add_notification_create_layer: invalid 
argument\n");
-   return IVI_FAILED;
-   }
 
-   created_callback = malloc(sizeof *created_callback);
-   if (created_callback == NULL) {
-   weston_log("fails to allocate memory\n");
+   if (listener == NULL) {
+   weston_log("ivi_layout_add_listener_create_layer: invalid 
argument\n");
return IVI_FAILED;
}
 
-   created_callback->callback = callback;
-   created_callback->data = userdata;
+   wl_signal_add(&layout->layer_notification.created, listener);
 
-   return add_notification(&layout->layer_notification.created,
-   layer_created,
-   created_callback);
+   return IVI_SUCCEEDED;
 }
 
 static void
@@ -2216,7 +2188,7 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
/**
 * layer controller interfaces
 */
-   .add_notification_create_layer  = 
ivi_layout_add_notification_create_layer,
+   .add_listener_create_layer  = 
ivi_layout_add_listener_create_layer,
.remove_notification_create_layer   = 
ivi_layout_remove_notification_create_layer,
.add_notification_remove_layer  = 
ivi_layout_add_notification_remove_layer,
.remove_notification_remove_layer   = 
ivi_layout_remove_notification_remove_layer,
diff --git a/tests/ivi_layout-internal-test.c b/tests/ivi_layout-internal-test.c
index f95c9e3..500aa99 100644
--- a/tests/ivi_layout-internal-test.c
+++ b/tests/ivi_layout-internal-test.c
@@ -43,6 +43,7 @@ struct test_context {
uint32_t user_flags;
 
struct wl_listener layer_property_changed;
+   struct wl_listener layer_created;
 };
 
 static void
@@ -718,11 +719,13 @@ test_layer_properties_changed_notification(struct 
test_context *ctx)
 }
 
 static void
-test_layer_create_notification_callback(struct ivi_layout_layer *ivilayer,
-   void *userdata)
+test_layer_create_notification_callback(struct wl_listener *

[PATCH weston 06/16] ivi-shell: rework create_surface notification

[Ucan, Emre (ADITG/SW1)]

The add_notification_create_surface API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to add_listener_create_surface.

This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
   by controller plugins
3. Remove API is not needed. Controller plugins can easily
   remove the listener link.

Signed-off-by: Emre Ucan 
---
 ivi-shell/hmi-controller.c   |   14 -
 ivi-shell/ivi-layout-export.h|4 +---
 ivi-shell/ivi-layout.c   |   40 ++
 tests/ivi_layout-internal-test.c |2 +-
 tests/ivi_layout-test-plugin.c   |   20 ++-
 5 files changed, 28 insertions(+), 52 deletions(-)

diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index 1ef008d..bd38717 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -127,6 +127,8 @@ struct hmi_controller {
struct weston_compositor   *compositor;
struct wl_listener  destroy_listener;
 
+   struct wl_listener  surface_created;
+
struct wl_client   *user_interface;
struct ui_setting   ui_setting;
 
@@ -576,10 +578,12 @@ create_layer(struct weston_output *output,
  * Internal set notification
  */
 static void
-set_notification_create_surface(struct ivi_layout_surface *ivisurf,
-   void *userdata)
+set_notification_create_surface(struct wl_listener *listener, void *data)
 {
-   struct hmi_controller *hmi_ctrl = userdata;
+   struct hmi_controller *hmi_ctrl =
+   wl_container_of(listener, hmi_ctrl,
+   surface_created);
+   struct ivi_layout_surface *ivisurf = (struct ivi_layout_surface*) data;
struct hmi_controller_layer *layer_link =

wl_container_of(hmi_ctrl->application_layer_list.prev,
layer_link,
@@ -834,8 +838,8 @@ hmi_controller_create(struct weston_compositor *ec)
wl_list_insert(&hmi_ctrl->workspace_fade.layer_list,
   &tmp_link_layer->link);
 
-   ivi_layout_interface->add_notification_create_surface(
-   set_notification_create_surface, hmi_ctrl);
+   hmi_ctrl->surface_created.notify = set_notification_create_surface;
+   
ivi_layout_interface->add_listener_create_surface(&hmi_ctrl->surface_created);
ivi_layout_interface->add_notification_remove_surface(
set_notification_remove_surface, hmi_ctrl);
ivi_layout_interface->add_notification_configure_surface(
diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index f8d29da..7f5e785 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -181,9 +181,7 @@ struct ivi_layout_interface {
/**
 * \brief register/unregister for notification when ivi_surface is 
created
 */
-   int32_t (*add_notification_create_surface)(
-   surface_create_notification_func callback,
-   void *userdata);
+   int32_t (*add_listener_create_surface)(struct wl_listener *listener);
 
void (*remove_notification_create_surface)(
surface_create_notification_func callback,
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 80f8496..ac86049 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -965,23 +965,6 @@ layer_removed(struct wl_listener *listener, void *data)
 }
 
 static void
-surface_created(struct wl_listener *listener, void *data)
-{
-   struct ivi_layout_surface *ivisurface = data;
-
-   struct listener_layout_notification *notification =
-   container_of(listener,
-struct listener_layout_notification,
-listener);
-
-   struct ivi_layout_notification_callback *created_callback =
-   notification->userdata;
-
-   ((surface_create_notification_func)created_callback->callback)
-   (ivisurface, created_callback->data);
-}
-
-static void
 surface_removed(struct wl_listener *listener, void *data)
 {
struct ivi_layout_surface *ivisurface = data;
@@ -1137,29 +1120,18 @@ 
ivi_layout_remove_notification_remove_layer(layer_remove_notification_func callb
 }
 
 static int32_t
-ivi_layout_add_notification_create_surface(surface_create_notification_func 
callback,
-  void *userdata)
+ivi_layout_add_listener_create_surface(struct wl_listener *listener)
 {
struct ivi_layout *layout = get_instance();
-   struct ivi_layout_notification_callback *created_callback = NULL;
 
-   if (callback == NULL) {
-   weston_log("ivi_layout_add_notification_create_surface: inv

[PATCH weston 07/16] ivi-shell: remove remove_notification_create_surface

[Ucan, Emre (ADITG/SW1)]

ivi_layout_remove_notification_remove_surface API is
removed, because it is not needed after the changes to
the ivi_layout_add_notification_create_surface.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h |8 
 ivi-shell/ivi-layout.c|9 -
 2 files changed, 17 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 7f5e785..b03fd43 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -146,10 +146,6 @@ typedef void (*layer_remove_notification_func)(
struct ivi_layout_layer *ivilayer,
void *userdata);
 
-typedef void (*surface_create_notification_func)(
-   struct ivi_layout_surface *ivisurf,
-   void *userdata);
-
 typedef void (*surface_remove_notification_func)(
struct ivi_layout_surface *ivisurf,
void *userdata);
@@ -183,10 +179,6 @@ struct ivi_layout_interface {
 */
int32_t (*add_listener_create_surface)(struct wl_listener *listener);
 
-   void (*remove_notification_create_surface)(
-   surface_create_notification_func callback,
-   void *userdata);
-
/**
 * \brief register/unregister for notification when ivi_surface is 
removed
 */
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index ac86049..4b4114f 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -1134,14 +1134,6 @@ ivi_layout_add_listener_create_surface(struct 
wl_listener *listener)
return IVI_SUCCEEDED;
 }
 
-static void
-ivi_layout_remove_notification_create_surface(surface_create_notification_func 
callback,
- void *userdata)
-{
-   struct ivi_layout *layout = get_instance();
-   
remove_notification(&layout->surface_notification.created.listener_list, 
callback, userdata);
-}
-
 static int32_t
 ivi_layout_add_notification_remove_surface(surface_remove_notification_func 
callback,
   void *userdata)
@@ -2202,7 +2194,6 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
 * surface controller interfaces
 */
.add_listener_create_surface= 
ivi_layout_add_listener_create_surface,
-   .remove_notification_create_surface = 
ivi_layout_remove_notification_create_surface,
.add_notification_remove_surface= 
ivi_layout_add_notification_remove_surface,
.remove_notification_remove_surface = 
ivi_layout_remove_notification_remove_surface,
.add_notification_configure_surface = 
ivi_layout_add_notification_configure_surface,
-- 
1.7.9.5

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

[PATCH weston 05/16] ivi-shell: remove layer_remove_notification APIs

[Ucan, Emre (ADITG/SW1)]

ivi_layout_layer_remove_notification and
ivi_layout_layer_remove_notification_by_callback APIs
are removed, because they are not needed after the changes
to the ivi_layout_layer_add_notification.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h |   18 --
 ivi-shell/ivi-layout.c|   54 +
 2 files changed, 1 insertion(+), 71 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 9db18e0..f8d29da 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -138,12 +138,6 @@ enum ivi_layout_transition_type{
IVI_LAYOUT_TRANSITION_MAX,
 };
 
-typedef void (*layer_property_notification_func)(
-   struct ivi_layout_layer *ivilayer,
-   const struct ivi_layout_layer_properties *,
-   enum ivi_layout_notification_mask mask,
-   void *userdata);
-
 typedef void (*layer_create_notification_func)(
struct ivi_layout_layer *ivilayer,
void *userdata);
@@ -531,11 +525,6 @@ struct ivi_layout_interface {
  struct wl_listener *listener);
 
/**
-* \brief remove notification on property changes of ivi_layer
-*/
-   void (*layer_remove_notification)(struct ivi_layout_layer *ivilayer);
-
-   /**
 * \brief set type of transition animation
 */
int32_t (*layer_set_transition)(struct ivi_layout_layer *ivilayer,
@@ -595,13 +584,6 @@ struct ivi_layout_interface {
void *target, size_t size,
int32_t x, int32_t y,
int32_t width, int32_t height);
-
-   /**
-* \brief remove notification by callback on property changes of 
ivi_layer
-*/
-   void (*layer_remove_notification_by_callback)(struct ivi_layout_layer 
*ivilayer,
- 
layer_property_notification_func callback,
- void *userdata);
 };
 
 #ifdef __cplusplus
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 25df1f9..80f8496 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -181,26 +181,6 @@ get_screen_from_output(struct weston_output *output)
return NULL;
 }
 
-static void
-remove_all_notification(struct wl_list *listener_list)
-{
-   struct wl_listener *listener = NULL;
-   struct wl_listener *next = NULL;
-
-   wl_list_for_each_safe(listener, next, listener_list, link) {
-   struct listener_layout_notification *notification = NULL;
-   wl_list_remove(&listener->link);
-
-   notification =
-   container_of(listener,
-struct listener_layout_notification,
-listener);
-
-   free(notification->userdata);
-   free(notification);
-   }
-}
-
 /**
  * Called at destruction of wl_surface/ivi_surface
  */
@@ -1565,30 +1545,6 @@ ivi_layout_layer_create_with_dimension(uint32_t id_layer,
 }
 
 static void
-ivi_layout_layer_remove_notification(struct ivi_layout_layer *ivilayer)
-{
-   if (ivilayer == NULL) {
-   weston_log("ivi_layout_layer_remove_notification: invalid 
argument\n");
-   return;
-   }
-
-   remove_all_notification(&ivilayer->property_changed.listener_list);
-}
-
-static void
-ivi_layout_layer_remove_notification_by_callback(struct ivi_layout_layer 
*ivilayer,
-
layer_property_notification_func callback,
-void *userdata)
-{
-   if (ivilayer == NULL) {
-   weston_log("ivi_layout_layer_remove_notification_by_callback: 
invalid argument\n");
-   return;
-   }
-
-   remove_notification(&ivilayer->property_changed.listener_list, 
callback, userdata);
-}
-
-static void
 ivi_layout_layer_destroy(struct ivi_layout_layer *ivilayer)
 {
struct ivi_layout *layout = get_instance();
@@ -1610,8 +1566,6 @@ ivi_layout_layer_destroy(struct ivi_layout_layer 
*ivilayer)
wl_list_remove(&ivilayer->order.link);
wl_list_remove(&ivilayer->link);
 
-   ivi_layout_layer_remove_notification(ivilayer);
-
free(ivilayer);
 }
 
@@ -2320,7 +2274,6 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
.layer_remove_surface   = 
ivi_layout_layer_remove_surface,
.layer_set_render_order = 
ivi_layout_layer_set_render_order,
.layer_add_listener = ivi_layout_layer_add_listener,
-   .layer_remove_notification  = 
ivi_layout_layer_remove_notification,
.layer_set_transition   = 
ivi_layout_layer_set_transition,
 
  

[PATCH weston 04/16] ivi-shell: rework layer_add_notification API

[Ucan, Emre (ADITG/SW1)]

The layer_add_notification API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to layer_add_listener.

This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
   by controller plugins
3. Remove API is not needed. Controller plugins can easily
   remove the listener link.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h|5 ++---
 ivi-shell/ivi-layout.c   |   43 +++---
 tests/ivi_layout-internal-test.c |   33 -
 3 files changed, 28 insertions(+), 53 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 7a25825..9db18e0 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -527,9 +527,8 @@ struct ivi_layout_interface {
 * \return IVI_SUCCEEDED if the method call was successful
 * \return IVI_FAILED if the method call was failed
 */
-   int32_t (*layer_add_notification)(struct ivi_layout_layer *ivilayer,
- layer_property_notification_func 
callback,
- void *userdata);
+   int32_t (*layer_add_listener)(struct ivi_layout_layer *ivilayer,
+ struct wl_listener *listener);
 
/**
 * \brief remove notification on property changes of ivi_layer
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 013e096..25df1f9 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -985,23 +985,6 @@ layer_removed(struct wl_listener *listener, void *data)
 }
 
 static void
-layer_prop_changed(struct wl_listener *listener, void *data)
-{
-   struct ivi_layout_layer *ivilayer = data;
-
-   struct listener_layout_notification *layout_listener =
-   container_of(listener,
-struct listener_layout_notification,
-listener);
-
-   struct ivi_layout_notification_callback *prop_callback =
-   layout_listener->userdata;
-
-   ((layer_property_notification_func)prop_callback->callback)
-   (ivilayer, &ivilayer->prop, ivilayer->prop.event_mask, 
prop_callback->data);
-}
-
-static void
 surface_created(struct wl_listener *listener, void *data)
 {
struct ivi_layout_surface *ivisurface = data;
@@ -1983,29 +1966,17 @@ ivi_layout_surface_get_size(struct ivi_layout_surface 
*ivisurf,
 }
 
 static int32_t
-ivi_layout_layer_add_notification(struct ivi_layout_layer *ivilayer,
- layer_property_notification_func callback,
- void *userdata)
+ivi_layout_layer_add_listener(struct ivi_layout_layer *ivilayer,
+ struct wl_listener *listener)
 {
-   struct ivi_layout_notification_callback *prop_callback = NULL;
-
-   if (ivilayer == NULL || callback == NULL) {
-   weston_log("ivi_layout_layer_add_notification: invalid 
argument\n");
-   return IVI_FAILED;
-   }
-
-   prop_callback = malloc(sizeof *prop_callback);
-   if (prop_callback == NULL) {
-   weston_log("fails to allocate memory\n");
+   if (ivilayer == NULL || listener == NULL) {
+   weston_log("ivi_layout_layer_add_listener: invalid argument\n");
return IVI_FAILED;
}
 
-   prop_callback->callback = callback;
-   prop_callback->data = userdata;
+   wl_signal_add(&ivilayer->property_changed, listener);
 
-   return add_notification(&ivilayer->property_changed,
-   layer_prop_changed,
-   prop_callback);
+   return IVI_SUCCEEDED;
 }
 
 static const struct ivi_layout_surface_properties *
@@ -2348,7 +2319,7 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
.layer_add_surface  = ivi_layout_layer_add_surface,
.layer_remove_surface   = 
ivi_layout_layer_remove_surface,
.layer_set_render_order = 
ivi_layout_layer_set_render_order,
-   .layer_add_notification = 
ivi_layout_layer_add_notification,
+   .layer_add_listener = ivi_layout_layer_add_listener,
.layer_remove_notification  = 
ivi_layout_layer_remove_notification,
.layer_set_transition   = 
ivi_layout_layer_set_transition,
 
diff --git a/tests/ivi_layout-internal-test.c b/tests/ivi_layout-internal-test.c
index 99d10a4..1cd6c3f 100644
--- a/tests/ivi_layout-internal-test.c
+++ b/tests/ivi_layout-internal-test.c
@@ -35,11 +35,14 @@
 #include "ivi-shell/ivi-layout-export.h"
 #include "ivi-shell/ivi-layout-private.h"
 #include "ivi-test.h"
+#include "shared/helpers.h"
 
 struct test_context {
struct weston_compositor *compositor;
const

[PATCH weston 00/16] IVI Layout Notification APIs Rework

[Ucan, Emre (ADITG/SW1)]

I changed the interface of the notification APIs to get a wl_listener
instead of a ivi-shell specific notification callback function.

This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
   by controller plugins
3. Remove API is not needed. Controller plugins can easily
   remove the listener link.

The first patch is a preparation for the notification API changes.
It moves the event_mask to ivi_layout_surface/layer_properties struct,
so that it is accessible by get_properties_of_layer/surface APIs. Then,
it is not needed to send event_mask with an ivi-shell callback function.

The patches 2-15 modifies and renames IVI Layout notification APIs, and
removes their remove APIs.

The 16th patch removes content_observer callback function which is a
leftover of the patch: 193e301c740b582f20307e3e08f8373d26ea968f

Emre Ucan (16):
  ivi-shell: move event_mask to properties struct
  ivi-shell: rework surface_add_notification API
  ivi-shell: remove surface_remove_notification APIs
  ivi-shell: rework layer_add_notification API
  ivi-shell: remove layer_remove_notification APIs
  ivi-shell: rework create_surface notification
  ivi-shell: remove remove_notification_create_surface
  ivi-shell: rework create_layer_notification
  ivi-shell: remove remove_notification_create_layer
  ivi-shell: rework remove_layer notification
  ivi-shell: remove remove_notification_remove_layer
  ivi-shell: rework remove_surface notification
  ivi-shell: remove remove_notification_remove_surface
  ivi-shell: rework configure_surface notification
  ivi-shell: remove remove_notification_configure_surface
  ivi-shell: remove content_observer leftover

 ivi-shell/hmi-controller.c   |   42 +--
 ivi-shell/ivi-layout-export.h|  113 +---
 ivi-shell/ivi-layout-private.h   |2 -
 ivi-shell/ivi-layout.c   |  545 +-
 tests/ivi_layout-internal-test.c |   76 +++---
 tests/ivi_layout-test-plugin.c   |   93 ---
 6 files changed, 209 insertions(+), 662 deletions(-)

-- 
1.7.9.5

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

[PATCH weston 03/16] ivi-shell: remove surface_remove_notification APIs

[Ucan, Emre (ADITG/SW1)]

ivi_layout_surface_remove_notification and
ivi_layout_surface_remove_notification_by_callback APIs
are removed, because they are not needed after the changes
to the ivi_layout_surface_add_notification.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h  |   18 --
 ivi-shell/ivi-layout.c |   28 
 tests/ivi_layout-test-plugin.c |6 ++
 3 files changed, 2 insertions(+), 50 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 8dc32cb..7a25825 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -144,12 +144,6 @@ typedef void (*layer_property_notification_func)(
enum ivi_layout_notification_mask mask,
void *userdata);
 
-typedef void (*surface_property_notification_func)(
-   struct ivi_layout_surface *ivisurf,
-   const struct ivi_layout_surface_properties *,
-   enum ivi_layout_notification_mask mask,
-   void *userdata);
-
 typedef void (*layer_create_notification_func)(
struct ivi_layout_layer *ivilayer,
void *userdata);
@@ -332,11 +326,6 @@ struct ivi_layout_interface {
struct wl_listener *listener);
 
/**
-* \brief remove notification on property changes of ivi_surface
-*/
-   void (*surface_remove_notification)(struct ivi_layout_surface *ivisurf);
-
-   /**
 * \brief get weston_surface of ivi_surface
 */
struct weston_surface *
@@ -609,13 +598,6 @@ struct ivi_layout_interface {
int32_t width, int32_t height);
 
/**
-* remove notification by callback on property changes of ivi_surface
-*/
-   void (*surface_remove_notification_by_callback)(struct 
ivi_layout_surface *ivisurf,
-   
surface_property_notification_func callback,
-   void *userdata);
-
-   /**
 * \brief remove notification by callback on property changes of 
ivi_layer
 */
void (*layer_remove_notification_by_callback)(struct ivi_layout_layer 
*ivilayer,
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 8a95a11..013e096 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -201,30 +201,6 @@ remove_all_notification(struct wl_list *listener_list)
}
 }
 
-static void
-ivi_layout_surface_remove_notification(struct ivi_layout_surface *ivisurf)
-{
-   if (ivisurf == NULL) {
-   weston_log("ivi_layout_surface_remove_notification: invalid 
argument\n");
-   return;
-   }
-
-   remove_all_notification(&ivisurf->property_changed.listener_list);
-}
-
-static void
-ivi_layout_surface_remove_notification_by_callback(struct ivi_layout_surface 
*ivisurf,
-  
surface_property_notification_func callback,
-  void *userdata)
-{
-   if (ivisurf == NULL) {
-   weston_log("ivi_layout_surface_remove_notification_by_callback: 
invalid argument\n");
-   return;
-   }
-
-   remove_notification(&ivisurf->property_changed.listener_list, callback, 
userdata);
-}
-
 /**
  * Called at destruction of wl_surface/ivi_surface
  */
@@ -247,8 +223,6 @@ ivi_layout_surface_destroy(struct ivi_layout_surface 
*ivisurf)
 
ivi_layout_remove_all_surface_transitions(ivisurf);
 
-   ivi_layout_surface_remove_notification(ivisurf);
-
free(ivisurf);
 }
 
@@ -2347,7 +2321,6 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
.surface_set_destination_rectangle  = 
ivi_layout_surface_set_destination_rectangle,
.surface_set_orientation= 
ivi_layout_surface_set_orientation,
.surface_add_listener   = 
ivi_layout_surface_add_listener,
-   .surface_remove_notification= 
ivi_layout_surface_remove_notification,
.surface_get_weston_surface = 
ivi_layout_surface_get_weston_surface,
.surface_set_transition = 
ivi_layout_surface_set_transition,
.surface_set_transition_duration= 
ivi_layout_surface_set_transition_duration,
@@ -2401,7 +2374,6 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
/**
 * remove notification by callback on property changes of 
ivi_surface/layer
 */
-   .surface_remove_notification_by_callback= 
ivi_layout_surface_remove_notification_by_callback,
.layer_remove_notification_by_callback  = 
ivi_layout_layer_remove_notification_by_callback
 };
 
diff --git a/tests/ivi_layout-test-plugin.c b/tests/ivi_layout-test-plugin.c
index 5cdc203..839a0f6 100644
--- a

[PATCH weston 02/16] ivi-shell: rework surface_add_notification API

[Ucan, Emre (ADITG/SW1)]

The surface_add_notification API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to surface_add_listener.

This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
   by controller plugins
3. Remove API is not needed. Controller plugins can easily
   remove the listener link.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h  |5 ++--
 ivi-shell/ivi-layout.c |   52 +---
 tests/ivi_layout-test-plugin.c |   37 
 3 files changed, 30 insertions(+), 64 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 7a3fbb7..8dc32cb 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -328,9 +328,8 @@ struct ivi_layout_interface {
 * \return IVI_SUCCEEDED if the method call was successful
 * \return IVI_FAILED if the method call was failed
 */
-   int32_t (*surface_add_notification)(struct ivi_layout_surface *ivisurf,
-   surface_property_notification_func 
callback,
-   void *userdata);
+   int32_t (*surface_add_listener)(struct ivi_layout_surface *ivisurf,
+   struct wl_listener *listener);
 
/**
 * \brief remove notification on property changes of ivi_surface
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 5c0e8f4..8a95a11 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -1062,23 +1062,6 @@ surface_removed(struct wl_listener *listener, void *data)
 }
 
 static void
-surface_prop_changed(struct wl_listener *listener, void *data)
-{
-   struct ivi_layout_surface *ivisurf = data;
-
-   struct listener_layout_notification *layout_listener =
-   container_of(listener,
-struct listener_layout_notification,
-listener);
-
-   struct ivi_layout_notification_callback *prop_callback =
-   layout_listener->userdata;
-
-   ((surface_property_notification_func)prop_callback->callback)
-   (ivisurf, &ivisurf->prop, ivisurf->prop.event_mask, 
prop_callback->data);
-}
-
-static void
 surface_configure_changed(struct wl_listener *listener,
  void *data)
 {
@@ -1360,38 +1343,15 @@ ivi_layout_get_surface_from_id(uint32_t id_surface)
 }
 
 static int32_t
-ivi_layout_surface_add_notification(struct ivi_layout_surface *ivisurf,
-   surface_property_notification_func callback,
-   void *userdata)
+ivi_layout_surface_add_listener(struct ivi_layout_surface *ivisurf,
+   struct wl_listener *listener)
 {
-   struct listener_layout_notification* notification = NULL;
-   struct ivi_layout_notification_callback *prop_callback = NULL;
-
-   if (ivisurf == NULL || callback == NULL) {
-   weston_log("ivi_layout_surface_add_notification: invalid 
argument\n");
-   return IVI_FAILED;
-   }
-
-   notification = malloc(sizeof *notification);
-   if (notification == NULL) {
-   weston_log("fails to allocate memory\n");
-   return IVI_FAILED;
-   }
-
-   prop_callback = malloc(sizeof *prop_callback);
-   if (prop_callback == NULL) {
-   weston_log("fails to allocate memory\n");
-   free(notification);
+   if (ivisurf == NULL || listener == NULL) {
+   weston_log("ivi_layout_surface_add_listener: invalid 
argument\n");
return IVI_FAILED;
}
 
-   prop_callback->callback = callback;
-   prop_callback->data = userdata;
-
-   notification->listener.notify = surface_prop_changed;
-   notification->userdata = prop_callback;
-
-   wl_signal_add(&ivisurf->property_changed, ¬ification->listener);
+   wl_signal_add(&ivisurf->property_changed, listener);
 
return IVI_SUCCEEDED;
 }
@@ -2386,7 +2346,7 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
.surface_set_source_rectangle   = 
ivi_layout_surface_set_source_rectangle,
.surface_set_destination_rectangle  = 
ivi_layout_surface_set_destination_rectangle,
.surface_set_orientation= 
ivi_layout_surface_set_orientation,
-   .surface_add_notification   = 
ivi_layout_surface_add_notification,
+   .surface_add_listener   = 
ivi_layout_surface_add_listener,
.surface_remove_notification= 
ivi_layout_surface_remove_notification,
.surface_get_weston_surface = 
ivi_layout_surface_get_weston_surface,
.surface_set_transition = 
ivi_layout_surface_set_transition,
diff --git a/tests/ivi_layout-test-

[PATCH weston 01/16] ivi-shell: move event_mask to properties struct

[Ucan, Emre (ADITG/SW1)]

I moved the event_mask to ivi_layout_*_properties struct,
so that it is easily accessible with get_properties_of_*
APIs.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h  |2 ++
 ivi-shell/ivi-layout-private.h |2 --
 ivi-shell/ivi-layout.c |   66 +++-
 3 files changed, 33 insertions(+), 37 deletions(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 93eb504..7a3fbb7 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -84,6 +84,7 @@ struct ivi_layout_surface_properties
bool visibility;
int32_t transition_type;
uint32_t transition_duration;
+   uint32_t event_mask;
 };
 
 struct ivi_layout_layer_properties
@@ -104,6 +105,7 @@ struct ivi_layout_layer_properties
double start_alpha;
double end_alpha;
uint32_t is_fade_in;
+   uint32_t event_mask;
 };
 
 enum ivi_layout_notification_mask {
diff --git a/ivi-shell/ivi-layout-private.h b/ivi-shell/ivi-layout-private.h
index 7bea2fa..8fca68f 100644
--- a/ivi-shell/ivi-layout-private.h
+++ b/ivi-shell/ivi-layout-private.h
@@ -42,7 +42,6 @@ struct ivi_layout_surface {
struct weston_transform transform;
 
struct ivi_layout_surface_properties prop;
-   uint32_t event_mask;
 
struct {
struct ivi_layout_surface_properties prop;
@@ -64,7 +63,6 @@ struct ivi_layout_layer {
struct ivi_layout_screen *on_screen;
 
struct ivi_layout_layer_properties prop;
-   uint32_t event_mask;
 
struct {
struct ivi_layout_layer_properties prop;
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 5d68d4b..5c0e8f4 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -628,7 +628,7 @@ update_prop(struct ivi_layout_screen  *iviscrn,
bool can_calc = true;
 
/*In case of no prop change, this just returns*/
-   if (!ivilayer->event_mask && !ivisurf->event_mask)
+   if (!ivilayer->prop.event_mask && !ivisurf->prop.event_mask)
return;
 
update_opacity(ivilayer, ivisurf);
@@ -828,7 +828,7 @@ commit_layer_list(struct ivi_layout *layout)
ivisurf->on_layer = NULL;
wl_list_remove(&ivisurf->order.link);
wl_list_init(&ivisurf->order.link);
-   ivisurf->event_mask |= IVI_NOTIFICATION_REMOVE;
+   ivisurf->prop.event_mask |= IVI_NOTIFICATION_REMOVE;
}
 
assert(wl_list_empty(&ivilayer->order.surface_list));
@@ -839,7 +839,7 @@ commit_layer_list(struct ivi_layout *layout)
wl_list_insert(&ivilayer->order.surface_list,
   &ivisurf->order.link);
ivisurf->on_layer = ivilayer;
-   ivisurf->event_mask |= IVI_NOTIFICATION_ADD;
+   ivisurf->prop.event_mask |= IVI_NOTIFICATION_ADD;
}
 
ivilayer->order.dirty = 0;
@@ -865,7 +865,7 @@ commit_screen_list(struct ivi_layout *layout)
ivilayer->on_screen = NULL;
wl_list_remove(&ivilayer->order.link);
wl_list_init(&ivilayer->order.link);
-   ivilayer->event_mask |= IVI_NOTIFICATION_REMOVE;
+   ivilayer->prop.event_mask |= 
IVI_NOTIFICATION_REMOVE;
}
 
assert(wl_list_empty(&iviscrn->order.layer_list));
@@ -878,7 +878,7 @@ commit_screen_list(struct ivi_layout *layout)
wl_list_insert(&iviscrn->order.layer_list,
   &ivilayer->order.link);
ivilayer->on_screen = iviscrn;
-   ivilayer->event_mask |= IVI_NOTIFICATION_ADD;
+   ivilayer->prop.event_mask |= 
IVI_NOTIFICATION_ADD;
}
 
iviscrn->order.dirty = 0;
@@ -923,14 +923,14 @@ static void
 send_surface_prop(struct ivi_layout_surface *ivisurf)
 {
wl_signal_emit(&ivisurf->property_changed, ivisurf);
-   ivisurf->event_mask = 0;
+   ivisurf->pending.prop.event_mask = 0;
 }
 
 static void
 send_layer_prop(struct ivi_layout_layer *ivilayer)
 {
wl_signal_emit(&ivilayer->property_changed, ivilayer);
-   ivilayer->event_mask = 0;
+   ivilayer->pending.prop.event_mask = 0;
 }
 
 static void
@@ -940,12 +940,12 @@ send_prop(struct ivi_layout *layout)
struct ivi_layout_surface *ivisurf  = NULL;
 
wl_list_for_each_reverse(ivilayer, &layout->layer_list, link) {
-   if (ivilayer->event_mask)
+   if (ivilayer->prop.event_mask)
send_layer_prop(ivilayer);
}
 
wl_list_for_each_reverse(ivisurf, &layout->sur

Re: Collaboration on standard Wayland protocol extensions

[Daniel Stone]

Hi,

On 31 March 2016 at 00:16, Drew DeVault  wrote:
> Simply because xrandr was/is a poorly implemented mess doesn't mean that
> we are going to end up making a poorly implemented mess. We have the
> benefit of hindsight. After all, xorg is a poorly implemented mess but
> we still made Wayland, didn't we? (Though some could argue that we've
> just ended up with a well implemented mess...)

X and Wayland protocols have very different design principles guiding
them. X (often by necessity) exposes as much as possible of its
internal workings to clients, and allows total external manipulation.
That's not the case for Wayland, so what you're proposing is a
significant departure.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Semantics of wl_subcompositor::get_subsurface

[Pekka Paalanen]

On Thu, 24 Mar 2016 08:53:11 +0100
Martin Graesslin  wrote:

> On Monday, March 21, 2016 11:07:39 AM CET you wrote:
> > On Mon, 21 Mar 2016 08:36:59 +0100
> > 
> > Martin Graesslin  wrote:  
> > > Hi Wayland-devs,
> > > 
> > > while implementing sub-surface support in KWin I run into a small problem
> > > regarding the get_subsurface request:
> > > 
> > > When should the new subsurface be added to the parent surface?
> > > 
> > > My interpretation was that the subsurface will only be added after the
> > > next
> > > commit on the parent surface. As that would allow setting up the
> > > sub-surface completely and also calls like place_above are
> > > double-buffered. To me this looked like all child surface ordering
> > > changes are double buffered.  
> > Hi Martin,
> > 
> > child surface ordering changes are indeed meant to be applied
> > atomically by a commit on the parent.
> > 
> > And by "commit" on that sentence I mean "when the pending parent
> > surface state is applied". I have struggled a lot with the language in
> > the sub-surface spec.  
> 
> :-)
> 
> >   
> > > But testing with real world applications (systemsettings5 on QtWayland)
> > > showed that the parent surface does not get committed after the
> > > get_subsurface request and my implementation wasn't able to make the
> > > subsurface show at all due to that. On the other hand on Weston it works.
> > > 
> > > So what's the expected way? Is the get_subsurface request double buffered?
> > > If yes, could the documentation be extended about that?  
> > 
> > This is probably a case I have overlooked in both documentation and
> > Weston implementation. I likely have not considered that the to-be
> > sub-surface could be already fully set up, i.e. contents committed
> > and all.
> > 
> > Considering that a sub-surface is specified to start in synchronized
> > mode, I think the following would make sense when the parent surface is
> > already mapped and the to-be sub-surface has already contents
> > committed. The sub-surface gets mapped when:
> > - the client calls commit on the parent surface the next time, or
> > - the client calls set_desync on/after which according to the
> >   sub-surface rules the pending/cached surface state gets applied.  
> 
> that would be when the parents state gets applied?

This is from off the top of my head, but if the parent surface is
already acting non-synchronized itself, then set_desync would map the
sub-surface immediately.

However, please see below. If this gets too tricky, maybe we can just
require parent state to be applied instead, to be more consistent in
behaviour.

> > IOW, I would agree with your interpretation when the sub-surface stays
> > in synchronized mode.
> > 
> > *** (a dead-end pondering)
> > 
> > However, I don't think we can simply say "get_subsurface is
> > double-buffered and gets applied on the next parent surface commit"
> > without some more thought, because there are alternative paths that
> > avoid the need for parent surface commit:
> > 
> > 1. wl_surface A is already mapped, and effectively in desync mode
> > 2. wl_surface B has content applied (proper attach+commit)
> > 3. B is made a sub-surface of A (wl_subcompositor.get_subsurface)
> > 4. B is set to desync mode (wl_subsurface.set_desync)
> > 
> > Since the parent surface is effectively in desync mode, set_desync on B
> > applies cached state immediately. That allows B to be mapped (appear on
> > screen) with two possibilities:
> > - immediately at set_desync, or
> > - on the next commit on B after set_desync.
> > 
> > Which one happens is IMO unspecified. set_desync spec talks about
> > cached state, but as B has not seen commits while being a sub-surface
> > (they happened earlier), it does not have cached state.
> > 
> > Would it make more sense to pick the next commit on B after set_desync?  
> 
> I would say that making surface B a sub-surface of A affects the pending 
> state 
> of surface A. Thus I would say it can only get mapped once surface A's state 
> is applied and the state of surface B just doesn't matter.

That could indeed be the way to make things more clear.

> > 
> > ***
> > 
> > Or, if we actually do specify that get_subsurface will be effective on
> > the next parent surface commit, then there is no way to map the
> > sub-surface without a parent commit. As I see adding sub-surfaces as an
> > action on the parent surface, I'd be fine with this interpretation too.
> > If the client really wants the sub-surface to appear on its own time,
> > it can simply commit the parent surface straight away. Maybe this would
> > be simpler?  
> 
> yep, that's how I would see it.

Cool.

> > 
> > Hmm, and there is the question of positioning the sub-surface.
> > Regardless of modes, getting sub-surface position change applied always
> > requires a commit on the parent surface. Z-ordering is the same too. If
> > the defaults do not happen to be fine, the surfaces would glitch, if
> > the sub-surface was allowed to be

Re: [PATCH libinput] touchpad: fix left-handed top software trackpoint buttons

[Hans de Goede]

Hi,

On 31-03-16 03:52, Peter Hutterer wrote:

The previous code would swap the top software buttons depending on the
touchpad's left-handed setting, not the trackpoint setting. Changing both
devices to left-handed resulted in a double-swap, i.e. the trackpoint was
always right-handed.

https://bugs.freedesktop.org/show_bug.cgi?id=94733

Signed-off-by: Peter Hutterer 


Patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
  src/evdev-mt-touchpad-buttons.c |  23 ---
  test/trackpoint.c   | 132 
  2 files changed, 148 insertions(+), 7 deletions(-)

diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index 82c99c7..076eab0 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -963,6 +963,7 @@ tp_post_clickpadbutton_buttons(struct tp_dispatch *tp, 
uint64_t time)
uint32_t current, old, button, is_top;
enum libinput_button_state state;
enum { AREA = 0x01, LEFT = 0x02, MIDDLE = 0x04, RIGHT = 0x08 };
+   bool want_left_handed = true;

current = tp->buttons.state;
old = tp->buttons.old_state;
@@ -1008,14 +1009,22 @@ tp_post_clickpadbutton_buttons(struct tp_dispatch *tp, 
uint64_t time)
return 0;
}

-   if ((area & MIDDLE) || ((area & LEFT) && (area & RIGHT)))
-   button = evdev_to_left_handed(tp->device, BTN_MIDDLE);
-   else if (area & RIGHT)
-   button = evdev_to_left_handed(tp->device, BTN_RIGHT);
-   else if (area & LEFT)
-   button = evdev_to_left_handed(tp->device, BTN_LEFT);
-   else /* main or no area (for clickfinger) is always BTN_LEFT */
+   if ((area & MIDDLE) || ((area & LEFT) && (area & RIGHT))) {
+   button = BTN_MIDDLE;
+   } else if (area & RIGHT) {
+   button = BTN_RIGHT;
+   } else if (area & LEFT) {
button = BTN_LEFT;
+   } else { /* main or no area (for clickfinger) is always 
BTN_LEFT */
+   button = BTN_LEFT;
+   want_left_handed = false;
+   }
+
+   if (is_top)
+   want_left_handed = false;
+
+   if (want_left_handed)
+   button = evdev_to_left_handed(tp->device, button);

tp->buttons.active = button;
tp->buttons.active_is_topbutton = is_top;
diff --git a/test/trackpoint.c b/test/trackpoint.c
index 567fba8..5a68b19 100644
--- a/test/trackpoint.c
+++ b/test/trackpoint.c
@@ -150,6 +150,135 @@ START_TEST(trackpoint_scroll_source)
  }
  END_TEST

+START_TEST(trackpoint_topsoftbuttons_left_handed_trackpoint)
+{
+   struct litest_device *touchpad = litest_current_device();
+   struct litest_device *trackpoint;
+   struct libinput *li = touchpad->libinput;
+   enum libinput_config_status status;
+   struct libinput_event *event;
+   struct libinput_device *device;
+
+   trackpoint = litest_add_device(li, LITEST_TRACKPOINT);
+   litest_drain_events(li);
+   /* touchpad right-handed, trackpoint left-handed */
+   status = libinput_device_config_left_handed_set(
+   trackpoint->libinput_device, 1);
+   ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+
+   litest_touch_down(touchpad, 0, 5, 5);
+   libinput_dispatch(li);
+   litest_button_click(touchpad, BTN_LEFT, true);
+   libinput_dispatch(li);
+
+   event = libinput_get_event(li);
+   litest_is_button_event(event,
+  BTN_RIGHT,
+  LIBINPUT_BUTTON_STATE_PRESSED);
+   device = libinput_event_get_device(event);
+   ck_assert(device == trackpoint->libinput_device);
+   libinput_event_destroy(event);
+
+   litest_button_click(touchpad, BTN_LEFT, false);
+   libinput_dispatch(li);
+   event = libinput_get_event(li);
+   litest_is_button_event(event,
+  BTN_RIGHT,
+  LIBINPUT_BUTTON_STATE_RELEASED);
+   device = libinput_event_get_device(event);
+   ck_assert(device == trackpoint->libinput_device);
+   libinput_event_destroy(event);
+
+   litest_delete_device(trackpoint);
+}
+END_TEST
+
+START_TEST(trackpoint_topsoftbuttons_left_handed_touchpad)
+{
+   struct litest_device *touchpad = litest_current_device();
+   struct litest_device *trackpoint;
+   struct libinput *li = touchpad->libinput;
+   enum libinput_config_status status;
+   struct libinput_event *event;
+   struct libinput_device *device;
+
+   trackpoint = litest_add_device(li, LITEST_TRACKPOINT);
+   litest_drain_events(li);
+   /* touchpad left-handed, trackpoint right-handed */
+   status = libinput_device_

Re: [PATCH v7 wayland-protocols] Add the tablet protocol

[Peter Hutterer]

sorry about the delay, this one slipped through

On Fri, Mar 11, 2016 at 04:12:55PM -0800, Jason Gerecke wrote:
> On 03/08/2016 10:10 PM, Peter Hutterer wrote:
> > Signed-off-by: Peter Hutterer 
> > Reviewed-by: Daniel Stone 
> > Reviewed-by: Jonas Ådahl 
> > ---
> > Changes to v6:
> > - a bunch of typos/grammar fixes
> > - clarified the "down" event on enter
> > - clarified the "up" event, specifically: the up event isn't sent when the
> >   tool leaves the input region but rather when the compositor deems it's up
> > 

[...]

> > +
> > +   Clients should choose either value and avoid mixing degrees and
> > +   clicks. The compositor may accumulate values smaller than a logical
> > +   click and emulate click events when a certain threshold is met.
> > +   Thus, wl_tablet_tool.wheel events with non-zero clicks values may
> > +   have different degrees values.
> > +  
> > +  
> > +  
> > +
> 
> I just noticed this while working on the Xwayland implementation -- is
> there a reason the angles (in tilt, rotation, and here in wheel) aren't
> just using the "fixed" type? If its a wart, it might be one to remove
> before too long now that v1 has made it upstream...

hmm, good point, not sure why I didn't use wl_fixed other than "i didn't
think of it". It has finer granularity and provides the required range, so
it would be the better choice. This is something to fix in a new version
though :(

Carlos, any yay/nay comments for the GTK side?

Cheers,
   Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel