[PATCH libinput] Remove LIBINPUT_EVENT_TABLET_PAD_MODE event

2016-07-07 Thread Peter Hutterer 
Unimplemented and it wasn't supposed to be in the series.

https://lists.freedesktop.org/archives/wayland-devel/2016-June/029376.html

Signed-off-by: Peter Hutterer 
---
 src/libinput.c  |  2 --
 src/libinput.h  | 13 -
 test/litest.c   |  3 ---
 tools/event-debug.c | 22 --
 tools/event-gui.c   |  1 -
 5 files changed, 41 deletions(-)

diff --git a/src/libinput.c b/src/libinput.c
index cf0ed5b..a8240bd 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1691,7 +1691,6 @@ libinput_event_destroy(struct libinput_event *event)
case LIBINPUT_EVENT_TABLET_PAD_RING:
case LIBINPUT_EVENT_TABLET_PAD_STRIP:
case LIBINPUT_EVENT_TABLET_PAD_BUTTON:
-   case LIBINPUT_EVENT_TABLET_PAD_MODE:
libinput_event_tablet_pad_destroy(
   libinput_event_get_tablet_pad_event(event));
break;
@@ -2613,7 +2612,6 @@ event_type_to_str(enum libinput_event_type type)
CASE_RETURN_STRING(LIBINPUT_EVENT_TABLET_PAD_BUTTON);
CASE_RETURN_STRING(LIBINPUT_EVENT_TABLET_PAD_RING);
CASE_RETURN_STRING(LIBINPUT_EVENT_TABLET_PAD_STRIP);
-   CASE_RETURN_STRING(LIBINPUT_EVENT_TABLET_PAD_MODE);
CASE_RETURN_STRING(LIBINPUT_EVENT_GESTURE_SWIPE_BEGIN);
CASE_RETURN_STRING(LIBINPUT_EVENT_GESTURE_SWIPE_UPDATE);
CASE_RETURN_STRING(LIBINPUT_EVENT_GESTURE_SWIPE_END);
diff --git a/src/libinput.h b/src/libinput.h
index 491eee3..d2abb31 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -734,19 +734,6 @@ enum libinput_event_type {
 */
LIBINPUT_EVENT_TABLET_PAD_STRIP,
 
-   /**
-* A mode change on a device with the @ref
-* LIBINPUT_DEVICE_CAP_TABLET_PAD capability.
-*
-* This event is triggered when the mode is changed through
-* external means. The event reflects a mode change (see @ref
-* tablet-pad-modes) occurring as a result other than that of
-* pressing a mode toggle button.
-*
-* @note Support for this event is not yet implemented.
-*/
-   LIBINPUT_EVENT_TABLET_PAD_MODE,
-
LIBINPUT_EVENT_GESTURE_SWIPE_BEGIN = 800,
LIBINPUT_EVENT_GESTURE_SWIPE_UPDATE,
LIBINPUT_EVENT_GESTURE_SWIPE_END,
diff --git a/test/litest.c b/test/litest.c
index 0df480e..83ebc74 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -2150,9 +2150,6 @@ litest_event_type_str(struct libinput_event *event)
case LIBINPUT_EVENT_TABLET_PAD_STRIP:
str = "TABLET PAD STRIP";
break;
-   case LIBINPUT_EVENT_TABLET_PAD_MODE:
-   str = "TABLET PAD MODE";
-   break;
}
return str;
 }
diff --git a/tools/event-debug.c b/tools/event-debug.c
index 70f4268..67432b7 100644
--- a/tools/event-debug.c
+++ b/tools/event-debug.c
@@ -130,9 +130,6 @@ print_event_header(struct libinput_event *ev)
case LIBINPUT_EVENT_TABLET_PAD_STRIP:
type = "TABLET_PAD_STRIP";
break;
-   case LIBINPUT_EVENT_TABLET_PAD_MODE:
-   type = "TABLET_PAD_MODE";
-   break;
}
 
printf("%-7s%-16s ", libinput_device_get_sysname(dev), type);
@@ -682,22 +679,6 @@ print_tablet_pad_strip_event(struct libinput_event *ev)
   mode);
 }
 
-static void
-print_tablet_pad_mode_event(struct libinput_event *ev)
-{
-   struct libinput_event_tablet_pad *p = 
libinput_event_get_tablet_pad_event(ev);
-   struct libinput_tablet_pad_mode_group *group;
-   unsigned int mode;
-
-   print_event_time(libinput_event_tablet_pad_get_time(p));
-
-   group = libinput_event_tablet_pad_get_mode_group(p);
-   mode = libinput_event_tablet_pad_get_mode(p);
-   printf("group %d mode %d\n",
-  libinput_tablet_pad_mode_group_get_index(group),
-  mode);
-}
-
 static int
 handle_and_print_events(struct libinput *li)
 {
@@ -786,9 +767,6 @@ handle_and_print_events(struct libinput *li)
case LIBINPUT_EVENT_TABLET_PAD_STRIP:
print_tablet_pad_strip_event(ev);
break;
-   case LIBINPUT_EVENT_TABLET_PAD_MODE:
-   print_tablet_pad_mode_event(ev);
-   break;
}
 
libinput_event_destroy(ev);
diff --git a/tools/event-gui.c b/tools/event-gui.c
index 8b4e3e9..b67ca45 100644
--- a/tools/event-gui.c
+++ b/tools/event-gui.c
@@ -843,7 +843,6 @@ handle_event_libinput(GIOChannel *source, GIOCondition 
condition, gpointer data)
case LIBINPUT_EVENT_TABLET_PAD_BUTTON:
case LIBINPUT_EVENT_TABLET_PAD_RING:
case LIBINPUT_EVENT_TABLET_PAD_STRIP:
-   case LIBINPUT_EVENT_TABLET_PAD_MODE:
break;
}
 
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org

Re: [PATCH v4 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

2016-07-07 Thread Jason Gerecke 
On 06/30/2016 05:16 AM, Jonas Ådahl wrote:
> On Thu, Jun 30, 2016 at 01:10:33PM +0200, Carlos Garnacho wrote:
>> Hi!,
>>
>> On Thu, Jun 30, 2016 at 6:27 AM, Jonas Ådahl  wrote:
>>> On Tue, Jun 28, 2016 at 11:21:50PM +0200, Carlos Garnacho wrote:
 The pad's interface is similar to the tool interface, a client is notified 
 of
 the pad after the tablet_added event.

 The pad has three functionalities: buttons, rings and strips.
 Buttons are fairly straightforward, rings and strips are separate 
 interfaces
 with a pointer-axis-like source/value/frame events.
 The two interfaces are effectively identical but for the actual value they
 send (degrees vs normalized position).

 Buttons are sequentially indexed starting with zero, unlike other protocols
 where a linux/input.h-style semantic event code is used. Since we expect 
 all
 buttons to have client-specific functionality, an additional event tells 
 the
 client when a given button index is not available, usually because the
 compositor assignes some function to it (e.g. mode switching, see below).

 Specific to the pad device is the set_feedback request which enables a 
 client
 to set a user-defined string to display for an OSD on the current mappings.
 This request is available for buttons, rings and strips.

 Finally, the pad supports groups, effectively sets of button/ring/strip
 configurations. Those groups may have multiple modes each, so that
 users/clients may map several actions to a single element.

 Signed-off-by: Carlos Garnacho 
 Signed-off-by: Peter Hutterer 
 Reviewed-by: Jason Gerecke 
 ---

> 
> ... snip ...
> 
 +
 +
 +  
 + Sent on wp_tablet_pad_group initialization to announce available 
 rings.
 + One event is sent for each ring available on this pad group.
 +
 + This event is sent in the initial burst of events before the
 + wp_tablet_pad_group.done event. This event is only sent when at least
 + one ring is available.
>>>
>>> The last sentence is redundant. It already says that there'll be one
>>> event per ring, thus no rings, no events. It also makes it slightly
>>> unclear (by the description alone) whethere multiple rings will result
>>> in multiple events.
>>
>> Agreed, removed. As for the last part... I guess the "One event is
>> sent for each ring available..." bit makes it clear enough already?
> 
> Yes, I think that part makes it clear. It was only the part you now
> removed that made it possible to doubt the first part for a second.
> 
>>
> 
> ... snip ...
> 
 +
 +
 +  
 + Notification that the mode was switched.
 +
 + A mode applies to all buttons, rings and strips in a group
 + simultaneously, but a client is not required to assign different 
 actions
 + for each mode. For example, a client may have mode-specific button
 + mappings but map the ring to vertical scrolling in all modes. Mode
 + indices start at 0.
 +
 + Switching modes is compositor-dependent. The compositor may provide
 + visual cues to the client about the mode, e.g. by toggling LEDs on
 + the tablet device. Mode-switching may be software-controlled or
 + controlled by one or more physical buttons. For example, on a Wacom
 + Intuos Pro, the button inside the ring may be assigned to switch
 + between modes.
 +
 + The current mode is compositor-global, the compositor will also send
>>>
>>> Isn't it just seat global? And why would this event be on the pad group
>>> and not on the seat wide interface?
>>
>> perhaps I should expand that first phrase :).
>>
>> The extent of the current mode is pretty much group local, it only
>> affects the buttons/rings/strips that have been announced through this
>> group.
>>
>> However, the current mode of every given group is global to all
>> clients. If you have a client focused with a group in mode=1, focus
>> another client, switch that group to mode=3 and go back to the first
>> client, you'll receive a .mode_switch with mode=3 after
>> wp_tablet_pad.enter.
>>
>> This could be considered similar to keyboard modifiers, you don't
>> reset those (eg. caps lock) when focusing another client, the current
>> state is rather propagated to the newly focused client.
>>
>> I'm replacing the beginning of that paragraph with this:
>> "Compositors will globally track the current mode that every
>> wp_tablet_pad_group has. This event will also be sent after
>> wp_tablet_pad.enter for all groups in the pad in order to..."
> 
> I see. Any reason on why it needs to be compositor global? Couldn't that
> be a decision left to the compositor? Either way, the new wording makes
> me understand whats going on, so it now

