[PATCH wayland-protocols] input-method: Cleanup some grammar

[Bryce Harrington]

Fix which vs. that, and rephrase a few descriptions to be clearer.

Signed-off-by: Bryce Harrington 
---
 unstable/input-method/input-method-unstable-v1.xml | 25 +++---
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/unstable/input-method/input-method-unstable-v1.xml 
b/unstable/input-method/input-method-unstable-v1.xml
index e9d93ba..e454a55 100644
--- a/unstable/input-method/input-method-unstable-v1.xml
+++ b/unstable/input-method/input-method-unstable-v1.xml
@@ -39,7 +39,7 @@
   commit_state request and are used by the input method to indicate
   the known text input state in events like preedit_string, commit_string,
   and keysym. The text input can then ignore events from the input method
-  which are based on an outdated state (for example after a reset).
+  that are based on an outdated state (for example after a reset).
 
   Warning! The protocol described in this file is experimental and
   backward incompatible changes may be made. Backward compatible changes
@@ -55,11 +55,11 @@
 
 
   
-   Send the commit string text for insertion to the application.
+   Send the commit string text to the application for insertion.
 
-   The text to commit could be either just a single character after a key
-   press or the result of some composing (pre-edit). It could be also an
-   empty text when some text should be removed (see
+   The text could be a single character corresponding to an ordinary key
+   press, one or more characters forming the result of a compose action
+   (pre-edit), or no characters such as when text should be removed (see
delete_surrounding_text) or when the input cursor should be moved (see
cursor_position).
 
@@ -86,10 +86,11 @@
 
 
   
-   Set the styling information on composing text. The style is applied for
-   length in bytes from index relative to the beginning of
-   the composing text (as byte offset). Multiple styles can
-   be applied to a composing text.
+   Set the styling information on a section of the composing text
+   offset index bytes from the beginning and ending at length
+   bytes.
+
+   Multiple styles can be applied to a composing text.
 
This request should be sent before sending a preedit_string request.
   
@@ -100,7 +101,7 @@
 
 
   
-   Set the cursor position inside the composing text (as byte offset)
+   Set the cursor position inside the composing text (as a byte offset)
relative to the start of the composing text.
 
When index is negative no cursor should be displayed.
@@ -245,13 +246,13 @@
   An input method object is responsible for composing text in response to
   input from hardware or virtual keyboards. There is one input method
   object per seat. On activate there is a new input method context object
-  created which allows the input method to communicate with the text input.
+  created that allows the input method to communicate with the text input.
 
 
 
   
A text input was activated. Creates an input method context object
-   which allows communication with the text input.
+   that allows communication with the text input.
   
   
 
-- 
1.9.1

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

[PATCH wayland-protocols] idle-inhibit: Lead with a verb in request description

[Bryce Harrington]

Signed-off-by: Bryce Harrington 
---
 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml 
b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
index 70372fc..9c06cdc 100644
--- a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
+++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
@@ -42,7 +42,7 @@
 
 
   
-   This destroys the inhibit manager.
+   Destroy the inhibit manager.
   
 
 
@@ -75,7 +75,7 @@
 
 
   
-   This removes the inhibitor effect from the associated wl_surface.
+   Remove the inhibitor effect from the associated wl_surface.
   
 
 
-- 
1.9.1

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

[PATCH wayland 2/4] wl_array: Set data to null after free

[Yong Bakos]

From: Yong Bakos 

Explicitly set the data member to NULL during wl_array_release, preventing the
dangling pointer but, more importantly, making it testable.

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

diff --git a/src/wayland-util.c b/src/wayland-util.c
index 639ccf8..2efb133 100644
--- a/src/wayland-util.c
+++ b/src/wayland-util.c
@@ -102,6 +102,7 @@ WL_EXPORT void
 wl_array_release(struct wl_array *array)
 {
free(array->data);
+   array->data = NULL;
 }
 
 WL_EXPORT void *
-- 
2.7.2

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

[PATCH wayland 3/4] tests: Test wl_array_release

[Yong Bakos]

From: Yong Bakos 

array-test.c did not cover wl_array_release, so add one test that specifically
tests this method.

Signed-off-by: Yong Bakos 
---
 tests/array-test.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/tests/array-test.c b/tests/array-test.c
index fe53240..a5856fd 100644
--- a/tests/array-test.c
+++ b/tests/array-test.c
@@ -45,6 +45,16 @@ TEST(array_init)
}
 }
 
+TEST(array_release)
+{
+   struct wl_array array;
+   wl_array_init();
+   array.data = calloc(1, sizeof(int));
+   assert(array.data != NULL);
+   wl_array_release();
+   assert(array.data == NULL);
+}
+
 TEST(array_add)
 {
struct mydata {
-- 
2.7.2

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

[PATCH wayland 0/4] wl_array: documentation and test

[Yong Bakos]

From: Yong Bakos 

This series adds documentation to wl_array and its methods. You can ignore the
warning during documentation building; it is caused by a reference to
`wl_list_for_each`, which is anticipated in a separate patch (up for review).

There is one implementation change: setting the `data` pointer to NULL after
free, in wl_array_release. I did not set `size` and `alloc` to 0, in order to
keep the change miniminal. I do think it would would be better to set them to 0,
rather than document that `wl_array_release` leaves the wl_array in an invalid
state.

Regards,
yong

Yong Bakos (4):
  util: Document wl_array
  wl_array: Set data to null after free
  tests: Test wl_array_release
  array-test: Include wayland-util.h and simplify init test

 src/wayland-util.c |  1 +
 src/wayland-util.h | 66 +-
 tests/array-test.c | 28 ---
 3 files changed, 77 insertions(+), 18 deletions(-)

--
2.7.2

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

[PATCH wayland 4/4] array-test: Include wayland-util.h and simplify init test

[Yong Bakos]

From: Yong Bakos 

Include wayland-util.h instead of wayland-private.h, because that's where
wl_array is and nothing in wayland-private.h is required.

Remove the useless repeated testing of wl_array_init, because if it fails once
out of thousands of iterations we're all doomed anyway.

Signed-off-by: Yong Bakos 
---
 tests/array-test.c | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/tests/array-test.c b/tests/array-test.c
index a5856fd..4aaf041 100644
--- a/tests/array-test.c
+++ b/tests/array-test.c
@@ -25,24 +25,16 @@
 
 #include 
 #include 
-#include "wayland-private.h"
+#include "wayland-util.h"
 #include "test-runner.h"
 
 TEST(array_init)
 {
-   const int iterations = 4122; /* this is arbitrary */
-   int i;
-
-   /* Init array an arbitray amount of times and verify the
-* defaults are sensible. */
-
-   for (i = 0; i < iterations; i++) {
-   struct wl_array array;
-   wl_array_init();
-   assert(array.size == 0);
-   assert(array.alloc == 0);
-   assert(array.data == 0);
-   }
+   struct wl_array array;
+   wl_array_init();
+   assert(array.size == 0);
+   assert(array.alloc == 0);
+   assert(array.data == 0);
 }
 
 TEST(array_release)
-- 
2.7.2

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

[PATCH wayland 1/4] util: Document wl_array

[Yong Bakos]

From: Yong Bakos 

Add doxygen comments for wl_array and its methods.

Signed-off-by: Yong Bakos 
---
 src/wayland-util.h | 66 +-
 1 file changed, 61 insertions(+), 5 deletions(-)

diff --git a/src/wayland-util.h b/src/wayland-util.h
index cacc122..fe0507c 100644
--- a/src/wayland-util.h
+++ b/src/wayland-util.h
@@ -206,29 +206,85 @@ wl_list_insert_list(struct wl_list *list, struct wl_list 
*other);
 pos = tmp, \
 tmp = wl_container_of(pos->member.prev, tmp, member))
 
+/**
+ * \class wl_array
+ *
+ * Dynamic array
+ *
+ */
 struct wl_array {
size_t size;
size_t alloc;
void *data;
 };
 
-#define wl_array_for_each(pos, array)  \
-   for (pos = (array)->data;   \
-(const char *) pos < ((const char *) (array)->data + 
(array)->size); \
-(pos)++)
-
+/**
+ * Initializes the array.
+ *
+ * \param array Array to initialize
+ *
+ * \memberof wl_array
+ */
 void
 wl_array_init(struct wl_array *array);
 
+/**
+ * Releases the array data.
+ *
+ * \note Leaves the array in an invalid state.
+ *
+ * \param array Array whose data is to be released
+ *
+ * \memberof wl_array
+ */
 void
 wl_array_release(struct wl_array *array);
 
+/**
+ * Increases the size of the array by \p size bytes.
+ *
+ * \param array Array whose size is to be increased
+ * \param size Number of bytes to increase the size of the array by
+ *
+ * \return A pointer to the beginning of the newly appended space, or NULL when
+ * resizing fails.
+ *
+ * \memberof wl_array
+ */
 void *
 wl_array_add(struct wl_array *array, size_t size);
 
+/**
+ * Copies the contents of \p source to \p array.
+ *
+ * \param array Destination array to copy to
+ * \param source Source array to copy from
+ *
+ * \return 0 on success, or -1 on failure
+ *
+ * \memberof wl_array
+ */
 int
 wl_array_copy(struct wl_array *array, struct wl_array *source);
 
+/**
+ * Iterates over an array.
+ *
+ * This macro expresses a for-each iterator for wl_array. It assigns each
+ * element in the list to \p pos, which can then be referenced in a trailing
+ * code block.
+ *
+ * \param pos Cursor that each array element will be assigned to
+ * \param array Array to iterate over
+ *
+ * \relates wl_array
+ * \sa wl_list_for_each()
+ */
+#define wl_array_for_each(pos, array)  \
+   for (pos = (array)->data;   \
+(const char *) pos < ((const char *) (array)->data + 
(array)->size); \
+(pos)++)
+
 typedef int32_t wl_fixed_t;
 
 static inline double
-- 
2.7.2

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

Re: [PATCH wayland-web] Drop the ubuntu 12.04 build directions.

[Yong Bakos]

On Sep 16, 2016, at 2:29 PM, Bryce Harrington  wrote:
> 
> It is unlikely anyone still needs directions on how to install on this
> old distro -- Ubuntu 12.04 is scheduled to hit end-of-life this April.
> 
> Further, no developers (to my knowledge) still test on 12.04, so the
> directions have likely bitrotted anyway.  (Bill had a machine running
> 12.04 and was keeping the page updated, but last March indicated in
> 4fa80f28 he is no longer testing on it.  I myself moved off 12.04 some
> time ago as well.)
> 
> For the most part, the directions are requiring a nearly full build of
> the stack from source, thus is rather duplicative of the generic Wayland
> build directions (which are more actively maintained).  Only a handful
> of lower level X packages and some compiler tools are used from the
> system.
> 
> Signed-off-by: Bryce Harrington 

It's old stuff, so...

Reviewed-by: Yong Bakos 

yong


> ---
> building.html|   3 -
> ubuntu12.04.html | 306 ---
> 2 files changed, 309 deletions(-)
> delete mode 100644 ubuntu12.04.html
> 
> diff --git a/building.html b/building.html
> index 22838dd..34663e3 100644
> --- a/building.html
> +++ b/building.html
> @@ -54,9 +54,6 @@ Ubuntu 16.04. May be useful for any Debian-derived 
> system.
> Building Weston and XWayland on
> Linux Mint 17, which is derived from Ubuntu 14.04.
> 
> -Building Weston and XWayland on
> -Ubuntu 12.04. May be useful for any Debian-derived system.
> -
> For building Weston for http://www.raspberrypi.org/;>Raspberry
> Pi, follow the normal build guide after checking out the
> https://dri.freedesktop.org/wiki/VC4/;>FOSS drivers, and use
> diff --git a/ubuntu12.04.html b/ubuntu12.04.html
> deleted file mode 100644
> index e79dc83..000
> --- a/ubuntu12.04.html
> +++ /dev/null
> @@ -1,306 +0,0 @@
> - "http://www.w3.org/TR/html4/strict.dtd;>
> -
> -
> -
> -
> -
> -Building Weston on Ubuntu 12.04
> -
> -
> -
> -
> -Building Weston on Ubuntu 12.04
> -
> -The following sequence of commands successfully built Weston and
> -XWayland on an Ubuntu 12.04 LTS system, on October 29 2014. This system had
> -previously been used to compile Xlib programs, and thus already had
> -some dependencies (such as git, the compiler, and X11 header files)
> -installed. The commands have been updated for recent versions of
> -Wayland but not tested.
> -
> -This is about the oldest version of Linux which can compile Weston.
> -Newer Linux distributions should require fewer things to be compiled
> -from git.
> -
> -Conversely, newer versions of the code, in particular Mesa, will
> -probably require more dependencies than shown here.
> -
> -
> -# setup environment for local install:
> -export WLD=$HOME/install
> -export LD_LIBRARY_PATH=$WLD/lib
> -export PKG_CONFIG_PATH=$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/
> -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
> -
> -# dependencies for libwayland:
> -sudo apt-get install doxygen xmlto # or use 
> --disable-documentation
> -sudo apt-get install libxml2-dev
> -
> -# expat with pkg-config needed for libwayland:
> -wget 
> http://downloads.sourceforge.net/project/expat/expat/2.1.0/expat-2.1.0.tar.gz
> -tar xzf expat-2.1.0.tar.gz
> -cd expat-2.1.0
> -./configure --prefix=$WLD
> -make  make install
> -cd ..
> -
> -# libwayland-*:
> -git clone git://anongit.freedesktop.org/wayland/wayland
> -cd wayland
> -./autogen.sh --prefix=$WLD
> -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 ..
> -
> -# dependencies for Mesa:
> -# "sudo apt-get build-dep mesa" will install these, but will also
> -# install unwanted items, such as wayland itself, and xcb prototypes
> -# that are too old.
> -sudo apt-get install autoconf automake bison debhelper dpkg-dev flex \
> -  libudev-dev libx11-dev libx11-xcb-dev \
> -  libxdamage-dev libxext-dev libxfixes-dev libxxf86vm-dev \
> -  linux-libc-dev pkg-config python-libxml2 quilt x11proto-dri2-dev \
> -  x11proto-gl-dev xutils-dev
> -
> -# Mesa required llvm-3.1, but newer versions are 
> available.
> -# "apt-cache search 'llvm-[0-9.]*-dev'" will list them
> -sudo apt-get install llvm-3.1-dev
> -sudo ln -sf llvm-config-3.1 /usr/bin/llvm-config
> -
> -sudo apt-get install libpciaccess-dev # needed by 
> drm
> -git clone git://anongit.freedesktop.org/git/mesa/drm
> -cd drm
> -./autogen.sh --prefix=$WLD
> -make  make install
> -cd ..
> -
> -# needed by libxcb:
> -git clone git://anongit.freedesktop.org/xcb/proto
> -cd proto
> -./autogen.sh --prefix=$WLD
> -make  make install
> -cd ..
> -
> -# needed by libxcb:
> -git clone git://anongit.freedesktop.org/xorg/util/macros
> -cd 

[PATCH wayland-web] Drop the ubuntu 12.04 build directions.

[Bryce Harrington]

It is unlikely anyone still needs directions on how to install on this
old distro -- Ubuntu 12.04 is scheduled to hit end-of-life this April.

Further, no developers (to my knowledge) still test on 12.04, so the
directions have likely bitrotted anyway.  (Bill had a machine running
12.04 and was keeping the page updated, but last March indicated in
4fa80f28 he is no longer testing on it.  I myself moved off 12.04 some
time ago as well.)

For the most part, the directions are requiring a nearly full build of
the stack from source, thus is rather duplicative of the generic Wayland
build directions (which are more actively maintained).  Only a handful
of lower level X packages and some compiler tools are used from the
system.

Signed-off-by: Bryce Harrington 
---
 building.html|   3 -
 ubuntu12.04.html | 306 ---
 2 files changed, 309 deletions(-)
 delete mode 100644 ubuntu12.04.html

diff --git a/building.html b/building.html
index 22838dd..34663e3 100644
--- a/building.html
+++ b/building.html
@@ -54,9 +54,6 @@ Ubuntu 16.04. May be useful for any Debian-derived 
system.
 Building Weston and XWayland on
 Linux Mint 17, which is derived from Ubuntu 14.04.
 
-Building Weston and XWayland on
-Ubuntu 12.04. May be useful for any Debian-derived system.
-
 For building Weston for http://www.raspberrypi.org/;>Raspberry
 Pi, follow the normal build guide after checking out the
 https://dri.freedesktop.org/wiki/VC4/;>FOSS drivers, and use
diff --git a/ubuntu12.04.html b/ubuntu12.04.html
deleted file mode 100644
index e79dc83..000
--- a/ubuntu12.04.html
+++ /dev/null
@@ -1,306 +0,0 @@
-http://www.w3.org/TR/html4/strict.dtd;>
-
-
-
-
-
-Building Weston on Ubuntu 12.04
-
-
-
-
-Building Weston on Ubuntu 12.04
-
-The following sequence of commands successfully built Weston and
-XWayland on an Ubuntu 12.04 LTS system, on October 29 2014. This system had
-previously been used to compile Xlib programs, and thus already had
-some dependencies (such as git, the compiler, and X11 header files)
-installed. The commands have been updated for recent versions of
-Wayland but not tested.
-
-This is about the oldest version of Linux which can compile Weston.
-Newer Linux distributions should require fewer things to be compiled
-from git.
-
-Conversely, newer versions of the code, in particular Mesa, will
-probably require more dependencies than shown here.
-
-
-# setup environment for local install:
-export WLD=$HOME/install
-export LD_LIBRARY_PATH=$WLD/lib
-export PKG_CONFIG_PATH=$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/
-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
-
-# dependencies for libwayland:
-sudo apt-get install doxygen xmlto # or use 
--disable-documentation
-sudo apt-get install libxml2-dev
-
-# expat with pkg-config needed for libwayland:
-wget 
http://downloads.sourceforge.net/project/expat/expat/2.1.0/expat-2.1.0.tar.gz
-tar xzf expat-2.1.0.tar.gz
-cd expat-2.1.0
-./configure --prefix=$WLD
-make  make install
-cd ..
-
-# libwayland-*:
-git clone git://anongit.freedesktop.org/wayland/wayland
-cd wayland
-./autogen.sh --prefix=$WLD
-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 ..
-
-# dependencies for Mesa:
-# "sudo apt-get build-dep mesa" will install these, but will also
-# install unwanted items, such as wayland itself, and xcb prototypes
-# that are too old.
-sudo apt-get install autoconf automake bison debhelper dpkg-dev flex \
-  libudev-dev libx11-dev libx11-xcb-dev \
-  libxdamage-dev libxext-dev libxfixes-dev libxxf86vm-dev \
-  linux-libc-dev pkg-config python-libxml2 quilt x11proto-dri2-dev \
-  x11proto-gl-dev xutils-dev
-
-# Mesa required llvm-3.1, but newer versions are 
available.
-# "apt-cache search 'llvm-[0-9.]*-dev'" will list them
-sudo apt-get install llvm-3.1-dev
-sudo ln -sf llvm-config-3.1 /usr/bin/llvm-config
-
-sudo apt-get install libpciaccess-dev # needed by 
drm
-git clone git://anongit.freedesktop.org/git/mesa/drm
-cd drm
-./autogen.sh --prefix=$WLD
-make  make install
-cd ..
-
-# needed by libxcb:
-git clone git://anongit.freedesktop.org/xcb/proto
-cd proto
-./autogen.sh --prefix=$WLD
-make  make install
-cd ..
-
-# needed by libxcb:
-git clone git://anongit.freedesktop.org/xorg/util/macros
-cd macros
-./autogen.sh --prefix=$WLD
-make  make install
-cd ..
-
-git clone git://anongit.freedesktop.org/xcb/libxcb
-cd libxcb
-./autogen.sh --prefix=$WLD
-make  make install
-cd ..
-
-git clone git://anongit.freedesktop.org/xorg/proto/presentproto
-cd presentproto
-./autogen.sh --prefix=$WLD
-make  make install
-cd ..
-
-git clone git://anongit.freedesktop.org/xorg/proto/dri3proto
-cd dri3proto
-./autogen.sh --prefix=$WLD
-make  make install

Re: [PATCH wayland 0/4] Untangle the symbol export duplication

[Pekka Paalanen]

On Fri, 16 Sep 2016 14:47:39 +0100
Emil Velikov  wrote:

> Hi Pekka,
> 
> Thanks again for keeping up.
> 
> On 16 September 2016 at 10:46, Pekka Paalanen  wrote:
> > Hi,
> >
> > there seems to be two different issues discussed here.
> >  
> You cought me, yes there are.
> 
> > 1) libwayland-client and libwayland-server export the same interface
> > symbols each, and cannot stop exporting them. You proposed to
> > consolidate them into a third library.
> >
> > I don't think that is necessary.
> >
> > 2) Push everyone to build and install a .so and generated headers for
> > every protocol extension XML file they offer for public use. You claim
> > it would have benefits over the static build approach.

Hi

> > All such libraries would be ignored by all other language bindings.
> > Language bindings have their own scanners generating wrappers suitable
> > for their language directly. The symbols we are talking about are just
> > a curiosity of the C language bindings.
> >  
> NB: other languages can reuse C binding, no ? Obviously they can use
> the native ones as well.

They can build on C bindings with great effort and pain, something which
they usually prefer to avoid, and upstream discourages. They cannot
build on the C bindings without writing a specific shim library in C or
maybe C++.


> There's more to it - you're suggesting to hide them by default (the
> non libwayland ones of course). I'm saying that one should keep them
> around (in alternative form) by default and allow people to hide them.

Right. It certainly took hours and hours of debate to get to this
sentence that finally explains what the big issue was.


> >> Similar to libwayland-util.so, any old and new projects will continue
> >> to work and the symbol duplication will be resolved.  
> >
> > You only resolve the duplication between libwayland-server and
> > libwayland-client, which has never been a problem heard about in
> > upstream. The symbols exported by them are identical, so it does not
> > matter which one provides them.
> >  
> The "don't provide duplicate symbols" rule/suggestion/etc. is there
> for a reason.
> 
> Just because in this particular place (project) and time those have
> identical implementation there is no guarantee that things will stay
> the same.

The fundamental architecture of libwayland requires them to be
identical. This has been enshrined in the ABI.


> IIRC it carries the XML only for the client header, yet it depends on
> libEGL.so. And yes, they _expect_ to have a cannonical provider for
> the _interface symbol(s). It's only fair to assume that they're not
> the only ones (but perhaps for other _interface symbols).

EGADS, libva is even more insane than I could have ever imagined.

So, you say that we can never stop Mesa from exporting
wl_drm_interface. Too bad.


> The reluctance on the topic strikes me, bth:
>  - Nobody is expecting you/others to hack on this. Fwiw we're talking
> about ~20 loc for wayland.
>  - The proposal preserves your suggestion, yet it is not the default option.
>  - New projects will continue to work as before with zero changes and
> they can opt for either new 'route'.
>  - And last but not least, it preserves ABI compat and mitigates
> existing and future problems.

You want people who did it right to go fix their code.
I want people who did it wrong to go fix their code.

I think that pretty much sums it up. Unfortunately I cannot see any way
around it either. People who did it right will need to pay the price.
I'm starting to recall lots of precedence of that too. I have been in
denial and the world is a much darker place than I remembered.

I still do not want the proliferation of DSOs.

Wait, didn't you or someone clean up Mesa's exports in the past?


Thanks,
pq


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

Re: [PATCH libxkbcommon 2/2] README: Add basic build directions

[Bryce Harrington]

On Fri, Sep 16, 2016 at 09:35:09AM +0300, Ran Benita wrote:
> On Thu, Sep 15, 2016 at 02:31:55PM -0700, Bryce Harrington wrote:
> > In particular, highlight the use of configure flags to control locating
> > X11 keyboard stuff when building for Wayland.
> > 
> > Of particular note, if the locale root is not specified, then xkbcommon
> > will look for them under $prefix (i.e. /usr/local/share/X11/locale).
> > But unless the user has specifically installed them there, it is better
> > to look in the standard system location, /usr/share/X11/locale.
> > 
> > Otherwise, xkbcommon will error when it can't find them, e.g.:
> > 
> >   xkbcommon: ERROR: ~/.XCompose:4:9: failed to expand %L to the locale 
> > Compose file
> >   xkbcommon: ERROR: ~/.XCompose:4:12: unterminated string literal
> > 
> > Signed-off-by: Bryce Harrington 
> 
> I applied these two as well, thanks!

Thanks.
 
> BTW: The xkb-config-root is usually taken from the xkeyboard-config
> pkg-config file, so it's usually not problematic if you have
> xkeyboard-config installed during the build.
> 
> The x-locale-root is more unfortunate since libX11 does not provide a
> pkg-config variable for it. IIRC I tried to add one (and even split the
> x-locale stuff to a different repo since the Compose data is useful for
> other projects well), but it was ignored... Hopefully distros can split
> the libX11 package themselves though.

Yeah, you're right, it would be cleaner if that were split out as a
separate package (or moved to xkbcommon).  This workaround is ok for
now, assuming most people still have X11 installed in parallel, but for
folks wanting to run pure-Wayland setups if they want compose keys too,
having the compose config data only available via libX11 will be a
little awkward.

Bryce

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

Re: [PATCH wayland v1 1/1] wayland-scanner.pc.in: prepend pc_sysrootdir

[Joe Konno]

On Fri, 16 Sep 2016 17:30:18 +0200
Arnaud Vrac  wrote:

> On Fri, Sep 16, 2016 at 5:19 PM, Joe Konno 
> wrote:
> 
> > On Fri, 16 Sep 2016 10:53:32 +0300
> > Pekka Paalanen  wrote:
> >  
> > > On Thu, 15 Sep 2016 15:22:12 -0700
> > > Joe Konno  wrote:
> > >  
> > > > From: Joe Konno 
> > > >
> > > > In a cross-compilation environment with packages depending on
> > > > wayland-scanner, ensure the path to wayland-scanner is correct. Without
> > > > this patch, the path will _not_ point to the target environment but to
> > > > the host's, potentially leading to breakage.
> > > >
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=97828
> > > >
> > > > Signed-off-by: Joe Konno 
> > > > ---
> > > >  src/wayland-scanner.pc.in | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/wayland-scanner.pc.in b/src/wayland-scanner.pc.in
> > > > index 7b2a4c92e0e3..ec11a0bc982c 100644
> > > > --- a/src/wayland-scanner.pc.in
> > > > +++ b/src/wayland-scanner.pc.in
> > > > @@ -2,7 +2,7 @@ prefix=@prefix@
> > > >  exec_prefix=@exec_prefix@
> > > >  datarootdir=@datarootdir@
> > > >  pkgdatadir=@datadir@/@PACKAGE@
> > > > -wayland_scanner=@bindir@/wayland-scanner
> > > > +wayland_scanner=${pc_sysrootdir}/@bindir@/wayland-scanner
> > > >
> > > >  Name: Wayland Scanner
> > > >  Description: Wayland scanner  
> > >
> > > Hi,
> > >
> > > ok, so pc_sysrootdir points to the sysroot. I would just like to
> > > confirm that this really does what you intend. wayland-scanner is a
> > > build tool to be run on the host. Such tools get installed into the
> > > sysroot even when compiled for the host, not the target, yes?
> > >
> > > I read both http://dev.gentoo.org/~mgorny/pkg-config-spec.html and
> > > https://autotools.io/pkgconfig/cross-compiling.html but couldn't
> > > actually understand what is going on, perhaps because I never
> > > cross-compile.
> > >
> > > Hence I cannot offer a Reviewed-by, but I can offer:
> > > Acked-by: Pekka Paalanen 
> > >
> > > (Not for the 1.12.0 release.)
> > >
> > > Are you using binary-compatible arches for both host and target? I'd
> > > like to see a test on a setup where the binaries are completely
> > > incompatible so that the host != target difference is obvious.  
> >
> > I'm struggling with this particular cross-compilation scenario as well, as
> > there's a fair bit of wonky overhead involved in the build process I'm
> > dealing
> > with. Figured I'd introduce the patch and solicit feedback early while I
> > continue digging.
> >
> > Your points are fair and the feedback's appreciated. I'll see about testing
> > this out a bit more with an incompatible binary target-- right now my host
> > is
> > Intel-based and my target is also Intel-based.
> >
> > I'll reply back once I feel convinced one way or the other. ^_^
> >  
> 
> Hi Joe,
> 
> I believe your patch is not right, as pq says the sysroot normally contains
> the code compiled for the target, which might not be compatible with the
> host.
> 
> I think the proper way to do this is to compile wayland for the host
> separately, and use ${CHOST}-pkg-config instead of pkg-config to get the
> wayland-scanner path. In practice you would call
> x86_64-linux-gnu-pkg-config --variable=wayland_scanner. The
> x86_64-linux-gnu-pkg-config utility will look for pkgconfig files in the
> host sysroot, instead of the target sysroot, allowing this use case to work.
> 
> Unfortunately not many packages do this correctly...
> 
> Regards,
> Arnaud

Thanks a mil, Arnaud. I appreciate your feedback. Some of my observations are
making more sense now, and I'm increasingly convinced this patch I submitted
isn't the solution Wayland's looking for (or needs).

Apologies for cluttering the list, Pekka and folks. I don't think this patch
as-is should be considered for inclusion.

Cheers, and thanks again!


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

Re: [PATCH wayland v1 1/1] wayland-scanner.pc.in: prepend pc_sysrootdir

[Arnaud Vrac]

On Fri, Sep 16, 2016 at 5:19 PM, Joe Konno 
wrote:

> On Fri, 16 Sep 2016 10:53:32 +0300
> Pekka Paalanen  wrote:
>
> > On Thu, 15 Sep 2016 15:22:12 -0700
> > Joe Konno  wrote:
> >
> > > From: Joe Konno 
> > >
> > > In a cross-compilation environment with packages depending on
> > > wayland-scanner, ensure the path to wayland-scanner is correct. Without
> > > this patch, the path will _not_ point to the target environment but to
> > > the host's, potentially leading to breakage.
> > >
> > > https://bugs.freedesktop.org/show_bug.cgi?id=97828
> > >
> > > Signed-off-by: Joe Konno 
> > > ---
> > >  src/wayland-scanner.pc.in | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/src/wayland-scanner.pc.in b/src/wayland-scanner.pc.in
> > > index 7b2a4c92e0e3..ec11a0bc982c 100644
> > > --- a/src/wayland-scanner.pc.in
> > > +++ b/src/wayland-scanner.pc.in
> > > @@ -2,7 +2,7 @@ prefix=@prefix@
> > >  exec_prefix=@exec_prefix@
> > >  datarootdir=@datarootdir@
> > >  pkgdatadir=@datadir@/@PACKAGE@
> > > -wayland_scanner=@bindir@/wayland-scanner
> > > +wayland_scanner=${pc_sysrootdir}/@bindir@/wayland-scanner
> > >
> > >  Name: Wayland Scanner
> > >  Description: Wayland scanner
> >
> > Hi,
> >
> > ok, so pc_sysrootdir points to the sysroot. I would just like to
> > confirm that this really does what you intend. wayland-scanner is a
> > build tool to be run on the host. Such tools get installed into the
> > sysroot even when compiled for the host, not the target, yes?
> >
> > I read both http://dev.gentoo.org/~mgorny/pkg-config-spec.html and
> > https://autotools.io/pkgconfig/cross-compiling.html but couldn't
> > actually understand what is going on, perhaps because I never
> > cross-compile.
> >
> > Hence I cannot offer a Reviewed-by, but I can offer:
> > Acked-by: Pekka Paalanen 
> >
> > (Not for the 1.12.0 release.)
> >
> > Are you using binary-compatible arches for both host and target? I'd
> > like to see a test on a setup where the binaries are completely
> > incompatible so that the host != target difference is obvious.
>
> I'm struggling with this particular cross-compilation scenario as well, as
> there's a fair bit of wonky overhead involved in the build process I'm
> dealing
> with. Figured I'd introduce the patch and solicit feedback early while I
> continue digging.
>
> Your points are fair and the feedback's appreciated. I'll see about testing
> this out a bit more with an incompatible binary target-- right now my host
> is
> Intel-based and my target is also Intel-based.
>
> I'll reply back once I feel convinced one way or the other. ^_^
>

Hi Joe,

I believe your patch is not right, as pq says the sysroot normally contains
the code compiled for the target, which might not be compatible with the
host.

I think the proper way to do this is to compile wayland for the host
separately, and use ${CHOST}-pkg-config instead of pkg-config to get the
wayland-scanner path. In practice you would call
x86_64-linux-gnu-pkg-config --variable=wayland_scanner. The
x86_64-linux-gnu-pkg-config utility will look for pkgconfig files in the
host sysroot, instead of the target sysroot, allowing this use case to work.

Unfortunately not many packages do this correctly...

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

Re: [PATCH wayland v1 1/1] wayland-scanner.pc.in: prepend pc_sysrootdir

[Joe Konno]

On Fri, 16 Sep 2016 10:53:32 +0300
Pekka Paalanen  wrote:

> On Thu, 15 Sep 2016 15:22:12 -0700
> Joe Konno  wrote:
> 
> > From: Joe Konno 
> > 
> > In a cross-compilation environment with packages depending on
> > wayland-scanner, ensure the path to wayland-scanner is correct. Without
> > this patch, the path will _not_ point to the target environment but to
> > the host's, potentially leading to breakage.
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=97828
> > 
> > Signed-off-by: Joe Konno 
> > ---
> >  src/wayland-scanner.pc.in | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/wayland-scanner.pc.in b/src/wayland-scanner.pc.in
> > index 7b2a4c92e0e3..ec11a0bc982c 100644
> > --- a/src/wayland-scanner.pc.in
> > +++ b/src/wayland-scanner.pc.in
> > @@ -2,7 +2,7 @@ prefix=@prefix@
> >  exec_prefix=@exec_prefix@
> >  datarootdir=@datarootdir@
> >  pkgdatadir=@datadir@/@PACKAGE@
> > -wayland_scanner=@bindir@/wayland-scanner
> > +wayland_scanner=${pc_sysrootdir}/@bindir@/wayland-scanner
> >  
> >  Name: Wayland Scanner
> >  Description: Wayland scanner  
> 
> Hi,
> 
> ok, so pc_sysrootdir points to the sysroot. I would just like to
> confirm that this really does what you intend. wayland-scanner is a
> build tool to be run on the host. Such tools get installed into the
> sysroot even when compiled for the host, not the target, yes?
> 
> I read both http://dev.gentoo.org/~mgorny/pkg-config-spec.html and
> https://autotools.io/pkgconfig/cross-compiling.html but couldn't
> actually understand what is going on, perhaps because I never
> cross-compile.
> 
> Hence I cannot offer a Reviewed-by, but I can offer:
> Acked-by: Pekka Paalanen 
> 
> (Not for the 1.12.0 release.)
> 
> Are you using binary-compatible arches for both host and target? I'd
> like to see a test on a setup where the binaries are completely
> incompatible so that the host != target difference is obvious.

I'm struggling with this particular cross-compilation scenario as well, as
there's a fair bit of wonky overhead involved in the build process I'm dealing
with. Figured I'd introduce the patch and solicit feedback early while I
continue digging.

Your points are fair and the feedback's appreciated. I'll see about testing
this out a bit more with an incompatible binary target-- right now my host is
Intel-based and my target is also Intel-based.

I'll reply back once I feel convinced one way or the other. ^_^

> 
> 
> Thanks,
> pq



pgpDx4QhAEys3.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 07/14 v3] weston: Port RDP backend to new output handling API

[Pekka Paalanen]

On Thu, 18 Aug 2016 18:42:35 +0200
Armin Krezović  wrote:

> This is a complete port of the RDP backend that uses
> recently added output handling API for output
> configuration.
> 
> Output can be configured at runtime by passing the
> necessary configuration parameters, which can be
> filled in manually or obtained from the command line
> using previously added functionality. It is required
> that the scale and transform values are set using
> the previously added functionality.
> 
> After everything has been set, output needs to be
> enabled manually using weston_output_enable().
> 
> v2:
> 
>  - Rename output_configure() to output_set_size()
>in plugin API and describe it.
>  - Manually fetch parsed_options from wet_compositor.
>  - Call rdp_output_disable() explicitly from
>rdp_output_destroy().
> 
> v3:
> 
>  - Disallow calling rdp_output_set_size more than once.
>  - Manually assign a hardcoded name to an output as that's
>now mandatory.
>  - Use weston_compositor_add_pending_output().
>  - Bump weston_rdp_backend_config version to 2.
> 
> Reviewed-by: Quentin Glidic 
> Signed-off-by: Armin Krezović 
> ---
>  compositor/main.c  |  52 +++--
>  libweston/compositor-rdp.c | 138 
> +++--
>  libweston/compositor-rdp.h |  26 -
>  3 files changed, 167 insertions(+), 49 deletions(-)
> 

Hi Armin,

this patch looks essentially good, so:
Reviewed-by: Pekka Paalanen 

I did make a couple of comments below that would be nice to address
later.

I am also slightly concerned that this patch might introduce a hard to
lose race during start-up, but I haven't verified it. It's about the
output initialization vs. accepting RDP clients, I see that the
backend->output is being used in a few functions. Not quite sure if it
could get used before it gets initialized, even when main.c enables the
output ASAP. Hmm... but we probably won't service the listening socket
before all init is done, so maybe it's not an issue.

> diff --git a/compositor/main.c b/compositor/main.c
> index 12f5e76..7007901 100644
> --- a/compositor/main.c
> +++ b/compositor/main.c


> diff --git a/libweston/compositor-rdp.c b/libweston/compositor-rdp.c
> index ee81300..b34024a 100644
> --- a/libweston/compositor-rdp.c
> +++ b/libweston/compositor-rdp.c
> @@ -25,6 +25,7 @@
>  
>  #include "config.h"
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -371,15 +372,6 @@ rdp_output_repaint(struct weston_output *output_base, 
> pixman_region32_t *damage)
>   return 0;
>  }
>  
> -static void
> -rdp_output_destroy(struct weston_output *output_base)
> -{
> - struct rdp_output *output = to_rdp_output(output_base);
> -
> - wl_event_source_remove(output->finish_frame_timer);
> - free(output);
> -}
> -
>  static int
>  finish_frame_handler(void *data)
>  {
> @@ -471,16 +463,15 @@ rdp_switch_mode(struct weston_output *output, struct 
> weston_mode *target_mode)
>  }
>  
>  static int
> -rdp_backend_create_output(struct rdp_backend *b, int width, int height)
> +rdp_output_set_size(struct weston_output *base,
> + int width, int height)
>  {
> - struct rdp_output *output;
> - struct wl_event_loop *loop;
> + struct rdp_output *output = to_rdp_output(base);
>   struct weston_mode *currentMode;
>   struct weston_mode initMode;
>  
> - output = zalloc(sizeof *output);
> - if (output == NULL)
> - return -1;
> + /* We can only be called once. */
> + assert(!output->base.current_mode);
>  
>   wl_list_init(>peers);
>   wl_list_init(>base.mode_list);
> @@ -492,48 +483,100 @@ rdp_backend_create_output(struct rdp_backend *b, int 
> width, int height)
>  
>   currentMode = ensure_matching_mode(>base, );
>   if (!currentMode)
> - goto out_free_output;
> + return -1;
>  
>   output->base.current_mode = output->base.native_mode = currentMode;
> - weston_output_init(>base, b->compositor, 0, 0, width, height,
> -WL_OUTPUT_TRANSFORM_NORMAL, 1);
> -
>   output->base.make = "weston";
>   output->base.model = "rdp";
> +
> + /* XXX: Calculate proper size. */
> + output->base.mm_width = width;
> + output->base.mm_height = height;
> +
> + output->base.start_repaint_loop = rdp_output_start_repaint_loop;
> + output->base.repaint = rdp_output_repaint;
> + output->base.assign_planes = NULL;
> + output->base.set_backlight = NULL;
> + output->base.set_dpms = NULL;
> + output->base.switch_mode = rdp_switch_mode;

I'm wondering why setting these vfuncs is here in set_size rather than
in rdp_output_enable() or even rdp_backend_create_output(). It doesn't
feel logical here, but works as well so, whatever.

Ideally the setters would just set some fields and not much else, then
enable() would do all the real 

Re: [PATCH wayland 0/4] Untangle the symbol export duplication

[Emil Velikov]

Hi Pekka,

Thanks again for keeping up.

On 16 September 2016 at 10:46, Pekka Paalanen  wrote:
> Hi,
>
> there seems to be two different issues discussed here.
>
You cought me, yes there are.

> 1) libwayland-client and libwayland-server export the same interface
> symbols each, and cannot stop exporting them. You proposed to
> consolidate them into a third library.
>
> I don't think that is necessary.
>
> 2) Push everyone to build and install a .so and generated headers for
> every protocol extension XML file they offer for public use. You claim
> it would have benefits over the static build approach.
>
Almost...

s/Push/Suggest/ with an alternative on how to keep things static, yet
not exported. If anything your suggestion is the "pushy" one ;-)

> The static approach can break only when the interface symbols are
> exported and therefore possible to have conflicting symbols from
> different binaries all loaded into the same process. I think that is
> solved well enough by making wayland-scanner to stop forcing the export
> of the interface symbols.
>
Going a level up, abstracting ourselves of the actual wayland
specifics, there are a few simple (imho) points:
 - exposing the same symbols from different libraries is bad
 - hiding the exports will break applications and people will notice
that _after_ things are already broken.
 - any arguments against shared libraries is applicable to every
project in the wild.
 - users will have the option to static/shared link the code with info
how _not_ to export them (in case of the former).


>>  - Both client and server, take const pointer to the symbol in order
>> to bind an instance (client) and create the global (?) resource
>> (server).
>> Which in itself requires a provider for the said symbol(s). I believe
>> the latter is what you meant with "don't work", correct ?
>
> That is the "you cannot write all the necessary code" part, yes.
>
> The other part, which wayland-drm.xml does not excercise, is in the
> generated client headers as I explained above.
>
I fear you're getting on a tangent here - simple question was asked
and answered :-)

"header's won't work" == "headers _may_ pull dependency of _interface
symbol(s). latter of which should be resolved at link time"

>> >
>> > X_interface is only needed when creating objects of that kind.
>> >
>> Which (m)any new servers would like to do.
>
> I'm not sure what you're trying to say.
>
Simple. You mentioned "X_interface is only needed when creating
objects of that kind."
and I replied that "(m)any new servers would like to do." such a thing.

Those projects need to have the symbols resolved - be that statically
or otherwise is another topic.

>
> An interface can only ever be defined in one place, and no other place
> can change that or inherit from it (create a new interface of the same
> name but with added messages) because it will conflict eventually.
>
[...]
>
> Interface development by version bumps cannot branch, it must always be
> kept linear, which means that we really want to have just one XML file
> defining the interface.
>
I admit, the word "inherit" is wrong here. Dully noted.


> Such libfoo would not include any text, only variables with data that
> is constant and completely defined by the XML file it was created from.
> All the functions in the headers will be inline and call into libwayland
> directly.
>
Yes the actual "code" will be inlined into the user. Yes the library
will only add unique symbol(s) to the global namespace.

> All such libraries would be ignored by all other language bindings.
> Language bindings have their own scanners generating wrappers suitable
> for their language directly. The symbols we are talking about are just
> a curiosity of the C language bindings.
>
NB: other languages can reuse C binding, no ? Obviously they can use
the native ones as well.

> I really do not see much benefit from that. I do see a hassle with
> installing libraries and versioning everything properly.
Let's try to keep things technical please. "hassle" is ...

> Wayland-protocols would need to install 15 libraries already and that
> number will just grow and never go down.
Considering new protocols are added how could one expect _anything_ to
get less ?
If the number (15) of libraries is an issue one can fold things into a
single library. It will be a tiny bit of a cheat, but it's perfectly
reasonable.

> Add to that all the work
> needed in projects using these to start using the libraries.
>
Seems like my earlier point did not get through - old and new users
should need _zero_ changes.
If they opt for static + hide - one line, shared - ~5 or so.

> A project cannot make use of an interface v5 if it only implements
> support for v4. Using the library you suggest or not does not change
> that, support for a new interface version always requires new
> hand-written code for the new semantics. Therefore it is good enough to
> build the interface v4 definitions into the 

Re: [PATCH wayland 0/4] Untangle the symbol export duplication

[Pekka Paalanen]

On Fri, 16 Sep 2016 01:03:40 +0100
Emil Velikov  wrote:

> On 15 September 2016 at 11:47, Pekka Paalanen  wrote:
> > On Wed, 14 Sep 2016 16:57:17 +0100
> > Emil Velikov  wrote:
> >  
> >> Hi Pekka,
> >>
> >> Huge thanks for the input.
> >>
> >> On 14 September 2016 at 14:35, Pekka Paalanen  wrote: 
> >>  
> >> > On Tue, 30 Aug 2016 18:24:18 +0100
> >> > Emil Velikov  wrote:
> >> >  
> >> >> Hi all,
> >> >>
> >> >> For a while I've noticed that on mesa side we have few providers of the
> >> >> wl_drm_interface symbol and literally all our 'wayland binaries' are
> >> >> linked against both the client and server wayland libs.
> >> >>
> >> >> After having a look, it seems that:
> >> >>  - the server exposes the interface symbols for 'inheritance' purposes,
> >> >> thus other servers can build upon these primitives while designing their
> >> >> own protocols (interfaces ?).  

Hi,

there seems to be two different issues discussed here.

1) libwayland-client and libwayland-server export the same interface
symbols each, and cannot stop exporting them. You proposed to
consolidate them into a third library.

I don't think that is necessary.

2) Push everyone to build and install a .so and generated headers for
every protocol extension XML file they offer for public use. You claim
it would have benefits over the static build approach.

The static approach can break only when the interface symbols are
exported and therefore possible to have conflicting symbols from
different binaries all loaded into the same process. I think that is
solved well enough by making wayland-scanner to stop forcing the export
of the interface symbols.

Detailed replies are inline below.

> >> >
> >> > I have no idea what that means. wl_drm is private to Mesa.
> >> >
> >> > You are not supposed to use wl_drm in your apps, and *no-one* is
> >> > supposed to build on it by any other way than copying the XML file and
> >> > renaming everything. The recommended way would be to start writing XML
> >> > from scratch though.
> >> >  
> >> The wl_drm* symbols are what brought me here. AFAICT all the
> >> information/discussion is generic and not specific to it.
> >>
> >> See below for more.
> >>  
> >> >>  - at the same time the client needs to have a reference to the
> >> >> interface symbol in order to register an instance of said interface.  
> >> >
> >> > Anyway, those details don't really matter at all, see below.
> >> >  
> >> >> This means that if the "wrong" symbol gets picked at runtime and the
> >> >> client does not correctly manage older versions in its
> >> >> .registry_handle_global function (yes we have a case or two of those in
> >> >> the wild) things will end up horribly wrong.
> >> >>
> >> >> I think that a better option would have been to distinguish the two
> >> >> (call one instance or the other singleton) and let the scanner attribute
> >> >> for the name difference. Regardless of that is that it's too late to
> >> >> change things since this would lead to breaking the ABI.
> >> >>
> >> >> One way around it to update the scanner to provide newer symbols and
> >> >> annotate the old ones as deprecated. This way when/if we break the ABI
> >> >> we can untangle things. One day...
> >> >>
> >> >> Does the above sound about right - can anyone let me know if I'm loosing
> >> >> the plot ?
> >> >>
> >> >> That said, I've went ahead and removed duplication where possible - by
> >> >> folding the util symbols into libwayland-util. Please check with patch 
> >> >> 3/4
> >> >> how compatibility with existing and new users is be preserved.  
> >> >
> >> > Actually, the _interface symbols are not meant to be exported *at
> >> > all*. But there is a catch that is the source for all the confusion.
> >> >
> >> > For historical reasons, libwayland-server and libwayland-client are
> >> > designed to export the wl_*_interface pointers, because libwayland
> >> > ships the headers generated from wayland.xml.  
> >>  
> >> > The headers cannot work
> >> > if something does not provide the symbols from the generated
> >> > wayland-protocol.c file.  
> >> Having a dull moment - what do you mean with the above ? How can
> >> headers "work" or "not work" ?  
> >
> > Hi,
> >
> > you can generate the headers and use them, but you cannot write all the
> > necessary code to get a working thing without also having access to the
> > symbols exported from wayland-protocol.c. To be specific, you can never
> > create any object type whose wl_*_interface symbol you do not have
> > access to. This applies both to server and client side.
> >
> > Furthermore, the client side generated headers explicitly use the
> > *_interface symbols. On server side they are used by the hand-written
> > code in a compositor.
> >  
> Afaict (I'm looking at the mesa generated files yet they should be
> similar/identical to others):
>  - The generated headers 

Re: [PATCH wayland v1 1/1] wayland-scanner.pc.in: prepend pc_sysrootdir

[Pekka Paalanen]

On Thu, 15 Sep 2016 15:22:12 -0700
Joe Konno  wrote:

> From: Joe Konno 
> 
> In a cross-compilation environment with packages depending on
> wayland-scanner, ensure the path to wayland-scanner is correct. Without
> this patch, the path will _not_ point to the target environment but to
> the host's, potentially leading to breakage.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=97828
> 
> Signed-off-by: Joe Konno 
> ---
>  src/wayland-scanner.pc.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/wayland-scanner.pc.in b/src/wayland-scanner.pc.in
> index 7b2a4c92e0e3..ec11a0bc982c 100644
> --- a/src/wayland-scanner.pc.in
> +++ b/src/wayland-scanner.pc.in
> @@ -2,7 +2,7 @@ prefix=@prefix@
>  exec_prefix=@exec_prefix@
>  datarootdir=@datarootdir@
>  pkgdatadir=@datadir@/@PACKAGE@
> -wayland_scanner=@bindir@/wayland-scanner
> +wayland_scanner=${pc_sysrootdir}/@bindir@/wayland-scanner
>  
>  Name: Wayland Scanner
>  Description: Wayland scanner

Hi,

ok, so pc_sysrootdir points to the sysroot. I would just like to
confirm that this really does what you intend. wayland-scanner is a
build tool to be run on the host. Such tools get installed into the
sysroot even when compiled for the host, not the target, yes?

I read both http://dev.gentoo.org/~mgorny/pkg-config-spec.html and
https://autotools.io/pkgconfig/cross-compiling.html but couldn't
actually understand what is going on, perhaps because I never
cross-compile.

Hence I cannot offer a Reviewed-by, but I can offer:
Acked-by: Pekka Paalanen 

(Not for the 1.12.0 release.)

Are you using binary-compatible arches for both host and target? I'd
like to see a test on a setup where the binaries are completely
incompatible so that the host != target difference is obvious.


Thanks,
pq


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

Re: [PATCH libxkbcommon 2/2] README: Add basic build directions

[Ran Benita]

On Thu, Sep 15, 2016 at 02:31:55PM -0700, Bryce Harrington wrote:
> In particular, highlight the use of configure flags to control locating
> X11 keyboard stuff when building for Wayland.
> 
> Of particular note, if the locale root is not specified, then xkbcommon
> will look for them under $prefix (i.e. /usr/local/share/X11/locale).
> But unless the user has specifically installed them there, it is better
> to look in the standard system location, /usr/share/X11/locale.
> 
> Otherwise, xkbcommon will error when it can't find them, e.g.:
> 
>   xkbcommon: ERROR: ~/.XCompose:4:9: failed to expand %L to the locale 
> Compose file
>   xkbcommon: ERROR: ~/.XCompose:4:12: unterminated string literal
> 
> Signed-off-by: Bryce Harrington 

I applied these two as well, thanks!

BTW: The xkb-config-root is usually taken from the xkeyboard-config
pkg-config file, so it's usually not problematic if you have
xkeyboard-config installed during the build.

The x-locale-root is more unfortunate since libX11 does not provide a
pkg-config variable for it. IIRC I tried to add one (and even split the
x-locale stuff to a different repo since the Compose data is useful for
other projects well), but it was ignored... Hopefully distros can split
the libX11 package themselves though.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libxkbcommon] bench: Check for errors opening Compose file

[Ran Benita]

On Thu, Sep 15, 2016 at 02:12:38PM -0700, Bryce Harrington wrote:
> From: Bryce Harrington 
> 
> Otherwise it can segfault e.g. running ./compose inside the bench
> directory.

Applied, thanks!

(I only notice now when replying that you used tabs instead of spaces,
but I'll fix it up myself).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel