[PATCH wayland-protocols] input-method: Cleanup some grammar
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
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
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
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); + array.data = calloc(1, sizeof(int)); + assert(array.data != NULL); + wl_array_release(&array); + 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
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
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(&array); - assert(array.size == 0); - assert(array.alloc == 0); - assert(array.data == 0); - } + struct wl_array array; + wl_array_init(&array); + 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
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.
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 macros > -./autogen.sh --prefix=$WLD > -make && make install > -c
[PATCH wayland-web] Drop the ubuntu 12.04 build directions.
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 -c
Re: [PATCH wayland 0/4] Untangle the symbol export duplication
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
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
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
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
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
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(&output->peers); > wl_list_init(&output->base.mode_list); > @@ -492,48 +483,100 @@ rdp_backend_create_output(struct rdp_backend *b, int > width, int height) > > currentMode = ensure_matching_mode(&output->base, &initMode); > if (!currentMode) > - goto out_free_output; > + return -1; > > output->base.current_mode = output->base.native_mode = currentMode; > - weston_output_init(&output->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 work. This comment applies to all backends. > + > + return 0; > +} >
Re: [PATCH wayland 0/4] Untangle the symbol export duplication
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 program directly, and avo
Re: [PATCH wayland 0/4] Untangle the symbol export duplication
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 contain only the *_interface symbol > declaration. None of the generated code makes use of it. That is only because the XML
Re: [PATCH wayland v1 1/1] wayland-scanner.pc.in: prepend pc_sysrootdir
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