Re: [PATCH weston] config-parser: Improve error checks for strtol/strtoul calls

2016-07-07 Thread Bryce Harrington 
On Thu, Jul 07, 2016 at 02:08:28PM -0700, Bryce Harrington wrote:
> Check errno, which is set of over/underflow, out of range, etc.  Also
> check for empty strings (the usages covered in this patch already also
> cover the case where there are non-digits present).  Set errno to 0
> before making the strto*l call in case of pre-existing errors
> (i.e. ENOTTY when running under the testsuite).
> 
> This follows the error checking style used in Wayland
> (c.f. wayland-client.c and scanner.c).
> 
> In tests, also check errno, and add testcases for parsing '0'.
> 
> Signed-off-by: Bryce Harrington 

If this approach looks ok to folks, there are other irregular uses of
strto*l I'll clean up as well subsequently.

> ---
>  shared/config-parser.c |  6 --
>  tests/config-parser-test.c | 34 ++
>  2 files changed, 38 insertions(+), 2 deletions(-)
> 
> diff --git a/shared/config-parser.c b/shared/config-parser.c
> index 2256469..151ae9c 100644
> --- a/shared/config-parser.c
> +++ b/shared/config-parser.c
> @@ -169,8 +169,9 @@ weston_config_section_get_int(struct 
> weston_config_section *section,
>   return -1;
>   }
>  
> + errno = 0;
>   *value = strtol(entry->value, , 0);
> - if (*end != '\0') {
> + if (errno != 0 || end == entry->value || *end != '\0') {
>   *value = default_value;
>   errno = EINVAL;
>   return -1;
> @@ -195,8 +196,9 @@ weston_config_section_get_uint(struct 
> weston_config_section *section,
>   return -1;
>   }
>  
> + errno = 0;
>   *value = strtoul(entry->value, , 0);
> - if (*end != '\0') {
> + if (errno != 0 || end == entry->value || *end != '\0') {
>   *value = default_value;
>   errno = EINVAL;
>   return -1;
> diff --git a/tests/config-parser-test.c b/tests/config-parser-test.c
> index 5dcafc4..735da4e 100644
> --- a/tests/config-parser-test.c
> +++ b/tests/config-parser-test.c
> @@ -116,6 +116,7 @@ static struct zuc_fixture config_test_t1 = {
>   "[bar]\n"
>   "# more comments\n"
>   "number=5252\n"
> + "zero=0\n"
>   "flag=false\n"
>   "\n"
>   "[stuff]\n"
> @@ -263,6 +264,7 @@ ZUC_TEST_F(config_test_t1, test006, data)
>  
>   ZUC_ASSERT_EQ(0, r);
>   ZUC_ASSERT_EQ(5252, n);
> + ZUC_ASSERT_EQ(0, errno);
>  }
>  
>  ZUC_TEST_F(config_test_t1, test007, data)
> @@ -289,8 +291,10 @@ ZUC_TEST_F(config_test_t1, test008, data)
>  
>   section = weston_config_get_section(config, "bar", NULL, NULL);
>   r = weston_config_section_get_uint(section, "number", , 600);
> +
>   ZUC_ASSERT_EQ(0, r);
>   ZUC_ASSERT_EQ(5252, u);
> + ZUC_ASSERT_EQ(0, errno);
>  }
>  
>  ZUC_TEST_F(config_test_t1, test009, data)
> @@ -427,6 +431,36 @@ ZUC_TEST_F(config_test_t1, test017, data)
>   ZUC_ASSERT_EQ(5, i);
>  }
>  
> +ZUC_TEST_F(config_test_t1, test018, data)
> +{
> + int r;
> + int32_t n;
> + struct weston_config_section *section;
> + struct weston_config *config = data;
> +
> + section = weston_config_get_section(config, "bar", NULL, NULL);
> + r = weston_config_section_get_int(section, "zero", , 600);
> +
> + ZUC_ASSERT_EQ(0, r);
> + ZUC_ASSERT_EQ(0, n);
> + ZUC_ASSERT_EQ(0, errno);
> +}
> +
> +ZUC_TEST_F(config_test_t1, test019, data)
> +{
> + int r;
> + uint32_t n;
> + struct weston_config_section *section;
> + struct weston_config *config = data;
> +
> + section = weston_config_get_section(config, "bar", NULL, NULL);
> + r = weston_config_section_get_uint(section, "zero", , 600);
> +
> + ZUC_ASSERT_EQ(0, r);
> + ZUC_ASSERT_EQ(0, n);
> + ZUC_ASSERT_EQ(0, errno);
> +}
> +
>  ZUC_TEST_F(config_test_t2, doesnt_parse, data)
>  {
>   struct weston_config *config = data;
> -- 
> 1.9.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] config-parser: Improve error checks for strtol/strtoul calls

2016-07-07 Thread Bryce Harrington 
Check errno, which is set of over/underflow, out of range, etc.  Also
check for empty strings (the usages covered in this patch already also
cover the case where there are non-digits present).  Set errno to 0
before making the strto*l call in case of pre-existing errors
(i.e. ENOTTY when running under the testsuite).

This follows the error checking style used in Wayland
(c.f. wayland-client.c and scanner.c).

In tests, also check errno, and add testcases for parsing '0'.

Signed-off-by: Bryce Harrington 
---
 shared/config-parser.c |  6 --
 tests/config-parser-test.c | 34 ++
 2 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/shared/config-parser.c b/shared/config-parser.c
index 2256469..151ae9c 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -169,8 +169,9 @@ weston_config_section_get_int(struct weston_config_section 
*section,
return -1;
}
 
+   errno = 0;
*value = strtol(entry->value, , 0);
-   if (*end != '\0') {
+   if (errno != 0 || end == entry->value || *end != '\0') {
*value = default_value;
errno = EINVAL;
return -1;
@@ -195,8 +196,9 @@ weston_config_section_get_uint(struct weston_config_section 
*section,
return -1;
}
 
+   errno = 0;
*value = strtoul(entry->value, , 0);
-   if (*end != '\0') {
+   if (errno != 0 || end == entry->value || *end != '\0') {
*value = default_value;
errno = EINVAL;
return -1;
diff --git a/tests/config-parser-test.c b/tests/config-parser-test.c
index 5dcafc4..735da4e 100644
--- a/tests/config-parser-test.c
+++ b/tests/config-parser-test.c
@@ -116,6 +116,7 @@ static struct zuc_fixture config_test_t1 = {
"[bar]\n"
"# more comments\n"
"number=5252\n"
+   "zero=0\n"
"flag=false\n"
"\n"
"[stuff]\n"
@@ -263,6 +264,7 @@ ZUC_TEST_F(config_test_t1, test006, data)
 
ZUC_ASSERT_EQ(0, r);
ZUC_ASSERT_EQ(5252, n);
+   ZUC_ASSERT_EQ(0, errno);
 }
 
 ZUC_TEST_F(config_test_t1, test007, data)
@@ -289,8 +291,10 @@ ZUC_TEST_F(config_test_t1, test008, data)
 
section = weston_config_get_section(config, "bar", NULL, NULL);
r = weston_config_section_get_uint(section, "number", , 600);
+
ZUC_ASSERT_EQ(0, r);
ZUC_ASSERT_EQ(5252, u);
+   ZUC_ASSERT_EQ(0, errno);
 }
 
 ZUC_TEST_F(config_test_t1, test009, data)
@@ -427,6 +431,36 @@ ZUC_TEST_F(config_test_t1, test017, data)
ZUC_ASSERT_EQ(5, i);
 }
 
+ZUC_TEST_F(config_test_t1, test018, data)
+{
+   int r;
+   int32_t n;
+   struct weston_config_section *section;
+   struct weston_config *config = data;
+
+   section = weston_config_get_section(config, "bar", NULL, NULL);
+   r = weston_config_section_get_int(section, "zero", , 600);
+
+   ZUC_ASSERT_EQ(0, r);
+   ZUC_ASSERT_EQ(0, n);
+   ZUC_ASSERT_EQ(0, errno);
+}
+
+ZUC_TEST_F(config_test_t1, test019, data)
+{
+   int r;
+   uint32_t n;
+   struct weston_config_section *section;
+   struct weston_config *config = data;
+
+   section = weston_config_get_section(config, "bar", NULL, NULL);
+   r = weston_config_section_get_uint(section, "zero", , 600);
+
+   ZUC_ASSERT_EQ(0, r);
+   ZUC_ASSERT_EQ(0, n);
+   ZUC_ASSERT_EQ(0, errno);
+}
+
 ZUC_TEST_F(config_test_t2, doesnt_parse, data)
 {
struct weston_config *config = data;
-- 
1.9.1

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

Re: [PATCH weston 5/6] libweston: do not add libweston-$version to the Cflags

2016-07-07 Thread Quentin Glidic 

On 07/07/2016 18:28, Emil Velikov wrote:

On 7 July 2016 at 10:20, Pekka Paalanen  wrote:

[snip]
Therefore a NAK from me too.


As you guys wish. In that case can we drop the pkgincludedir variable
? Most packages don't bother with it (on my local setup only 7 out of
740 do)


Is there a strong reason to remove it? Right now I would see it as a 
noise commit with no real value.


Cheers,


--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 3/6] README: Document versioning scheme, forward compatibility

2016-07-07 Thread Quentin Glidic 

On 07/07/2016 18:11, Emil Velikov wrote:

On 7 July 2016 at 10:05, Pekka Paalanen  wrote:



>> [snip]


Now that you mentioned the semantics could be of upper or lower
limit, the name should imply the meaning. I only thought of using
it as both lower limit (as in pkg-config check) *and* upper limit
(do not declare API that was added after the given version or
remove API that was deprecated after the given version).


Ack. Considering I already know how it would/should be used, I'm a bit
short on unbiased name. Your earlier suggestion sounds great imho, but
if you have something else in mind please share it :-)


However, I also realized something more.

If you do like I suggested for configure.ac, you would have trouble
using pre-releases of libweston.

Pre-releases of, say 1.13.0, will be released as 1.12.9x. That
would be MINOR=12, so if you use the same numbers for both
pkg-config check and for the CPP macro for API, you cannot test the
13 API until it has been finally released.

So maybe those two need to be separate anyway?


The example will cover this confusion, but the gist is that:
 - No released version of software X should rely on development
version of libweston/libfoo.
 - If there's a serious need to void the above, one should set the
REQUIRED_API to the number it would be in an official/final version.

Example:
libweston (devel. process):
- git tag 1.12.90
- Add API X, guarded behind version 0x010d version check (one could
keep the numbers decimal and/or other)
- other...

User:
- Bump required version to 1.12.90
- Use "-DREQUIRED_API_VERSION=0x010d"
Personally I'm leaning towards adding the define only in the
respective places that need the newer API, but having it in configure
(global scale) would be nice as well.


Regarding that, I’d go the GLib/GTK+ way completely.
That means each function has a
WESTON_AVAILABLE_IN(1, 13)

and *if* a project set
WESTON_VERSION_{MIN,MAX}_ALLOWED, that will make these functions 
deprecated (not sure for the ones above the MAX).


The maint point is that I would rather have the new functions without 
needing to update the define. Or most projects will use 0x as the 
value. :-)


Cheers,


--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 3/6] README: Document versioning scheme, forward compatibility

2016-07-07 Thread Thiago Macieira 
On segunda-feira, 4 de julho de 2016 15:23:51 PDT Emil Velikov wrote:
> +Similar approach is used by ATK, QT and KDE programs/libraries,

Qt, with a lowercase t.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

[PATCH wayland-protocols] Fix grammar for 'an X*'

2016-07-07 Thread Bryce Harrington 
Signed-off-by: Bryce Harrington 
---
 unstable/input-method/input-method-unstable-v1.xml | 2 +-
 unstable/text-input/text-input-unstable-v1.xml | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/unstable/input-method/input-method-unstable-v1.xml 
b/unstable/input-method/input-method-unstable-v1.xml
index 274eac8..c1b2b59 100644
--- a/unstable/input-method/input-method-unstable-v1.xml
+++ b/unstable/input-method/input-method-unstable-v1.xml
@@ -145,7 +145,7 @@
Notify when a key event was sent. Key events should not be used for
normal text input operations, which should be done with commit_string,
delete_surrounding_text, etc. The key event follows the wl_keyboard key
-   event convention. Sym is a XKB keysym, state a wl_keyboard key_state.
+   event convention. Sym is an XKB keysym, state a wl_keyboard key_state.
   
   
   
diff --git a/unstable/text-input/text-input-unstable-v1.xml 
b/unstable/text-input/text-input-unstable-v1.xml
index 1d00a52..d37ffcf 100644
--- a/unstable/text-input/text-input-unstable-v1.xml
+++ b/unstable/text-input/text-input-unstable-v1.xml
@@ -328,7 +328,7 @@
Notify when a key event was sent. Key events should not be used
for normal text input operations, which should be done with
commit_string, delete_surrounding_text, etc. The key event follows
-   the wl_keyboard key event convention. Sym is a XKB keysym, state a
+   the wl_keyboard key event convention. Sym is an XKB keysym, state a
wl_keyboard key_state. Modifiers are a mask for effective modifiers
(where the modifier indices are set by the modifiers_map event)
   
-- 
1.9.1

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

Re: [PATCH weston] xwayland: Grammar fixes

2016-07-07 Thread Bryce Harrington 
On Thu, Jul 07, 2016 at 01:16:38PM +0100, Eric Engestrom wrote:
> On Wed, Jul 06, 2016 at 03:25:19PM -0700, Bryce Harrington wrote:
> > Signed-off-by: Bryce Harrington 
> > ---
> >  xwayland/xwayland-api.h | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/xwayland/xwayland-api.h b/xwayland/xwayland-api.h
> > index 4be87e5..9a16147 100644
> > --- a/xwayland/xwayland-api.h
> > +++ b/xwayland/xwayland-api.h
> > @@ -63,8 +63,8 @@ struct weston_xwayland_api {
> >  
> > /** Listen for X connections.
> >  *
> > -* This function tells the Xwayland module to start create a X socket
> > -* and to listen for client connections. When one such connection is
> > +* This function tells the Xwayland module to begin creating a X socket
> > +* and start listening for client connections. When one such connection 
> > is
> >  * detected the given \a spawn_func callback will be called to start
> >  * the Xwayland process.
> >  *
> 
> "an X socket", maybe?

Sure, I'll change that one too.  I wondered about that myself.
 
> Either way, your changes are good:
> Reviewed-by: Eric Engestrom 

Thanks very much for the R-b's Eric.

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

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

2016-07-07 Thread Emil Velikov 
On 7 July 2016 at 10:46, Pekka Paalanen  wrote:
> On Mon, 4 Jul 2016 16:25:54 +0100
> Emil Velikov  wrote:
>
>> On 4 July 2016 at 15:35, Quentin Glidic  
>> wrote:
>> > On 04/07/2016 16:23, Emil Velikov wrote:
>> >>
>> >> From: Emil Velikov 
>> >>
>> >> Signed-off-by: Emil Velikov 
>> >> ---
>> >>  configure.ac  | 1 +
>> >>  libweston/libweston.pc.in | 2 +-
>> >>  2 files changed, 2 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/configure.ac b/configure.ac
>> >> index be40f10..46b61ae 100644
>> >> --- a/configure.ac
>> >> +++ b/configure.ac
>> >> @@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
>> >>  AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
>> >>  AC_SUBST([WESTON_VERSION], [weston_version])
>> >>  AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
>> >> +AC_SUBST([LIBWESTON_VERSION],
>> >> [libweston_major_version.libweston_minor_version.libweston_patch_version])
>> >
>> >
>> > That makes packaging a pain. Although the whole libweston (supposedly
>> > parallel-installable) is already a pain.
>> >
>> > When you have a project with a dep on libweston, you’ll have to dig the
>> > weston version because the tarball is versioned as weston.
>> >
>> > I would only do that once (and if) we split libweston and weston to
>> > different repositories.
>> >
>> Yes splitting libweston into separate repo makes sense. Yet I failed
>> to see where the actual pain is - there is a minor annoyance, and devs
>> and/or distro maintainers have learned to deal with a lot nastier
>> things through the years.
>>
>> If anything, having libweston-2 provided by (a future)
>> libweston-1.12.0 tarball/package would make things even more
>> confusing/annoying. That is unless one is planning to say "f**k it,
>> let's decrease the version" upon the split. With the later upsetting a
>> lot of people.
>
> Hi guys,
>
> my 2c again:
>
> I don't think splitting weston and libweston to separate
> repositories can happen any time soon, because of the test suite
> that is specific to weston. I do not want to duplicate the test
> suite, and I do not want 'make check' in libweston to be useless,
> so we need to keep them together for now.
>
If there were more developers, one could also move the tests into a
separate repo. Although that (plus libweston) would require extensive
audit of the private and public headers since atm, things are quite
fragile (one might even call them busted).

> I also think that we don't need separate versioning for weston and
> libweston. Let's just use the same for both, now that the plans are
> clarifying.
>
> Yes, it does mean the following:
>
> - weston version number will start to deviate from wayland, even
>   when both are still released at the same time
>
Don't think this is a serious problem, I've even recall people being
confused why they are still in sync.

> - weston version number will be the same as libweston it uses
>
> - MAJOR will start running like hell, we'll probably get to weston
>   27.0.0 before it slows down, or whatever
>
> But, that's all fine with me, considering the confusion any other
> scheme would raise.
>
> I suppose (lib)weston release 1.12.0 would be last MAJOR=1 release
> of weston, installing libweston-1.so, and then we'd just bump to
> weston 2.0.0 on the next final release.
>
> How's that?
>
This sounds like a good plan to me, fwiw.

> Hmm... but again, if we use MAJOR like that, then during the
> development of 2.0.0 we would be still installing libweston-1.so
> because our version in git master is 1.12.90 until the first
> pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
> How to solve that? Or is it not a problem?
>
> The thing is, libweston 1.12.90 will be completely incompatible
> with libweston 1.12.0.
>
> Should .9x be a special case somehow, installed as
> libweston-1-90.so or such?
>
As mentioned elsewhere - one should not rely on development version of
project foo having stable interface(s). That said, making sure that
things aren't too crazy for people that do want to test them is a must
imho.
Nobody (?) wants to deter their testers away.

> This is starting to sound very much like what I read about GTK
> trying a new versioning scheme...
>
That might be a good idea. Are you talking about [1] [2] ?
Alternatively do you have a link/keywords on the topic ?

"Versionning - there's always more to it than one expects" ;-)

Thanks
Emil

[1] https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
[2] https://blogs.gnome.org/desrt/2016/06/14/gtk-5-0-is-not-gtk-5/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 5/6] libweston: do not add libweston-$version to the Cflags

2016-07-07 Thread Emil Velikov 
On 7 July 2016 at 10:20, Pekka Paalanen  wrote:
> On Mon, 4 Jul 2016 16:02:23 +0100
> Emil Velikov  wrote:
>
>> On 4 July 2016 at 15:32, Quentin Glidic  
>> wrote:
>> > On 04/07/2016 16:23, Emil Velikov wrote:
>> >>
>> >> From: Emil Velikov 
>> >>
>> >> When managing headers there's normally two ways to handle them
>> >> - with or without the subfolder.
>> >>
>> >> Opting for the latter case here, since it will provide direct feedback,
>> >> whether one is using libweston-0 or any other version.
>> >>
>> >> Which in turn should deter (help prevent) issues like building/linking
>> >> against multiple versions of libweston.
>> >>
>> >> Signed-off-by: Emil Velikov 
>> >
>> >
>> > I really prefer not to do that. It means supporting multiple versions of
>> > libweston will lead to a really big #ifdef dance at the top of the file to
>> > include every single version you might support, instead of a just a few
>> > #ifdef around specific new/old functions you use.
>> >
>> Yes, I agree with you - adding ifdef spaghetti is ugly. Then again, if
>> one wants to support multiple versions they will need a bunch of them
>> either way.
>>
>> Keeping things explicit will give (and/or save) you and others a fair
>> bit of time when it goes wrong/nasty. Here is an (somewhat silly, or
>> you might say sad) example I've seen in the open-source Tizen world...
>> or was it Android:
>>
>> Dev. lacks exact knowledge when function A (libfoo1) and B (libfoo2)
>> are introduced. Thus he/she adds both versions of libfoo in the
>> configure pkg-config checks. At which point, you will have symbol
>> collisions, seemingly random corruption and/or crashes.
>
> Hi Emil,
>
> I'm not sure I get that example.
>
> I read the long IRC discussion between the two of you the other
> day, and I have to say I'm on Quentin's side on this, solely because
> switching from one libweston version to the next will cause lots of
> "unnecessary"
+1 for well use of quotation marks :-)

> changes if you need to fix the #include directives
> everywhere. I also do not think doing that mechanical excercise
> will make anyone think about the actual ABI changes.
>
"Anyone" is an overstatement. I might be a minority, but I would make
the effort of checking the API's (I use) in such cases. The whole
example and logic steers on the idea that the greater the effort
required by the user the larger likelihood that they will stop and
think for a second "wait there might be a reason behind all this
annoyance". As said, I'm likely a minority here.

> If we want to make sure users actually notice libweston ABI
> changes, we need to make those as build-breaking API changes too.
> That's the only feasible thing I can think of, unless we had someone
> writing a checklist of all the ABI changes - a fat chance - and
> hoping that downstream devs actually go through it.
>
Yes, it's impossible to make thing completely bullet proof or even get
some (most?) users to read through the changelog. That is unless
things blow up in their face :-)

> Therefore a NAK from me too.
>
As you guys wish. In that case can we drop the pkgincludedir variable
? Most packages don't bother with it (on my local setup only 7 out of
740 do)

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

Re: [PATCH weston 3/6] README: Document versioning scheme, forward compatibility

2016-07-07 Thread Emil Velikov 
On 7 July 2016 at 10:05, Pekka Paalanen  wrote:
> On Wed, 6 Jul 2016 13:57:48 +0100
> Emil Velikov  wrote:
>
>> On 5 July 2016 at 15:46, Pekka Paalanen  wrote:
>> > On Mon,  4 Jul 2016 15:23:51 +0100
>> > Emil Velikov  wrote:
>> >
>> >> From: Emil Velikov 
>> >>
>> >> Signed-off-by: Emil Velikov 
>> >> ---
>> >> Pekka,
>> >>
>> >> There's a couple of things to 'break' - forward and backward
>> >> compatibility.
>> >>
>> >> Latter implies changing (removing) certain existing API, while the
>> >> former is used in reference to functionality introduced with minor
>> >> bumps.
>> >>
>> >> Since people don't always know when the new API is introduced, let alone
>> >> bump the version accordingly in configure (and thus package runtime
>> >> dependency), things end up badly.
>> >>
>> >> In some subtle cases (the autogenerated headers in wayland) not only is
>> >> the new API available, but you end up using it without knowing. And yes,
>> >> I fully agree that approach used in wayland is good, but it can cause
>> >> subtle breakage.
>> >>
>> >> If weston devs don't want this approach (i.e. adding the ifdef guards
>> >> prove too annoying and/or other), then one can just stick with only with
>> >> MAJOR. Then the number will ramp quite fast and user will have no way
>> >> of knowing/detecting bugfix (patch versions).
>> >>
>> >> From my experience, using the LIBWESTON_API_VERSION alike macros does
>> >> not get in the way of development. Yet it's up-to you guys to make the
>> >> call.
>> >>
>> >> -Emil
>> >> ---
>> >>  README | 46 ++
>> >>  1 file changed, 46 insertions(+)
>> >>
>> >> diff --git a/README b/README
>> >> index 126df4d..72e8c7c 100644
>> >> --- a/README
>> >> +++ b/README
>> >> @@ -70,6 +70,52 @@ For more information about parallel installability, see
>> >>  http://ometer.com/parallel.html
>> >>
>> >>
>> >> +Versioning scheme
>> >> +-
>> >> +
>> >> +In order to provide consistent, easy to use versioning, libweston
>> >> +follows the rules in the Apache Portable Runtime Project
>> >> +http://apr.apache.org/versioning.html.
>> >
>> > Hi Emil,
>> >
>> > I read that doc, and I fully agree with it now.
>> >
>> >> +
>> >> +The document provides the full details, with the gist summed below:
>> >> + - Major - backward incompatible changes.
>> >> + - Minor - new backward compatible features.
>> >> + - Patch - internal (implementation specific) fixes.
>> >> +
>> >> +
>> >> +Forward compatibility
>> >> +-
>> >> +
>> >> +In order to ensure prevent subtle breaks with a simple recompile
>> >
>> > Strike "ensure" perhaps?
>> >
>> Yes, well spotted.
>>
>> >> +(against a newer version), features introduced with minor versions are is
>> >> +guarded with a LIBWESTON_API_VERSION guard.
>> >> +
>> >> +For example:
>> >> +Libweston v1.1.0 introduces a new entry point weston_ham_sandwich().
>> >> +As such it will be annotated as below in the relevant header(s).
>> >> +
>> >> +#if LIBWESTON_API_VERSION >= 0x0101
>> >> +
>> >> +bool
>> >> +weston_ham_sandwich(void);
>> >> +
>> >> +#endif
>> >> +
>> >> +As the user requires the said symbol, they must explicitly set the
>> >> +LIBWESTON_API_VERSION macro. By doing so they explicitly state "yes I
>> >> +want to use the said version of the library", at which point they should
>> >> +also bump the version check in their configure (or equivalent) script.
>> >> +
>> >> +The LIBWESTON_API_VERSION is of the format 0x$MAJOR$MINOR and does not
>> >> +include PATCH version. As mentioned in the Versioning scheme section,
>> >> +PATCH does not reflect any user visible API changes, thus should be not
>> >> +considered part of the API VERSION.
>> >> +
>> >> +Similar approach is used by ATK, QT and KDE programs/libraries,
>> >> +libjpeg-turbo, GTK, NetworkManager (in a more complex/compherensive
>> >> +manner), js17, lz4 and many others.
>> >
>> > This is interesting and the very first time I hear about such a scheme.
>> > Obviously I have never used any library that required me to declare
>> > which version I am expecting to use of it at the CPP level.
>> >
>> > Also the APR versioning doc says nothing about it,
>> Neither have I found any reference/docs on the topic sadly.
>>
>> > and I couldn't find
>> > any GTK documentation of a similar mechanism. libjpeg-turbo seems to
>> > have something of the sort indeed, however it also defines
>> > JPEG_LIB_VERSION itself, not the user of the library. I suspect there
>> > is some misunderstanding here. I didn't check the others.
>> >
>> On the libjpeg-turbo front, JPEG_LIB_VERSION is _optionally_ defined
>> and controls only the structs' layout.
>>
>> On the GTK side I've made a typo - it should have been GDK.
>> Here is a snippet from /usr/include/gtk-3.0/gdk/gdkversionmacros.h
>>
>> /**
>>  * GDK_VERSION_MAX_ALLOWED:
>>

[PATCH weston] weston-editor: Close the data source after sending

2016-07-07 Thread Derek Foreman 
We're leaking the fd when sending cut'n'paste.  Failure to close can also
makes the other end unhappy because it doesn't know the paste is finished.

Signed-off-by: Derek Foreman 
---
 clients/editor.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/clients/editor.c b/clients/editor.c
index e081a5b..9daa77f 100644
--- a/clients/editor.c
+++ b/clients/editor.c
@@ -575,6 +575,8 @@ data_source_send(void *data,
 
if (write(fd, editor->selected_text, strlen(editor->selected_text) + 1) 
< 0)
fprintf(stderr, "write failed: %m\n");
+
+   close(fd);
 }
 
 static void
-- 
2.8.1

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

RE: [PATCH weston] libweston: Implement wl_output version 3 (release request)

2016-07-07 Thread Ucan, Emre (ADITG/SW1) 
Hi,

It looks good.

Reviewed-by: Emre Ucan   

Best regards

Emre Ucan
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6937

> -Original Message-
> From: wayland-devel [mailto:wayland-devel-
> boun...@lists.freedesktop.org] On Behalf Of Quentin Glidic
> Sent: Dienstag, 5. Juli 2016 20:45
> To: wayland-devel@lists.freedesktop.org
> Subject: [PATCH weston] libweston: Implement wl_output version 3 (release
> request)
> 
> From: Quentin Glidic 
> 
> Signed-off-by: Quentin Glidic 
> ---
>  libweston/compositor.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/libweston/compositor.c b/libweston/compositor.c
> index 771f1c9..38f78fd 100644
> --- a/libweston/compositor.c
> +++ b/libweston/compositor.c
> @@ -4006,6 +4006,17 @@ weston_compositor_stack_plane(struct
> weston_compositor *ec,
>   wl_list_insert(>plane_list, >link);
>  }
> 
> +static void
> +output_release(struct wl_client *client, struct wl_resource *resource)
> +{
> + wl_resource_destroy(resource);
> +}
> +
> +static const struct wl_output_interface output_interface = {
> + output_release,
> +};
> +
> +
>  static void unbind_resource(struct wl_resource *resource)
>  {
>   wl_list_remove(wl_resource_get_link(resource));
> @@ -4027,7 +4038,7 @@ bind_output(struct wl_client *client,
>   }
> 
>   wl_list_insert(>resource_list,
> wl_resource_get_link(resource));
> - wl_resource_set_implementation(resource, NULL, data,
> unbind_resource);
> + wl_resource_set_implementation(resource, _interface,
> data, unbind_resource);
> 
>   wl_output_send_geometry(resource,
>   output->x,
> @@ -4300,7 +4311,7 @@ weston_output_init(struct weston_output
> *output, struct weston_compositor *c,
>   output->compositor->output_id_pool |= 1u << output->id;
> 
>   output->global =
> - wl_global_create(c->wl_display, _output_interface, 2,
> + wl_global_create(c->wl_display, _output_interface, 3,
>output, bind_output);
>  }
> 
> --
> 2.9.0
> 
> ___
> 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 weston] xwayland: Include missing config.h

2016-07-07 Thread Eric Engestrom 
On Wed, Jul 06, 2016 at 03:14:20PM -0700, Bryce Harrington wrote:
> Signed-off-by: Bryce Harrington 

Indeed, this is needed for XSERVER_PATH
Reviewed-by: Eric Engestrom 

> ---
>  compositor/xwayland.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/compositor/xwayland.c b/compositor/xwayland.c
> index 26eda20..9fa7600 100644
> --- a/compositor/xwayland.c
> +++ b/compositor/xwayland.c
> @@ -24,6 +24,8 @@
>   * SOFTWARE.
>   */
>  
> +#include "config.h"
> +
>  #include 
>  #include 
>  
> -- 
> 1.9.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] xwayland: Cleanup error message on spawn failure Signed-off-by: Bryce Harrington <br...@osg.samsung.com>

2016-07-07 Thread Eric Engestrom 
On Wed, Jul 06, 2016 at 03:18:46PM -0700, Bryce Harrington wrote:
> Signed-off-by: Bryce Harrington 

Reviewed-by: Eric Engestrom 

> ---
>  compositor/xwayland.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/compositor/xwayland.c b/compositor/xwayland.c
> index 9fa7600..9881cd9 100644
> --- a/compositor/xwayland.c
> +++ b/compositor/xwayland.c
> @@ -146,7 +146,7 @@ spawn_xserver(void *user_data, const char *display, int 
> abstract_fd, int unix_fd
>   break;
>  
>   case -1:
> - weston_log( "failed to fork\n");
> + weston_log("Failed to fork to spawn xserver process\n");
>   break;
>   }
>  
> -- 
> 1.9.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] xwayland: Grammar fixes

2016-07-07 Thread Eric Engestrom 
On Wed, Jul 06, 2016 at 03:25:19PM -0700, Bryce Harrington wrote:
> Signed-off-by: Bryce Harrington 
> ---
>  xwayland/xwayland-api.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/xwayland/xwayland-api.h b/xwayland/xwayland-api.h
> index 4be87e5..9a16147 100644
> --- a/xwayland/xwayland-api.h
> +++ b/xwayland/xwayland-api.h
> @@ -63,8 +63,8 @@ struct weston_xwayland_api {
>  
>   /** Listen for X connections.
>*
> -  * This function tells the Xwayland module to start create a X socket
> -  * and to listen for client connections. When one such connection is
> +  * This function tells the Xwayland module to begin creating a X socket
> +  * and start listening for client connections. When one such connection 
> is
>* detected the given \a spawn_func callback will be called to start
>* the Xwayland process.
>*

"an X socket", maybe?

Either way, your changes are good:
Reviewed-by: Eric Engestrom 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] dmabuf: Fix grammar in a comment

2016-07-07 Thread Eric Engestrom 
On Wed, Jul 06, 2016 at 03:30:54PM -0700, Bryce Harrington wrote:
> Signed-off-by: Bryce Harrington 

Reviewed-by: Eric Engestrom 

> ---
>  libweston/linux-dmabuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libweston/linux-dmabuf.c b/libweston/linux-dmabuf.c
> index 78e77a2..a91ae85 100644
> --- a/libweston/linux-dmabuf.c
> +++ b/libweston/linux-dmabuf.c
> @@ -471,7 +471,7 @@ linux_dmabuf_setup(struct weston_compositor *compositor)
>   * In any case, the options are to either composite garbage or nothing,
>   * or disconnect the client. This is a helper function for the latter.
>   *
> - * The error is sent as a INVALID_OBJECT error on the client's wl_display.
> + * The error is sent as an INVALID_OBJECT error on the client's wl_display.
>   *
>   * \param buffer The linux_dmabuf_buffer that is unusable.
>   * \param msg A custom error message attached to the protocol error.
> -- 
> 1.9.1
> 
> ___
> 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 2/2] test: remove NOTPARALLEL

2016-07-07 Thread Peter Hutterer 
We can now run the tests in parallel with make check -j , even though 
results are
mixed: on an i7 here make -j 4 is reliable, on a under-resourced VM running on
an i5 make -j2 is the best I can do, anything higher fails with timeouts
possibly because of the udev lock contention (see 030ec053fbbc).

There is one test in device.test (device_reenable_syspath_changed) that fails
if another device is added/removed at the wrong time and it's reliable to
trigger that failure. The tests are split up into parallel and serial tests,
for the serial tests we have to manually add dependencies to avoid executing
them in parallel with others.

Signed-off-by: Peter Hutterer 
---
I'm not sure if it's a good idea merging this one. I've timed bunch of runs
and a -j1 is north of 30 minutes. make check -j2  is aroudn 13 minutes here,
-j4 is the same. Anything higher tends to cause test case failures because
we're now timing out on some tests. I did an test with a whole lot of forks
and a timeout of a minute and it finished in 20 minutes.

So long story short: .NOTPARALLEL guarantees it will succeeds, albeit not
very quickly. Removing is only reliable-ish on -j2, beyond that it will
likely fail. So that would require custom makeflags for libinput which is
less than ideal. We could add MAKEFLAGS to the environment, but really, I
think it may be better to just leave it as-is.

Either way, patches are now on the list and thus archived for all eternity.

 test/Makefile.am | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/test/Makefile.am b/test/Makefile.am
index acb2de7..4e7a728 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -74,13 +74,12 @@ liblitest_la_LIBADD += $(LIBUNWIND_LIBS) -ldl
 liblitest_la_CFLAGS += $(LIBUNWIND_CFLAGS)
 endif
 
-run_tests = \
+parallel_tests = \
touchpad.test \
touchpad-tap.test \
touchpad-buttons.test \
pad.test \
tablet.test \
-   device.test \
gestures.test \
pointer.test \
touch.test \
@@ -93,6 +92,14 @@ run_tests = \
keyboard.test \
litest-selftest.test
 
+# serial tests require a manual dependency for testname.log, see below
+serial_tests = \
+   device.test
+
+run_tests = \
+   $(parallel_tests) \
+   $(serial_tests)
+
 build_tests = \
build-cxx.test \
build-linker.test \
@@ -103,8 +110,6 @@ noinst_PROGRAMS = $(build_tests) $(run_tests)
 noinst_SCRIPTS = symbols-leak-test
 TESTS = $(run_tests) symbols-leak-test
 
-.NOTPARALLEL:
-
 udev_test_SOURCES = udev.c
 udev_test_LDADD = $(TEST_LIBS)
 udev_test_LDFLAGS = -no-install
@@ -197,6 +202,11 @@ build_cxx_test_CXXFLAGS = -Wall -Wextra 
-Wno-unused-parameter $(AM_CXXFLAGS)
 
 AM_TESTS_ENVIRONMENT= LITEST_VERBOSE=1; export LITEST_VERBOSE;
 
+# serial tests require a manual dependency to avoid parallel execution
+device.log: $(parallel_tests:.test=.log)
+# add any further serial tests as:
+# testname.log: device.log
+
 if HAVE_VALGRIND
 VALGRIND_FLAGS=--leak-check=full \
   --quiet \
-- 
2.7.4

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

[PATCH libinput 1/2] test: use the .test suffix instead of a test- prefix

2016-07-07 Thread Peter Hutterer 
Having a suffix means we can use some automake features that rely on the
suffix

Signed-off-by: Peter Hutterer 
---
 .gitignore   |   2 +-
 test/Makefile.am | 202 +++
 2 files changed, 102 insertions(+), 102 deletions(-)

diff --git a/.gitignore b/.gitignore
index ab5f993..728c11b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,6 +36,6 @@ src/libinput-version.h
 doc/libinput.doxygen
 doc/html
 tags
-test/test-*
+test/*.test
 test/symbols-leak-test*
 test-driver
diff --git a/test/Makefile.am b/test/Makefile.am
index 231165c..acb2de7 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -75,29 +75,29 @@ liblitest_la_CFLAGS += $(LIBUNWIND_CFLAGS)
 endif
 
 run_tests = \
-   test-touchpad \
-   test-touchpad-tap \
-   test-touchpad-buttons \
-   test-pad \
-   test-tablet \
-   test-device \
-   test-gestures \
-   test-pointer \
-   test-touch \
-   test-trackball \
-   test-trackpoint \
-   test-udev \
-   test-path \
-   test-log \
-   test-misc \
-   test-keyboard \
-   test-litest-selftest
+   touchpad.test \
+   touchpad-tap.test \
+   touchpad-buttons.test \
+   pad.test \
+   tablet.test \
+   device.test \
+   gestures.test \
+   pointer.test \
+   touch.test \
+   trackball.test \
+   trackpoint.test \
+   udev.test \
+   path.test \
+   log.test \
+   misc.test \
+   keyboard.test \
+   litest-selftest.test
 
 build_tests = \
-   test-build-cxx \
-   test-build-linker \
-   test-build-pedantic-c99 \
-   test-build-std-gnuc90
+   build-cxx.test \
+   build-linker.test \
+   build-pedantic-c99.test \
+   build-std-gnuc90.test
 
 noinst_PROGRAMS = $(build_tests) $(run_tests)
 noinst_SCRIPTS = symbols-leak-test
@@ -105,95 +105,95 @@ TESTS = $(run_tests) symbols-leak-test
 
 .NOTPARALLEL:
 
-test_udev_SOURCES = udev.c
-test_udev_LDADD = $(TEST_LIBS)
-test_udev_LDFLAGS = -no-install
-
-test_path_SOURCES = path.c
-test_path_LDADD = $(TEST_LIBS)
-test_path_LDFLAGS = -no-install
-
-test_pointer_SOURCES = pointer.c
-test_pointer_LDADD = $(TEST_LIBS)
-test_pointer_LDFLAGS = -no-install
-
-test_touch_SOURCES = touch.c
-test_touch_LDADD = $(TEST_LIBS)
-test_touch_LDFLAGS = -no-install
-
-test_log_SOURCES = log.c
-test_log_LDADD = $(TEST_LIBS)
-test_log_LDFLAGS = -no-install
-
-test_tablet_SOURCES = tablet.c
-test_tablet_LDADD = $(TEST_LIBS)
-test_tablet_LDFLAGS = -static
-
-test_pad_SOURCES = pad.c
-test_pad_LDADD = $(TEST_LIBS)
-test_pad_LDFLAGS = -static
-
-test_touchpad_SOURCES = touchpad.c
-test_touchpad_LDADD = $(TEST_LIBS)
-test_touchpad_LDFLAGS = -no-install
-
-test_touchpad_tap_SOURCES = touchpad-tap.c
-test_touchpad_tap_LDADD = $(TEST_LIBS)
-test_touchpad_tap_LDFLAGS = -no-install
-
-test_touchpad_buttons_SOURCES = touchpad-buttons.c
-test_touchpad_buttons_LDADD = $(TEST_LIBS)
-test_touchpad_buttons_LDFLAGS = -no-install
-
-test_trackpoint_SOURCES = trackpoint.c
-test_trackpoint_LDADD = $(TEST_LIBS)
-test_trackpoint_LDFLAGS = -no-install
-
-test_trackball_SOURCES = trackball.c
-test_trackball_LDADD = $(TEST_LIBS)
-test_trackball_LDFLAGS = -no-install
-
-test_misc_SOURCES = misc.c
-test_misc_CFLAGS= $(AM_CFLAGS) 
-DLIBINPUT_LT_VERSION="\"$(LIBINPUT_LT_VERSION)\""
-test_misc_LDADD = $(TEST_LIBS)
-test_misc_LDFLAGS = -no-install
-
-test_keyboard_SOURCES = keyboard.c
-test_keyboard_LDADD = $(TEST_LIBS)
-test_keyboard_LDFLAGS = -no-install
-
-test_device_SOURCES = device.c
-test_device_LDADD = $(TEST_LIBS)
-test_device_LDFLAGS = -no-install
-
-test_gestures_SOURCES = gestures.c
-test_gestures_LDADD = $(TEST_LIBS)
-test_gestures_LDFLAGS = -no-install
-
-test_litest_selftest_SOURCES = litest-selftest.c litest.c litest-int.h litest.h
-test_litest_selftest_CFLAGS = -DLITEST_DISABLE_BACKTRACE_LOGGING 
-DLITEST_NO_MAIN $(liblitest_la_CFLAGS)
-test_litest_selftest_LDADD = $(TEST_LIBS)
-test_litest_selftest_LDFLAGS = -no-install
+udev_test_SOURCES = udev.c
+udev_test_LDADD = $(TEST_LIBS)
+udev_test_LDFLAGS = -no-install
+
+path_test_SOURCES = path.c
+path_test_LDADD = $(TEST_LIBS)
+path_test_LDFLAGS = -no-install
+
+pointer_test_SOURCES = pointer.c
+pointer_test_LDADD = $(TEST_LIBS)
+pointer_test_LDFLAGS = -no-install
+
+touch_test_SOURCES = touch.c
+touch_test_LDADD = $(TEST_LIBS)
+touch_test_LDFLAGS = -no-install
+
+log_test_SOURCES = log.c
+log_test_LDADD = $(TEST_LIBS)
+log_test_LDFLAGS = -no-install
+
+tablet_test_SOURCES = tablet.c
+tablet_test_LDADD = $(TEST_LIBS)
+tablet_test_LDFLAGS = -static
+
+pad_test_SOURCES = pad.c
+pad_test_LDADD = $(TEST_LIBS)
+pad_test_LDFLAGS = -static
+
+touchpad_test_SOURCES = touchpad.c
+touchpad_test_LDADD = $(TEST_LIBS)
+touchpad_test_LDFLAGS = -no-install
+
+touchpad_tap_test_SOURCES = touchpad-tap.c
+touchpad_tap_test_LDADD = $(TEST_LIBS)
+touchpad_tap_test_LDFLAGS = -no-install
+
+touchpad_buttons_test_SOURCES =

Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

2016-07-07 Thread Pekka Paalanen 
On Mon, 4 Jul 2016 16:25:54 +0100
Emil Velikov  wrote:

> On 4 July 2016 at 15:35, Quentin Glidic  
> wrote:
> > On 04/07/2016 16:23, Emil Velikov wrote:  
> >>
> >> From: Emil Velikov 
> >>
> >> Signed-off-by: Emil Velikov 
> >> ---
> >>  configure.ac  | 1 +
> >>  libweston/libweston.pc.in | 2 +-
> >>  2 files changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index be40f10..46b61ae 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
> >>  AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
> >>  AC_SUBST([WESTON_VERSION], [weston_version])
> >>  AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
> >> +AC_SUBST([LIBWESTON_VERSION],
> >> [libweston_major_version.libweston_minor_version.libweston_patch_version]) 
> >>  
> >
> >
> > That makes packaging a pain. Although the whole libweston (supposedly
> > parallel-installable) is already a pain.
> >
> > When you have a project with a dep on libweston, you’ll have to dig the
> > weston version because the tarball is versioned as weston.
> >
> > I would only do that once (and if) we split libweston and weston to
> > different repositories.
> >  
> Yes splitting libweston into separate repo makes sense. Yet I failed
> to see where the actual pain is - there is a minor annoyance, and devs
> and/or distro maintainers have learned to deal with a lot nastier
> things through the years.
> 
> If anything, having libweston-2 provided by (a future)
> libweston-1.12.0 tarball/package would make things even more
> confusing/annoying. That is unless one is planning to say "f**k it,
> let's decrease the version" upon the split. With the later upsetting a
> lot of people.

Hi guys,

my 2c again:

I don't think splitting weston and libweston to separate
repositories can happen any time soon, because of the test suite
that is specific to weston. I do not want to duplicate the test
suite, and I do not want 'make check' in libweston to be useless,
so we need to keep them together for now.

I also think that we don't need separate versioning for weston and
libweston. Let's just use the same for both, now that the plans are
clarifying.

Yes, it does mean the following:

- weston version number will start to deviate from wayland, even
  when both are still released at the same time

- weston version number will be the same as libweston it uses

- MAJOR will start running like hell, we'll probably get to weston
  27.0.0 before it slows down, or whatever

But, that's all fine with me, considering the confusion any other
scheme would raise.

I suppose (lib)weston release 1.12.0 would be last MAJOR=1 release
of weston, installing libweston-1.so, and then we'd just bump to
weston 2.0.0 on the next final release.

How's that?

Hmm... but again, if we use MAJOR like that, then during the
development of 2.0.0 we would be still installing libweston-1.so
because our version in git master is 1.12.90 until the first
pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
How to solve that? Or is it not a problem?

The thing is, libweston 1.12.90 will be completely incompatible
with libweston 1.12.0.

Should .9x be a special case somehow, installed as
libweston-1-90.so or such?

This is starting to sound very much like what I read about GTK
trying a new versioning scheme...


Thanks,
pq


pgpBTiQFbuFOb.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 5/6] libweston: do not add libweston-$version to the Cflags

2016-07-07 Thread Pekka Paalanen 
On Mon, 4 Jul 2016 16:02:23 +0100
Emil Velikov  wrote:

> On 4 July 2016 at 15:32, Quentin Glidic  
> wrote:
> > On 04/07/2016 16:23, Emil Velikov wrote:  
> >>
> >> From: Emil Velikov 
> >>
> >> When managing headers there's normally two ways to handle them
> >> - with or without the subfolder.
> >>
> >> Opting for the latter case here, since it will provide direct feedback,
> >> whether one is using libweston-0 or any other version.
> >>
> >> Which in turn should deter (help prevent) issues like building/linking
> >> against multiple versions of libweston.
> >>
> >> Signed-off-by: Emil Velikov   
> >
> >
> > I really prefer not to do that. It means supporting multiple versions of
> > libweston will lead to a really big #ifdef dance at the top of the file to
> > include every single version you might support, instead of a just a few
> > #ifdef around specific new/old functions you use.
> >  
> Yes, I agree with you - adding ifdef spaghetti is ugly. Then again, if
> one wants to support multiple versions they will need a bunch of them
> either way.
> 
> Keeping things explicit will give (and/or save) you and others a fair
> bit of time when it goes wrong/nasty. Here is an (somewhat silly, or
> you might say sad) example I've seen in the open-source Tizen world...
> or was it Android:
> 
> Dev. lacks exact knowledge when function A (libfoo1) and B (libfoo2)
> are introduced. Thus he/she adds both versions of libfoo in the
> configure pkg-config checks. At which point, you will have symbol
> collisions, seemingly random corruption and/or crashes.

Hi Emil,

I'm not sure I get that example.

I read the long IRC discussion between the two of you the other
day, and I have to say I'm on Quentin's side on this, solely because
switching from one libweston version to the next will cause lots of
"unnecessary" changes if you need to fix the #include directives
everywhere. I also do not think doing that mechanical excercise
will make anyone think about the actual ABI changes.

If we want to make sure users actually notice libweston ABI
changes, we need to make those as build-breaking API changes too.
That's the only feasible thing I can think of, unless we had someone
writing a checklist of all the ABI changes - a fat chance - and
hoping that downstream devs actually go through it.

Therefore a NAK from me too.


Thanks,
pq


pgp8YiXFOYxyM.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Patch revision logs in commit messages?

2016-07-07 Thread Pekka Paalanen 
On Mon, 4 Jul 2016 17:54:39 +0100
Emil Velikov  wrote:

> On 4 July 2016 at 15:45, Quentin Glidic  
> wrote:
> > On 04/07/2016 16:23, Emil Velikov wrote:  
> >>
> >> Use the documented libweston-$major.so.0.$minor.$patch scheme.
> >>
> >> An (almost) identical one is used by GLIB, GTK{2,3}, QT5, json-glib and
> >> others.
> >>
> >> v2:
> >>  - Use shorter variable names LIBWESTON_{MAJOR,MINOR...}
> >>  - Correctly use -version-info.
> >>  - Drop unneeded @LIBWESTON_VERSION_MAJOR@ additions.
> >>
> >> Signed-off-by: Emil Velikov 
> >> ---
> >>
> >> XXX:
> >>  - Should we rename libweston{,-0}.pc.in ?
> >>  - Drop the s/LIBWESTON_ABI_VERSION/LIBWESTON_MAJOR/ hunk ?
> >>  - Keep the configure libweston_*_version variables shorter ?
> >>  - Yes, the LT_VERSION_INFO hunk looks a bit nasty, yet this is what GTK
> >> is doing, once you unraver the 2-3 layers of variables. It works as
> >> expected though, and I'd imagine others are doing a similar trick.
> >>
> >> fixup! libweston: use new versioning scheme  
> >
> >
> > Looks good. A bit hard to read but I thing you at least build-tested it. :-)
> >
> > I think you can drop the "v2" part in the commit message, btw.
> >  
> I've noticed that other commits keep their revision history above the
> --- line, and thus is present in git log. So I take that it's a nice
> to have, but here it's just useless ?

Hi,

I would tend to err on too much information in the commit message
than too little, so I don't mind at all having the patch revision
log included. It might even answer some questions for a future git
archeologist.


Thanks,
pq


pgpmyduz1oycg.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 3/6] README: Document versioning scheme, forward compatibility

2016-07-07 Thread Pekka Paalanen 
On Wed, 6 Jul 2016 13:57:48 +0100
Emil Velikov  wrote:

> On 5 July 2016 at 15:46, Pekka Paalanen  wrote:
> > On Mon,  4 Jul 2016 15:23:51 +0100
> > Emil Velikov  wrote:
> >  
> >> From: Emil Velikov 
> >>
> >> Signed-off-by: Emil Velikov 
> >> ---
> >> Pekka,
> >>
> >> There's a couple of things to 'break' - forward and backward
> >> compatibility.
> >>
> >> Latter implies changing (removing) certain existing API, while the
> >> former is used in reference to functionality introduced with minor
> >> bumps.
> >>
> >> Since people don't always know when the new API is introduced, let alone
> >> bump the version accordingly in configure (and thus package runtime
> >> dependency), things end up badly.
> >>
> >> In some subtle cases (the autogenerated headers in wayland) not only is
> >> the new API available, but you end up using it without knowing. And yes,
> >> I fully agree that approach used in wayland is good, but it can cause
> >> subtle breakage.
> >>
> >> If weston devs don't want this approach (i.e. adding the ifdef guards
> >> prove too annoying and/or other), then one can just stick with only with
> >> MAJOR. Then the number will ramp quite fast and user will have no way
> >> of knowing/detecting bugfix (patch versions).
> >>
> >> From my experience, using the LIBWESTON_API_VERSION alike macros does
> >> not get in the way of development. Yet it's up-to you guys to make the
> >> call.
> >>
> >> -Emil
> >> ---
> >>  README | 46 ++
> >>  1 file changed, 46 insertions(+)
> >>
> >> diff --git a/README b/README
> >> index 126df4d..72e8c7c 100644
> >> --- a/README
> >> +++ b/README
> >> @@ -70,6 +70,52 @@ For more information about parallel installability, see
> >>  http://ometer.com/parallel.html
> >>
> >>
> >> +Versioning scheme
> >> +-
> >> +
> >> +In order to provide consistent, easy to use versioning, libweston
> >> +follows the rules in the Apache Portable Runtime Project
> >> +http://apr.apache.org/versioning.html.  
> >
> > Hi Emil,
> >
> > I read that doc, and I fully agree with it now.
> >  
> >> +
> >> +The document provides the full details, with the gist summed below:
> >> + - Major - backward incompatible changes.
> >> + - Minor - new backward compatible features.
> >> + - Patch - internal (implementation specific) fixes.
> >> +
> >> +
> >> +Forward compatibility
> >> +-
> >> +
> >> +In order to ensure prevent subtle breaks with a simple recompile  
> >
> > Strike "ensure" perhaps?
> >  
> Yes, well spotted.
> 
> >> +(against a newer version), features introduced with minor versions are is
> >> +guarded with a LIBWESTON_API_VERSION guard.
> >> +
> >> +For example:
> >> +Libweston v1.1.0 introduces a new entry point weston_ham_sandwich().
> >> +As such it will be annotated as below in the relevant header(s).
> >> +
> >> +#if LIBWESTON_API_VERSION >= 0x0101
> >> +
> >> +bool
> >> +weston_ham_sandwich(void);
> >> +
> >> +#endif
> >> +
> >> +As the user requires the said symbol, they must explicitly set the
> >> +LIBWESTON_API_VERSION macro. By doing so they explicitly state "yes I
> >> +want to use the said version of the library", at which point they should
> >> +also bump the version check in their configure (or equivalent) script.
> >> +
> >> +The LIBWESTON_API_VERSION is of the format 0x$MAJOR$MINOR and does not
> >> +include PATCH version. As mentioned in the Versioning scheme section,
> >> +PATCH does not reflect any user visible API changes, thus should be not
> >> +considered part of the API VERSION.
> >> +
> >> +Similar approach is used by ATK, QT and KDE programs/libraries,
> >> +libjpeg-turbo, GTK, NetworkManager (in a more complex/compherensive
> >> +manner), js17, lz4 and many others.  
> >
> > This is interesting and the very first time I hear about such a scheme.
> > Obviously I have never used any library that required me to declare
> > which version I am expecting to use of it at the CPP level.
> >
> > Also the APR versioning doc says nothing about it,  
> Neither have I found any reference/docs on the topic sadly.
> 
> > and I couldn't find
> > any GTK documentation of a similar mechanism. libjpeg-turbo seems to
> > have something of the sort indeed, however it also defines
> > JPEG_LIB_VERSION itself, not the user of the library. I suspect there
> > is some misunderstanding here. I didn't check the others.
> >  
> On the libjpeg-turbo front, JPEG_LIB_VERSION is _optionally_ defined
> and controls only the structs' layout.
> 
> On the GTK side I've made a typo - it should have been GDK.
> Here is a snippet from /usr/include/gtk-3.0/gdk/gdkversionmacros.h
> 
> /**
>  * GDK_VERSION_MAX_ALLOWED:
>  *
>  * A macro that should be defined by the user prior to including
>  * the gdk.h header.
>  * The definition should be one of the predefined GDK version
>  * macros:

Re: [PATCH weston] libweston: Position layers in an absolute way

2016-07-07 Thread Pekka Paalanen 
On Tue, 5 Jul 2016 11:26:52 +0200
Quentin Glidic  wrote:

> On 05/07/2016 11:09, Giulio Camuffo wrote:
> > 2016-07-05 10:15 GMT+02:00 Quentin Glidic 
> > :  
> >> From: Quentin Glidic 
> >>
> >> Currently, layers’ order depends on the module loading order.
> >> With this patch, modules can safely add their own layer at the correct
> >> place.
> >>
> >> Signed-off-by: Quentin Glidic 
> >> ---
> >>  desktop-shell/input-panel.c |  9 +++--
> >>  desktop-shell/shell.c   | 80 
> >> +++--
> >>  fullscreen-shell/fullscreen-shell.c |  3 +-
> >>  ivi-shell/input-panel-ivi.c |  9 +++--
> >>  ivi-shell/ivi-layout.c  |  3 +-
> >>  ivi-shell/ivi-shell.c   |  3 +-
> >>  libweston/compositor.c  | 34 +---
> >>  libweston/compositor.h  | 29 +-
> >>  tests/weston-test.c |  2 +-
> >>  9 files changed, 126 insertions(+), 46 deletions(-)
> >>
> >> [snip]
> >>
> >> +/* Higher value means higher in the stack.
> >> + * Only one module should use the NORMAL value to make sure clients 
> >> surfaces
> >> + * are stacked properly.
> >> + * Other values will stack layers from top to bottom in the order of 
> >> addition,
> >> + * and you should use plugir registry to make surfaces not overlap where
> >> + * relevant. */
> >> +enum weston_layer_position {
> >> +   WESTON_LAYER_POSITION_HIDDEN = 0x, /* special value to 
> >> remove
> >> +   * a layer from the 
> >> list */
> >> +   WESTON_LAYER_POSITION_BACKGROUND = 0x0200,
> >> +   WESTON_LAYER_POSITION_NORMAL = 0x0400,
> >> +   WESTON_LAYER_POSITION_UI = 0x0600,
> >> +   WESTON_LAYER_POSITION_FULLSCREEN = 0x0700,
> >> +   WESTON_LAYER_POSITION_TOP_UI = 0x0800,
> >> +   WESTON_LAYER_POSITION_LOCK   = 0x1000,
> >> +   WESTON_LAYER_POSITION_CURSOR = 0x1200,
> >> +   WESTON_LAYER_POSITION_FADE   = 0x1201,  
> >
> > In orbital i have 10 layers, so these would not be enough. Besides,
> > having to modify libweston everytime i need one more would be a
> > hassle. I understand the problem, but i think it is a weston problem,
> > rather than libweston, and should be something on top, imho.
> >  
> 
> There is room between these values, specifically so you can add your 
> own. No need to modify Weston every time. These are just standard values 
> that plugins can use and developers are aware of, so you can make your 
> own values meaningful wrt these ones.
> 
> These values should be shared between the majority of compositors, so if 
> you have more to add that are meaningful outside of orbital, please share.
> 
> It cannot be a weston problem, IMO, because I really want 
> libweston-based compositors to share as much modules as possible, and 
> these modules could add their layers.
> 
> Cheers,

Hi,

just my personal opinion: using layer priority values as the key
for ordering the layers automatically sounds good to me, so the
idea is Acked-by me.

You just need to improve the documentation to get the idea
clearly across. ;-)


Thanks,
pq


pgp4I_3iyDesb.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel