Re: [weston v2] configure.ac: Add support for new versions of systemd

[sardemff7+wayland]

On 2015-03-13 01:56, Javier Jardón wrote:

... that only provide a unique libsystemd.pc file
---
  configure.ac | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index d9d8d8f..5f2cbc1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -341,14 +341,21 @@ AC_ARG_ENABLE(resize-optimization,
  AS_IF([test "x$enable_resize_optimization" = "xyes"],
[AC_DEFINE([USE_RESIZE_POOL], [1], [Use resize memory pool as a 
performance optimization])])

-PKG_CHECK_MODULES(SYSTEMD_LOGIN, [libsystemd-login >= 198],
-  [have_systemd_login=yes], [have_systemd_login=no])
+PKG_CHECK_MODULES([SYSTEMD_LOGIN],
+  [libsystemd >= 198],
+  [PKG_CHECK_MODULES([SYSTEMD_LOGIN],
+ [libsystemd-login >= 198],
+ [have_systemd_login=yes], 
[have_systemd_login=no])])
  AS_IF([test "x$have_systemd_login" = "xyes"],
[AC_DEFINE([HAVE_SYSTEMD_LOGIN], [1], [Have systemd-login])])
  AM_CONDITIONAL(HAVE_SYSTEMD_LOGIN, test "x$have_systemd_login" = "xyes")

-PKG_CHECK_MODULES(SYSTEMD_LOGIN_209, [libsystemd-login >= 209],
-  [have_systemd_login_209=yes], [have_systemd_login_209=no])
+PKG_CHECK_MODULES([SYSTEMD_LOGIN_209],
+  [libsystemd >= 209],
+  [have_systemd_login_209=yes],
+  [PKG_CHECK_MODULES([SYSTEMD_LOGIN_209],
+ [libsystemd-login >= 209],
+ [have_systemd_login_209=yes], 
[have_systemd_login_209=no])])
  AS_IF([test "x$have_systemd_login_209" = "xyes"],
[AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 209])])




From systemd 209[1], libsystemd-login is in libsystemd. The compatibility 
pkg-config file just makes you link against libsystemd, so checking for libsystemd 
>= 209 is enough.

Also, the checks should be the other way around: first, see if libsystemd >= 209 
is there, then fallback to libsystemd-login >= 189.

So:


PKG_CHECK_MODULES(SYSTEMD_LOGIN, [libsystemd >= 209],

  [have_systemd_login_209=yes
   have_systemd_login=yes],
  [PKG_CHECK_MODULES(SYSTEMD_LOGIN, [libsystemd-login >= 198],
  [have_systemd_login=yes], [have_systemd_login=no])
AS_IF([test "x$have_systemd_login" = "xyes"],
  [AC_DEFINE([HAVE_SYSTEMD_LOGIN], [1], [Have systemd-login])])
AM_CONDITIONAL(HAVE_SYSTEMD_LOGIN, test "x$have_systemd_login" = "xyes")
AS_IF([test "x$have_systemd_login_209" = "xyes"],
  [AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 209])])


[1] 
http://cgit.freedesktop.org/systemd/systemd/tree/src/compat-libs/libsystemd-login.pc.in?id=v209

--

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

Re: [PATCH libinput 11/26] tablet: use libwacom to identify tablets for left-handedness

[sardemff7+wayland]

On 2015-02-24 07:21, Peter Hutterer wrote:

A tablet hotplug event is rare and not a time-critical event, so we load the
database on tablet init and throw it away again.

Signed-off-by: Peter Hutterer 
---
  configure.ac   | 14 ++
  src/Makefile.am|  2 ++
  src/evdev-tablet.c | 45 -
  test/tablet.c  | 13 -
  test/valgrind.suppressions | 18 ++
  5 files changed, 90 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1a4eb3a..95c822a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -165,6 +165,19 @@ if test "x$build_tests" = "xyes"; then
AC_PATH_PROG(VALGRIND, [valgrind])
  fi

+AC_ARG_ENABLE(libwacom,
+ AS_HELP_STRING([--enable-libwacom],
+[Use libwacom for tablet identification 
(default=enabled)]),
+ [use_libwacom="$enableval"],
+ [use_libwacom="yes"])
+if test "x$use_libwacom" = "xyes"; then
+   PKG_CHECK_MODULES(LIBWACOM, [libwacom], [HAVE_LIBWACOM="yes"])
+   AC_DEFINE(HAVE_LIBWACOM, 1, [Build with libwacom])
+else
+   HAVE_LIBWACOM="no"
+fi
+AC_SUBST(HAVE_LIBWACOM)


Do you use HAVE_LIBWACOM (as "yes"/"no") for real? I did not see any usage in 
this patch and it could be confusing. Using it in the configure summary does not require AC_SUBST.
I would just use ${use_libwacom}. Since you do not use automagic detection, it 
will always be set correctly for the summary. :-)


--

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

Re: [PATCH weston] configure.ac: make use of wayland-scanner.pc

[sardemff7+wayland]

On 2015-02-17 16:13, Emil Velikov wrote:

Currently we use the wayland-scanner executable as found with
AC_PATH_PROG, and then check the presence of wayland-scanner.pc

Currently the latter is unused even if AC_PATH_PROG fails to find the
binary. Rework things to use the pkg-config variable as a fall-back.

Cc: Andrew Oakley 
Cc: Bill Spitzak 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
  configure.ac | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1db9f79..b44675f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -503,11 +503,10 @@ AM_CONDITIONAL(HAVE_LCMS, [test "x$have_lcms" = xyes])

  AC_PATH_PROG([wayland_scanner], [wayland-scanner])


We should (must) set wayland_scanner as precious with AC_ARG_VAR. 
Probably a good idea to put that in this patch directly. (Ouch, I just 
saw that I did not add it in a patch of mine, shame on me.)


Also, AC_PATH_TOOL (or AC_PATH_TARGET_TOOL) may be a better choice 
considering the usage of wayland-scanner. Would the scanner generate 
*anything* different depending on the host(/target) platform? If so, 
it’s a (target) tool and AC_PATH_TOOL is the best way to go.


By the way, it seems sensible to me to ask for it in the standard PATH 
in all cases, as the C compiler is required, thus making the pkg-config 
check useless. I would consider wayland-scanner as part of the 
cross-compiling toolchain, not a library. You do have to *run* it on the 
compiling machine, right?


I am not fully aware of all the cross compiling stuff, so I just look at 
how Autoconf is telling me to handle that, since it’s one of its goal.




  if test x$wayland_scanner = x; then
-   AC_MSG_ERROR([wayland-scanner is needed to compile weston])
+   PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
+   wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner wayland-scanner`


I guess we cannot require pkg-config 0.28. If we can, PKG_CHECK_VAR is 
your friend.


Anyway, I think PKG_CHECK_EXISTS is better here (if we keep the 
pkg-config check as explained above). The _CFLAGS and _LIBS vars are 
just noise, and the error message should be clearer than the default 
one, imo. I am probably nitpicking here.




  fi

-PKG_CHECK_MODULES(WAYLAND_SCANNER, wayland-scanner)
-
  AC_CONFIG_FILES([Makefile src/version.h src/weston.pc])

  AM_CONDITIONAL([HAVE_GIT_REPO], [test -f $srcdir/.git/logs/HEAD])



Sorry for jumping late in the thread.

With AC_ARG_VAR added:
Reviewed-by: Quentin Glidic 

I let you guys decide on the cross-compiling stuff.

--

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

Re: [PATCH weston 1/2] configure.ac: Don't look for Xwayland in the weston install destination

[sardemff7+wayland]

On 2015-02-10 03:15, Bryce Harrington wrote:

Turns out the issue I've run into is that the --with-xserver-path
setting doesn't get passed down into distcheck, which calls configure
like this:

   && $(am__cd) $(distdir)/_build \
   && ../configure \
 $(AM_DISTCHECK_CONFIGURE_FLAGS) \
 $(DISTCHECK_CONFIGURE_FLAGS) \
 --srcdir=.. --prefix="$$dc_install_base" \
   && $(MAKE) $(AM_MAKEFLAGS) \

Setting --with-xserver-path in AM_DISTCHECK_CONFIGURE_FLAGS doesn't seem
to work (it ends up confusing config.sub mightily), but setting it in
DISTCHECK_CONFIGURE_FLAGS seems to produce valid results.


DISTCHECK_CONFIGURE_FLAGS is for user-defined distcheck flags, you must 
not define in your Makefile.am. I would rather find what is going on 
with AM_DISTCHECK_CONFIGURE_FLAGS, any log to share?


--

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

Re: [PATCH libinput 2/3] Add a rules file to assign LIBINPUT_DEVICE_GROUP

[sardemff7+wayland]

On 2015-02-10 07:50, Peter Hutterer wrote:

diff --git a/configure.ac b/configure.ac
index f47c5a4..2420f86 100644
--- a/configure.ac
+++ b/configure.ac
@@ -69,6 +69,15 @@ fi
  AC_SUBST(GCC_CFLAGS)
  AC_SUBST(GCC_CXXFLAGS)

+AC_ARG_WITH(udev-rules-dir,
+AS_HELP_STRING([--with-udev-rules-dir=DIR],
+   [Directory where udev expects its rules files
+   [[default=$libdir/udev/rules.d]]]),
+[udevdir="$withval"],


You may (should?) use $with_udev_rules_dir here. Furthermore, you should 
handle the --without case with something like that:


udev_rules_dir_default=$libdir/udev/rules.d
AC_ARG_WITH(udev-rules-dir,
AS_HELP_STRING([--with-udev-rules-dir=DIR],
   [Directory where udev expects its rules files
   [[default=$udev_rules_dir_default]]]),
[],
[with_udev_rules_dir=yes])
case "$with_udev_rules_dir" in
no|"") AC_MSG_ERROR([You must define an udev rules directory]) ;;
yes) udevdir=$udev_rules_dir_default ;;
*) udevdir=$with_udev_rules_dir ;;
esac



index 000..5b39ac7
--- /dev/null
+++ b/rules/Makefile.am
@@ -0,0 +1,4 @@
+udevdir=$(UDEV_RULES_DIR)
+udev_DATA = 80-libinput-tablet.rules
+
+EXTRA_DIST = $(udev_DATA)



Please use that only:

udevdir=$(UDEV_RULES_DIR)
dist_udev_DATA = 80-libinput-tablet.rules

--

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

Re: [PATCH V2] configure.ac: Fallback to older detection code if pkg-config can't find expat

[sardemff7+wayland]

On 2015-02-02 22:29, Bill Spitzak wrote:

This paritally reverts commit a4afd90f9f0c27ed5f3f313b915c260673f8be34.

On older expat versions (ie the one on Ubuntu 12.04) there is no pkg-config
file, so fall back to the previous test for the header file when it fails.
Test is slightly cleaned up from previous one.

I could not use AC_SEARCH_LIBS as was suggested, as this leaves the switch
in LIBS, not EXPAT_LIBS, and thus does not match the pkg-config results.


Well, you can perfectly do that, especially since AC_CHECK_LIB does not 
export EXPAT_LIBS either.


I would advice to use AM_SUBST_NOTMAKE(LIBS) and never rely on LIBS at 
all. But that could be left to another patch I guess.

---
  configure.ac |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 0426b53..fc5ea55 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,7 +85,12 @@ AC_ARG_WITH(icondir, [  --with-icondir=Look for 
cursor icons here],
  AC_SUBST([ICONDIR])

  if test "x$enable_scanner" = "xyes"; then
-   PKG_CHECK_MODULES(EXPAT, [expat])
+   PKG_CHECK_MODULES(EXPAT, [expat],,
+   [AC_CHECK_HEADERS(expat.h,,
+   [AC_MSG_ERROR([Can't find expat.h. Please install 
expat.])])
+   AC_CHECK_LIB(expat, XML_ParserCreate, [EXPAT_LIBS="-lexpat"],


Do you rely on PKG_CHECK_MODULES to AC_SUBST?



+   [AC_MSG_ERROR([Can't find expat library. Please install 
expat.])])
+   ])
  fi

  AC_PATH_PROG(XSLTPROC, xsltproc)




--

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

Re: [PATCH] Fallback to older detection code if pkg-config can't find expat

[sardemff7+wayland]

On 2015-01-31 02:23, Bill Spitzak wrote:

On older expat versions there is no pkg-config file, so fall back to
the previous test for the header file and library if it fails.


I agree this a good practice to fallback in this case.



This paritally reverts commit a4afd90f9f0c27ed5f3f313b915c260673f8be34.
---
  Makefile.am  |1 -
  configure.ac |7 ++-
  2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 0fccf86..43b741a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -65,7 +65,6 @@ if ENABLE_SCANNER
  wayland_scanner = $(top_builddir)/wayland-scanner
  bin_PROGRAMS = wayland-scanner
  wayland_scanner_SOURCES = src/scanner.c
-wayland_scanner_CFLAGS = $(EXPAT_CFLAGS) $(AM_CFLAGS)


This hunk is bad. If the pkg-config file provide CFLAGS, they must be 
used. And there is no harm at all to use an undefined variable here. 
(And I think we should just define it empty in the fallback.)




  wayland_scanner_LDADD = $(EXPAT_LIBS) libwayland-util.la
  $(BUILT_SOURCES) : wayland-scanner
  pkgconfig_DATA += src/wayland-scanner.pc
diff --git a/configure.ac b/configure.ac
index 97222f0..f7610e0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,7 +85,12 @@ AC_ARG_WITH(icondir, [  --with-icondir=Look for 
cursor icons here],
  AC_SUBST([ICONDIR])

  if test "x$enable_scanner" = "xyes"; then
-   PKG_CHECK_MODULES(EXPAT, [expat])
+   PKG_CHECK_MODULES(EXPAT, [expat],,
+[AC_CHECK_HEADERS(expat.h, [AC_DEFINE(HAVE_EXPAT_H)],


HAVE_EXPAT_H is defined by AC_CHECK_HEADERS itself so please remove the 
AC_DEFINE.




+   [AC_MSG_ERROR([Can't find expat.h. Please install expat.])])
+   AC_CHECK_LIB(expat, XML_ParserCreate, [EXPAT_LIBS="-lexpat"],


If we re-introduce such check, we should use AC_SEARCH_LIBS (as advised 
by the Autoconf manual[1]).

Here is the code I would use :


EXPAT_CFLAGS=""
EXPAT_LIBS="-lexpat"
AC_SEARCH_LIBS([XML_ParserCreate], [expat],
  [
AC_SUBST(EXPAT_CFLAGS)
AC_SUBST(EXPAT_LIBS)
  ],
  [
AC_MSG_ERROR([Can't find expat library. Please install expat.])
  ])


+   [AC_MSG_ERROR([Can't find expat library. Please install 
expat.])])
+   AC_SUBST(EXPAT_LIBS)])
  fi

  AC_PATH_PROG(XSLTPROC, xsltproc)



[1] 



--

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

Re: [PATCH 1/1] configure.ac: use pkg-config to find expat

[sardemff7+wayland]

Once the two things below are fixed:

Reviewed-by: Quentin Glidic 


On 2015-01-26 15:32, Andrew Oakley wrote:

This is now done in the same way as the libffi dependency and still
allows the library to be installed in a non-standard location (with
PKG_CONFIG_PATH).

We also now enable the normal GCC options when building the scanner.


They were used. AM_CFLAGS is appended for any target which doesn’t have 
a _CFLAGS variable. So this part of the commit message should be removed.




---
  Makefile.am  |  1 +
  configure.ac | 11 +--
  2 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 1551762..a2c2d79 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -65,6 +65,7 @@ if ENABLE_SCANNER
  wayland_scanner = $(top_builddir)/wayland-scanner
  bin_PROGRAMS = wayland-scanner
  wayland_scanner_SOURCES = src/scanner.c
+wayland_scanner_CFLAGS = $(EXPAT_CFLAGS) $(GCC_CFLAGS)


Use $(AM_CFLAGS) (which contains $(GCC_CFLAGS)) as defining a _CFLAGS 
variable will opt it out.




  wayland_scanner_LDADD = $(EXPAT_LIBS) libwayland-util.la
  $(BUILT_SOURCES) : wayland-scanner
  pkgconfig_DATA += src/wayland-scanner.pc
diff --git a/configure.ac b/configure.ac
index 0249002..b518ce1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -71,17 +71,8 @@ AC_ARG_WITH(icondir, [  --with-icondir=Look for 
cursor icons here],
 [  ICONDIR=${datadir}/icons])
  AC_SUBST([ICONDIR])

-EXPAT_LIB=""
-AC_ARG_WITH(expat, [  --with-expat=  Use expat from here],
-  [ expat=$withval
-CPPFLAGS="$CPPFLAGS -I$withval/include"
-LDFLAGS="$LDFLAGS -L$withval/lib" ] )
  if test "x$enable_scanner" = "xyes"; then
-   AC_CHECK_HEADERS(expat.h, [AC_DEFINE(HAVE_EXPAT_H)],
-[AC_MSG_ERROR([Can't find expat.h. Please install 
expat.])])
-   AC_CHECK_LIB(expat, XML_ParserCreate, [EXPAT_LIBS="-lexpat"],
-[AC_MSG_ERROR([Can't find expat library. Please install 
expat.])])
-   AC_SUBST(EXPAT_LIBS)
+   PKG_CHECK_MODULES(EXPAT, [expat])
  fi

  AC_PATH_PROG(XSLTPROC, xsltproc)




--

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

Re: [WESTON patch] Makefile: fix assigning to dist_wayland_session_DATA

[sardemff7+wayland]

On 2015-01-22 10:03, Marek Chalupa wrote:

dist_wayland_session_DATA is not set anywhere before, so using +=
results in:

error: dist_wayland_session_DATA must be set with '=' before using '+='

Signed-off-by: Marek Chalupa 
---
  Makefile.am | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index ccec9f3..589b47b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -158,7 +158,7 @@ pkgconfig_DATA = src/weston.pc

  wayland_sessiondir = $(datadir)/wayland-sessions
  wayland_session_DATA = src/weston.desktop
-dist_wayland_session_DATA += $(wayland_session_DATA)
+dist_wayland_session_DATA = $(wayland_session_DATA)

  westonincludedir = $(includedir)/weston
  westoninclude_HEADERS =   \



dist_wayland_session_DATA *alone* is more than enough actually. :-)
So:

dist_wayland_session_DATA = src/weston.desktop

--

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

Re: [PATCH weston] build: install a login manager session entry

[sardemff7+wayland]

On 2015-01-21 04:46, Bryce Harrington wrote:

On Sun, Dec 28, 2014 at 02:20:49PM +0100, Lubomir Rintel wrote:

This makes it possible to run Weston session from GDM (and possibly
other login managers).
---
  Makefile.am| 5 +
  src/weston.desktop | 5 +
  2 files changed, 10 insertions(+)
  create mode 100644 src/weston.desktop


Thanks, applied
1a873aa..4f4b47a  master -> master



Seems like I failed to reply to the list for my review on this one.

Basically, you should (read “must”) use dist_wayland_session_DATA here
and not EXTRA_DIST (because the dist_* variant works perfectly).
Should I send a follow-up or would you push the trivial fix yourself?


Also I was wondering about the whole weston to run in the D-Bus session
since it may be more sensible to run the weston-desktop-shell only.
Another “Weston DE” consideration here I guess.

Cheers,

--

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

Re: [PATCH weston v2 2/2] compositor: Implement JSON-timeline logging

[sardemff7+wayland]

On 2014-12-04 12:23, Pekka Paalanen wrote:

On Tue, 02 Dec 2014 12:12:28 -0800
Bill Spitzak  wrote:

I think you should make an emit(FILE*, const char*) function that prints
a quoted string or null, instead of doing this repeatedly. Such a
function could also convert non-printable characters to escape sequences.


Yeah, not a bad idea.


I think you better use a streaming JSON library (yajl is quite good at 
that). If this feature is for debugging, there is no harm making it 
optional with a little dependency. Even better, could it be a private 
debug protocol (always there) with a demo client outputting JSON? This 
way, we could see graphical clients providing graphs in real time, which 
would be nice too.




I think also you should ignore strict JSON and not put quotes around the
keywords. It makes the output a lot easier to read and most libraries
handle it.


Oh, I did hate those quotes, but assumed they were necessary as per
.


They are necessary. The fact that the format is stricter than parsers is 
just for robustness (and for JavaScript too probably, where these quotes 
are optional). If you want to output JSON, please output real JSON.



> OTOH, I'm not so sure my outmost JSON structure

is that valid either, since I'm emitting multiple separate objects
instead of a huge array enclosing it or something.


You can define that you are printing objects one after another, without 
any relation between them. In this case, you can use a parser with 
“ignore trailing garbage” option (think of it as e.g. the endptr of strtol).
If you want to be able to parse the whole thing in one go, you should 
put them in a big array. You can end your array with an empty object so 
that you can always put a comma after each object. You will get 
something like this (using "{…}" for complete objects):


[
{…},
{…},
{…},
{}]

Or you can use a JSON library that will manage it for you.

--

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

Re: [PATCH] doc: Add config check for doxygen 1.8.0+.

[sardemff7+wayland]

On 2014-12-03 21:39, Bill Spitzak wrote:

Thanks! You know I tried searching for "version" in the autotools
documents, but did not find this. That documentation is pretty incomplete.


Not incomplete at all. You should search harder next time. ;-)


I would advise anyone working with Autotools to read the full manual(s) 
at least once to understand the thing better. :-)


Cheers,

--

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

Re: [weston V2 1/2] Check for math (m) and real time (rt) libraries

[sardemff7+wayland]

On 2014-10-30 15:23, Javier Jardón wrote:

---
  Makefile.am  | 19 +--
  configure.ac |  6 ++
  2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/configure.ac b/configure.ac
index 934..e78f6c8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -46,6 +46,12 @@ AC_CHECK_FUNC([dlopen], [],
AC_CHECK_LIB([dl], [dlopen], DLOPEN_LIBS="-ldl"))
  AC_SUBST(DLOPEN_LIBS)

+AC_SEARCH_LIBS([sqrt], [m], [],
+   [AC_MSG_FAILURE([Math library missing])])
+
+AC_SEARCH_LIBS([clock_gettime], [rt], [],
+   [AC_MSG_FAILURE([Real time library missing])])
+
  AC_CHECK_DECL(SFD_CLOEXEC,[],
  [AC_MSG_ERROR("SFD_CLOEXEC is needed to compile weston")],
  [[#include ]])



That will add stuff to $(LIBS) directly, which should be avoided as much 
as possible. The use of $(LIBS) leads to overlinking most of the time.

I would recommend adding
AM_SUBST_NOTMAKE(LIBS)
to configure.ac, and add all the appropriate *_LIBS and *_CFLAGS 
variables everywhere needed.


--

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

Re: [PATCH] build: honor results obtained by pkg-config libinput

[sardemff7+wayland]

On 2014-09-08 15:03, Jan Engelhardt wrote:

The error was:
src/libinput-seat.c:30:22: fatal error: libinput.h: No such file or directory
---
  Makefile.am | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index b2d6893..7f3e5d3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -34,7 +34,8 @@ AM_CPPFLAGS = \
-DDATADIR='"$(datadir)"'  \
-DMODULEDIR='"$(moduledir)"'  \
-DLIBEXECDIR='"$(libexecdir)"'\
-   -DBINDIR='"$(bindir)"'
+   -DBINDIR='"$(bindir)"' \
+   $(LIBINPUT_BACKEND_CFLAGS)

  CLEANFILES = weston.ini $(BUILT_SOURCES)




Hi,

You must not put pkg-config *_CFLAGS in *_CPPFLAGS variables, as it can 
contains flags that cpp will not understand. This is especially 
forbidden for AM_CPPFLAGS, which is a global variable used everywhere.


In the same way, you should not put flags in AM_* vars unless they are 
used through your whole project, which I think is not the case here.
Instead, find the targets using src/libinput-seat.c and add 
LIBINPUT_BACKEND_CFLAGS to their _CFLAGS variable.

Hint: add an INPUT_BACKEND_CFLAGS variable mimicking INPUT_BACKEND_LIBS.

Nacked-by: Quentin Glidic 

Cheers,

--

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

Re: [PATCH libinput 6/8] test/Makefile.am: Use $(GCC_CFLAGS) from configure.ac

[sardemff7+wayland]

On 25/03/2014 21:45, Jonas Ådahl wrote:

Signed-off-by: Jonas Ådahl 
---
  test/Makefile.am | 15 ---
  1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/test/Makefile.am b/test/Makefile.am
index b59d4a9..12ed023 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -2,6 +2,7 @@ if BUILD_TESTS
  AM_CPPFLAGS = -I$(top_srcdir)/src $(CHECK_CFLAGS) $(LIBEVDEV_CFLAGS)

  TEST_LIBS = liblitest.la $(CHECK_LIBS) $(LIBUDEV_LIBS) $(LIBEVDEV_LIBS) 
$(top_builddir)/src/libinput.la -lm
+TEST_CFLAGS = $(GCC_CFLAGS) $(AM_CPPFLAGS)


AM_CPPFLAGS is wrong here, it must be AM_CFLAGS. The way it is currently 
written (or with this patch) AM_CPPFLAGS are passed twice while 
AM_CFLAGS are ignored. It may not be important but it is still wrong.
You could also drop TEST_CFLAGS altogether and append the GCC_CFLAGS to 
AM_CFLAGS in configure.ac.


(In your C++ test patch, you should also add AM_CXXFLAGS to 
test_build_cxx_CXXFLAGS.)



--

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

Re: Weston : ideas about xdg_sell, and implementation for a taskbar

[sardemff7+wayland]

On 11/02/2014 02:23, Bill Spitzak wrote:

May not have explained it correctly. It sounded like you were not
going to allow dialogs to be minimized except as a side-effect of
minimizing the parent.


I was, but I am not any more.



I certainly want to allow this! And I certainly want to support
minimizing multiple surfaces.


I agree, it is needed.



I was suggesting that one method of minimizing multiple surfaces
would be for the client to arrange them all as children of one of
them and then minimize the parent. The primary purpose is so the
compositor/taskbar knows all those windows are "related", for
instance to produce on a single taskbar entry.


All scenarii are supported. You can reparent or simply minimize everyone.



No, because if the client wants to redraw or raise or show or hide
any other surface as a side-effect of the minimize, these changes
will not be atomic with the minimize, resulting in unwanted
flickering of an intermediate display. There has to be a way for the
minimized window to not disappear until the client does some kind of
commit.


The commit *is* the .set_minimized. You can raise, draw everything you
want *then* send the .set_minimized request. It is the last step of the
minimization process. In the scenario of multiple .set_minimized
requests, the last one must be the “main” one (either the one requested
by the compositor or the one triggered by client UI).



I assume you mean "minimize", not "unfocus"? It must be possible to
minimize windows that don't have focus.


I mean “unfocus”. There is no reason to treat the minimized with a
special event. The client already reparented surfaces and raised
everything relevant.



It sounds like you are describing the 3-way communication I
proposed. I see 3 steps:

1. Client decides it wants to minimize, tells compositor (this step
is not done if the compositor chooses to do so). 2. Compositor tells
client that the minimize is happening. 3. (the step you are missing)
client tells compositor it has corrected all it's surfaces to reflect
the result of minimizing and it is ok to perform it.


No, I am describing a .request_set_minimized/.set_minimized use case:
1a. The compositor send the .request_set_minimized event.
1b. The client “minimize” button is pressed.
2. The client reparent, draw, raise, do whatever it needs to keep the UI
consistent.
3. The client send the .set_minimized request.
4. The relevant surfaces are hidden by the compositor.

In case 1b with a compositor not supporting minimization, the client
will just looks a bit weird. But:
1. I believe that a user will not expect anything better when using such
a compositor.
2. Using flags in the configure event to inform the client which actions
are supported will just remove such a weird case.



[…]


The rest of your email should be answered already.


Thanks,

--

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

Re: Weston : ideas about xdg_sell, and implementation for a taskbar

[sardemff7+wayland]

(Some parts are reordered to makes more sense in my answers. Agreed
parts are removed.)

On 10/02/2014 23:42, Bill Spitzak wrote:

sardemff7+wayl...@sardemff7.net wrote:

Based on Bill’s events and requests, here is what I think should
handle all cases the right way while keeping the global policy on
the compositor’s side [in square brackets, the part(s) that the
point ensure]: 1. States that the client *must* call .set_minimized
at least on the same surface as the .request_set_minimized
[compositor policy, client surfaces relations]


Yes I think that is a way to detect dead clients.

Rather than send minimize on many surfaces I propose the client
arranges all the windows it wants to vanish as children of each other
and then sends the minimize request to the top one (the one that the
compositor requested must either be this top one or in the list).

Multiple minimizes can then mean that the client wants multiple
taskbar entries or that unminimizing one window is different than the
other.


3. Only ever use “toplevel” (= no parent) surfaces compositor-side
for the .request_set_minimized [client surfaces relations]


Not sure why you want to limit it like this. I certainly would like
the ability to minimized dialog windows.


If you want a dialog window to be minimized, then it makes even more
sense to allow minimizing multiple surfaces. The client could want to
minimize everything if you minimize the toolbox.



2. Do not assume anything (e.g. do not draw “inactive” window
borders) before the real events (frame callback, focus events and
friends) [compositor relevant features]


This will not work. The actual vanishing of the minimized window must
be deferred until *after* the client has done this, or it will not be
atomic.


This will work perfectly. As you said, the window vanished, which means 
an “unfocus” event and no more frame callback. The compositor can safely 
hide a window even if the decorations were not updated accordingly. 
Also, minimizing should not be treated specifically, we already have the 
frame callback and focus events.




4. Have a way for the client to know which features are supported
[client UI consistence]


From my previous point, the client UI consistence is assured without 
such a mechanism since the client will see no “unfocus” event.




You may be right that the client does need to know if the compositor
 would obey the minimize. I thought it was not a problem but as you
point out the client may redraw the activation or move things around
on the assumption that it is going to work.

My first thought is to make this a 3-way communication. If you hit a
 minimize button the client sends a minimize-request-command to the
compositor. The compositor then responds with a
minimize-request-event. The client then knows it is going to work,
adjusts all it's display, and sends a minimize-command.

It may be better to just have an event that says whether the
compositor will obey things, like you suggest.


Just use the well-defined “unfocus” event and the minimize request.



ALTERNATIVE:

Actually after I typed this I think there may be a scheme that works
 more like you want but I'm not sure if it is practical:

1. Client sends a minimize-request on a surface, or the compositor
just decides to minimize a surface.

2. Compositor sends a minimize-notify (or not if it does not want to
 minimize). However (here is the tricky part) the surface has not
really minimized! It is still visible on-screen and everything works
as before until the compositor sees a commit that it knows is in
response to the minimize-notify.


There is just no point for the surface to still be visible. Unless some 
weird client wants to draw “Oh my god I am minimizing, bye!” in its surface.
The surfaces relation are already taken care of from point 1 here, no 
harm in actually hide everything.




3. Client then can respond to the minimize-notify by rearranging the
 surface tree, redrawing surfaces, doing minimize-request on other
surfaces, etc. It then eventually does a commit, and the serial
number can be used to identify that it is in response to the
minimize-notify (is this possible in wayland?). Note the client is
unable to stop the surface from minimizing, but can get ready for
it.

4. If the client is dead then the compositor just does the minimize
using the current surface parent/child tree.


As I said, it /should/ be irrelevant.


Summary:
1. .request_set_minimized (from the compositor) on a surface *must be 
obeyed* by the client, at least on said surface (e.g. a toolbox can 
minimize everything).
2. On .request_set_minimized, the client is free to reparent other 
surfaces to keep its UI in a consistent state.
3. The client just handle the “focus/unfocus” event and frame callback 
to draw its UI. Minimizing is not a special case as it does not need to be.


It should work in all cases, especially the thumbnails preview: the 
surface is drawn inactive but updated as soon as the preview is visible 
(whil

Re: Weston : ideas about xdg_sell, and implementation for a taskbar

[sardemff7+wayland]

On 10/02/2014 21:57, Bill Spitzak wrote:

Okay this sounds like it is going in exactly the wrong direction.


And you sound like you do not understand the strong need here: the 
compositor *must be in charge* of everything. But, please, do not start 
to yell now, it can perfectly work well with your need as well, let me 
explain.




What I am trying to do is restore the ability to use overlapping windows
which was broken in approximatly 1990 when everybody started doing
"click raises" (when even then it was *trivial* for a client to raise
it's own windows), and has only gotten worse as "roles" and "layers" and
so on have been added so that we can no longer even know if the user
will be able to close a dialog box or whether it is visible when we
don't have the focus.

Current schemes are about as useful as the compositor drawing into your
surface automatically in response to various mouse clicks (like always
drawing a line on the assumption that you are a sketching program), then
claiming you can "fix" it by drawing the correct picture again
afterwards. This is obviously nonsense but for some reason the same
logic is not being applied to surfaces.

All I want is for the client to have final say over exactly what
surfaces are visible and what their stacking order is. Then we may be
able to implement floating dialog boxes again after 25 years of the dark
ages.

This means that no surface disappears, appears, or changes stacking
order until after the client has been allowed to adjust all the other
surfaces it owns.


That sounds ok to me.



And that means there cannot be a "you were minimized" event. There can
only be a "I want you to minimize" event. It also means that a request
from the client to be minimized must be obeyed.


Partly wrong.

First, a compositor may have no mechanism of “minimization”, so it must 
not be forced to obey such a request with no meaning for it.


Second, the client must define relations between its surfaces, we both 
agree on that and I am pretty sure everyone does agree to some extent.




The compositor is allowed to detect "dead" clients (and misbehaviong
clients) and fake anything it wants, but this should not be used to
dictate the api.


True.



The api should be designed and described for
well-behaved clients (with perhaps a few notes on things that a
compositor can detect that tells it that the client is behaving badly
enough that the api should be ignored).


No. It *must* have a properly defined behaviour for all cases *that will 
keep the compositor in charge*. The compositor is also the shell, and 
the shell is user’s choice because it implies a policy that the user wants.



Based on Bill’s events and requests, here is what I think should handle 
all cases the right way while keeping the global policy on the 
compositor’s side [in square brackets, the part(s) that the point ensure]:
1. States that the client *must* call .set_minimized at least on the 
same surface as the .request_set_minimized [compositor policy, client 
surfaces relations]
2. Do not assume anything (e.g. do not draw “inactive” window borders) 
before the real events (frame callback, focus events and friends) 
[compositor relevant features]
3. Only ever use “toplevel” (= no parent) surfaces compositor-side for 
the .request_set_minimized [client surfaces relations]
4. Have a way for the client to know which features are supported 
[client UI consistence]


IMO, the same points (adapted) apply to all features that may have UI 
both client-side and compositor-side.
Concerning point 4, it could be a decoration flag in the configure 
event, the same way we want side ones (to support tiling!).


Thanks,

--

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

Re: [PATCH weston 06/11] configure.ac: Make AC_ARG_ENABLE calls consistent

[sardemff7+wayland]

On 08/12/2013 19:45, Quentin Glidic wrote:

From: Quentin Glidic 

Signed-off-by: Quentin Glidic 
---
  configure.ac | 128 ++-
  1 file changed, 83 insertions(+), 45 deletions(-)

diff --git a/configure.ac b/configure.ac
index daf81eb..157dc3a 100644
--- a/configure.ac
+++ b/configure.ac
[…]
@@ -158,10 +173,13 @@ fi

  PKG_CHECK_MODULES(COMPOSITOR, [$COMPOSITOR_MODULES])

-AC_ARG_ENABLE(wayland-compositor, [  --enable-wayland-compositor],,
+AC_ARG_ENABLE(wayland-compositor,
+ AS_HELP_STRING([--disable-wayland-compositor],
+[Disable Wayland (nested) compositor.]),,
  enable_wayland_compositor=yes)
  AM_CONDITIONAL(ENABLE_WAYLAND_COMPOSITOR,
-  test "x$enable_wayland_compositor" = "xyes" -a "x$enable_egl" = 
"xyes")
+  [test "x$enable_wayland_compositor" = "xyes"
+ -a "x$enable_egl" = "xyes"])


Little fail here, please ignore this chunk. Patch 7/11 is supposed to 
include the m4-quoting. I will resend the two patches (or the full 
series) after review.


> […]

--

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

Re: [RFC wayland v2] libwayland-client: Add GLib main loop integration

[sardemff7+wayland]

Forgot to amend the commit message:
libwayland-client: Add GLib main loop integration

--

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

Re: [PATCH weston 1/5] tests: always build tests

[sardemff7+wayland]

On 11/09/2013 11:12, Sam Spilsbury wrote:

Quick thought: there's also an important psychological effect to
building the tests on a standard make because it promotes them to the
same importance as the rest of your code. They become less of an
afterthought and it promotes greater care around how people design
the tests (eg, making the tests clean, making sure they run
quickly), as well as how the rest of the codebase interacts with the
tests. We observed a similar effect at Canonical between the projects
which had test building on by default as opposed to those that did
not.


Then we should definitely fix users (developers) and their workflow,
not some arbitrary “problem”, as I said already.



It all depends on whether or not the tests are there as a basic
safety line for managing releases or whether or not tests are used
as a tool to iterate and improve quality. In the latter case,
building them by default is a very sensible decision indeed.


Not at all. They should be *run* by default in this case, not just be
built. If their point is to check the code, they must do that, not just
build against some headers. See the end of this email.


On Wed, Sep 11, 2013 at 4:53 PM, Peter Hutterer wrote:

from my experience, every project I've worked on that has a test
suite needed this patch eventually, there's always a way to forget
to run make check and suddenly you find out that it's been broken
for months. (this is largely because test suites have a tendency to
become outdated and useless, but...)


Again, users need a “patch”. I’ll add a bit on that at the end of this
email.



how so? TESTS defines what's run during make check. check_* defines
what's built, the two are related but not the same.


Because building tests means you need their *dependencies*, which should
definitely not be needed if you do not want to run them.



I know the principle, I'm claiming that without this, tests will
eventually break unless you find a way to force everyone to run make
check.

Which, coincidentally, wastes maintainer time too if you get a patch
that's fine but breaks make check and you have to get through another
revision.


So, you have tests that build. Fine. Now what? If nobody run them, they 
are useless. The best way to force them is the vcs. Just add a git hook 
that runs them on commit or push, are you are sure you repo will never 
break. But you should teach people to run them, not force them to do so.


A good example (for me) is Cairo. Their tests are noinst_* already (side 
note: we have to patch that in Exherbo to avoid circular dependencies on 
fresh installs).

They are known to be broken for ages, but they build fine, sure!

Having tests built by default is not a bad idea, it is a bad fix. The 
developer *will* think “Hey, tests build, everything’s ok!” while his 
commit just broke them.



If you want to force tests build or run, you can tweak rules a bit:

if RUN_TESTS_BY_DEFAULT
 ifneq ($(ALREADY_INSIDE),yes)
all-local:
$(MAKE) ALREADY_INSIDE=yes check
 endif
else
if BUILD_TESTS_BY_DEFAULT
 ifneq ($(ALREADY_INSIDE),yes)
all-local:
$(MAKE) TESTS= ALREADY_INSIDE=yes check
 endif
endif
endif

It is both more explicit and saner, imo.


As a last note: if tests do not introduce new dependencies *and* are 
quick to build, it is fine to build them by default from a packager’s 
point of view (but not with a check_ vs. noinst_ hack).
But please, do not tell me “it will make people keep them up-to-date”. 
They should be *already*, since people *should* run (and thus build) 
them. Also, having them broken clearly states “we don’t care about 
them”, which is sane if upstream really do not care.


--

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

Re: [PATCH weston 2/5] tests: use variable for test name in weston-tests-env

[sardemff7+wayland]

On 11/09/2013 07:58, Peter Hutterer wrote:

Slightly more readable and makes it easier to switch to use $2 for something
in the future (if that's ever needed).


I have a series to remove that script, making it more integrated with 
autotools.




---
  tests/weston-tests-env | 17 -
  1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/tests/weston-tests-env b/tests/weston-tests-env
index 2e5fa95..b732250 100755
--- a/tests/weston-tests-env
+++ b/tests/weston-tests-env
@@ -1,5 +1,12 @@
  #!/bin/bash

+TESTNAME=$1
+
+if test -z "$TESTNAME"; then
+   echo "usage: $(basename $0) "
+   exit 1;
+fi
+
  WESTON=$abs_builddir/../src/weston
  LOGDIR=$abs_builddir/logs

@@ -18,17 +25,17 @@ else
BACKEND=$abs_builddir/../src/.libs/wayland-backend.so
  fi

-case $1 in
+case $TESTNAME in
*.la|*.so)
$WESTON --backend=$BACKEND \
-   --socket=test-$(basename $1) \
-   --modules=$abs_builddir/.libs/${1/.la/.so},xwayland.so \
+   --socket=test-$(basename $TESTNAME) \
+   
--modules=$abs_builddir/.libs/${TESTNAME/.la/.so},xwayland.so \
--log="$SERVERLOG" \
&> "$OUTLOG"
;;
*)
-   WESTON_TEST_CLIENT_PATH=$abs_builddir/$1 $WESTON \
-   --socket=test-$(basename $1) \
+   WESTON_TEST_CLIENT_PATH=$abs_builddir/$TESTNAME $WESTON \
+   --socket=test-$(basename $TESTNAME) \
--backend=$BACKEND \
--log="$SERVERLOG" \

--modules=$abs_builddir/.libs/weston-test.so,xwayland.so \




--

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

Re: [PATCH weston 1/5] tests: always build tests

[sardemff7+wayland]

On 11/09/2013 07:58, Peter Hutterer wrote:

check_PROGRAMS and friends are only built during make check.


Which is perfectly fine.


> Which is a

great way of introducing compiler errors in tests.


Agree, but we should fix the workflow, not some arbitrary “problem”.


> Always build them, TESTS

defines what's being run during make check.


That’s wrong. The check_* vars are meant this way to avoid forcing 
test-only dependencies if you disable tests and to allow one to test her 
code *before* updating the tests.
Packagers tend to “fix” that the other way around (moving tests from 
noinst_ to check_) quite often…



---
  tests/Makefile.am | 12 
  1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 82bf630..398a275 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -29,18 +29,14 @@ clean-local:
  export abs_builddir

  noinst_LTLIBRARIES =  \
-   $(weston_test)
+   $(weston_test)  \
+   $(module_tests)

  noinst_PROGRAMS = \
$(setbacklight) \
-   matrix-test
-
-check_LTLIBRARIES =\
-   $(module_tests)
-
-check_PROGRAMS =   \
$(shared_tests) \
-   $(weston_tests)
+   $(weston_tests) \
+   matrix-test

  AM_CFLAGS = $(GCC_CFLAGS)
  AM_CPPFLAGS = \




--

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

Re: [RFC] compositor-drm: Add hardware accelerated capture of screen using libva

[sardemff7+wayland]

On 30/08/2013 06:37, Kristian Høgsberg wrote:

On Fri, Aug 23, 2013 at 05:15:48PM +0300, Ander Conselvan de Oliveira wrote:

+PKG_CHECK_MODULES(LIBVA, [libva >= 0.34.0 libva-drm >= 0.34.0], 
[have_libva=yes], [have_libva=no])
+AS_IF([test "x$have_libva" = "xyes"],
+  [AC_DEFINE([HAVE_LIBVA], [1], [Have libva])])
+AM_CONDITIONAL(ENABLE_LIBVA, test "x$have_libva" = "xyes")


Before merging it, this part should be modified. There are already too 
much automagic features in this configure.ac. Please add a switch to 
enable and disable this feature not based on detection. Packagers will 
love you.


Cheers,

--

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

Re: [PATCH weston sdk v2 1/8] weston.pc: Add dependencies for pixman-1 and xkbcommon

[sardemff7+wayland]

On 04/07/2013 18:25, Thiago Macieira wrote:

On quinta-feira, 4 de julho de 2013 10.12.05, Pekka Paalanen wrote:

On Wed, 3 Jul 2013 18:26:06 -0400

No, it has to be plain Requires.  By having pixman and libxkbcommon
headers in our SDK headers, we expose those dependencies to
applications.


Hi,

could you explain that logic a bit more?

Is it just a convention to use Requires for header dependencies instead
of Requires.private, or does simply including SDK headers in a project
actually add a hard link time requirement to these libs, or are
Requires being used for distribution package dependencies while
Requires.private are not?


It's not a convention. This is required for proper builds to work.


No. Check my previous mail on this issue, please.



Suppose that our headers #include headers from a project whose headers aren't
usually in /usr/include (that is, they require -I). In order for our users'
applications to build, they need to add those -I as well. The Requires is what
tells pkg-config to add them.


Requires.private too.



What's more, even if the include paths are not an issue, the linking could be.
Since we included some third party API in our API, it's conceivable that users
might need to call functions in those libraries. If that happens, then user
applications must also link directly to the libraries, not indirectly only.


And they must link directly! That is the proper way to do that. 
Providing API using these libraries does not mean forcing anyone to use 
that. And using a library does require linking to it. Hiding this 
dependency inside "libweston" is error-prone. I was going to speak 
conditionally, but now it is the case so check that:
A plugin is using libxkbcommon for a feature, but provides several more. 
Weston is build with libxkbcommon support. All is fine.
Now, the same plugin is build against a non-libxkbcommon Weston (this is 
the now-possible case): it will break badly.

Explicit usage is the way. Period.



Requires.private is used to list other packages that are "privately" used.
That is, libraries and frameworks that are not exposed in the API, which means
that users our *our* API will not be exposed to the third-party API, so they
won't need the -I/-L/-l flags at all.


Sure, but read this pkg-config guide too: 
http://people.freedesktop.org/~dbn/pkg-config-guide.html




You may ask then, why list at all the privates? Well, there's one case where
the user needs the -L/-l flags: when our API is provided as a static library.
It's probably not going to be the case for Weston, since the point of linking
is to provide plugins and those make no sense in static builds.


The point will be when libweston will exist.


--

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

Re: xserver problems

[sardemff7+wayland]

On 03/07/2013 10:19, Bill Spitzak wrote:

I am really interested in knowing if other people are seeing this problem.

If this is due to the wlshm driver I would be able to try to fix this.
If this is for all xserver users then I suspect I do not have enough
knowledge to fix it however.

Bill Spitzak wrote:

For the last 2 months running x applications under wayland is
producing black windows, but if you resize them you get screwed up
window borders (in attached picture).

It also appears that the image does not update until the event *after*
the one that caused the window to change. For instance if you push a
button, the button does not draw pushed-in until the mouse is moved.

Are these known problems or is something wrong with my setup?


I can reproduce it with wlshm. With Intel DDX, it works fine.

I am using my rebased branches, so with Xorg server 1.15.
http://git.sardemff7.net/wayland/

--

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

Re: [PATCH] build: disabling the mtdev library support

[sardemff7+wayland]

On 25/06/2013 17:59, Marc Chalain wrote:

2013/6/25 


On 25/06/2013 17:28, mchalain [marc.chal...@gmail.com] wrote:


From: mchalain 






AC_CHECK_LIB([jpeg], [jpeg_CreateDecompress], have_jpeglib=yes)

   if test x$have_jpeglib = xyes; then
 JPEG_LIBS="-ljpeg"
@@ -259,8 +269,8 @@ AS_IF([test "x$enable_resize_optimization" = "xyes"],
 [AC_DEFINE([USE_RESIZE_POOL], [1], [Use resize memory pool as a
performance optimization])])

   AC_ARG_ENABLE(weston-launch, [  --enable-weston-launch],,
enable_weston_launch=yes)
-AM_CONDITIONAL(BUILD_WESTON_**LAUNCH, test x$enable_weston_launch ==
xyes)
-if test x$enable_weston_launch == xyes; then
+AM_CONDITIONAL(BUILD_WESTON_**LAUNCH, test x$enable_weston_launch =
xyes)
+if test x$enable_weston_launch = xyes; then
 PKG_CHECK_MODULES(WESTON_**LAUNCH, [libdrm])
 PKG_CHECK_MODULES(SYSTEMD_**LOGIN, [libsystemd-login],
 [have_systemd_login=yes], [have_systemd_login=no])



You should remove that hunk (git checkout -p).


Yes but it's a bug already exiting


Then please submit it in its own patch. :-)


--

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

Re: [PATCH] build: disabling the mtdev library support

[sardemff7+wayland]

On 25/06/2013 17:28, mchalain [marc.chal...@gmail.com] wrote:

From: mchalain 

This patch creates the --enable-mtdev configure's option with
"auto" as default value.
If mtdv library is not available the mtdev functions are replaced
by empty macros.
To simplify the Makefile.am evdev source files are placed inside
a static library. The other reason of this modification is to
see the link between evdev code and mtdev library from the Makefile
---
  configure.ac|   20 +++-
  src/Makefile.am |   27 ++-
  src/evdev.c |   11 ---
  3 files changed, 37 insertions(+), 21 deletions(-)

diff --git a/configure.ac b/configure.ac
index b625221..4bfce58 100644
--- a/configure.ac
+++ b/configure.ac
@@ -132,7 +132,7 @@ AC_ARG_ENABLE(drm-compositor, [  --enable-drm-compositor],,
  AM_CONDITIONAL(ENABLE_DRM_COMPOSITOR, test x$enable_drm_compositor = xyes -a 
x$enable_egl = xyes)
  if test x$enable_drm_compositor = xyes -a x$enable_egl = xyes; then
AC_DEFINE([BUILD_DRM_COMPOSITOR], [1], [Build the DRM compositor])
-  PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm mtdev 
>= 1.1.0])
+  PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm])
  fi


@@ -161,7 +161,7 @@ AM_CONDITIONAL(ENABLE_RPI_COMPOSITOR, test "x$enable_rpi_compositor" 
= "xyes")
  have_bcm_host="no"
  if test "x$enable_rpi_compositor" = "xyes"; then
AC_DEFINE([BUILD_RPI_COMPOSITOR], [1], [Build the compositor for Raspberry 
Pi])
-  PKG_CHECK_MODULES(RPI_COMPOSITOR, [libudev >= 136 mtdev >= 1.1.0])
+  PKG_CHECK_MODULES(RPI_COMPOSITOR, [libudev >= 136])
PKG_CHECK_MODULES(RPI_BCM_HOST, [bcm_host],
  [have_bcm_host="yes"
   AC_DEFINE([HAVE_BCM_HOST], [1], [have Raspberry Pi BCM 
headers])],
@@ -176,7 +176,7 @@ AM_CONDITIONAL([ENABLE_FBDEV_COMPOSITOR],
 [test x$enable_fbdev_compositor = xyes])
  AS_IF([test x$enable_fbdev_compositor = xyes], [
AC_DEFINE([BUILD_FBDEV_COMPOSITOR], [1], [Build the fbdev compositor])
-  PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev >= 136 mtdev >= 1.1.0])
+  PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev >= 136 ])
  ])

  AC_ARG_ENABLE([rdp-compositor], [  --enable-rdp-compositor],,
@@ -203,6 +203,16 @@ PKG_CHECK_MODULES(WEBP, [libwebp], [have_webp=yes], 
[have_webp=no])
  AS_IF([test "x$have_webp" = "xyes"],
[AC_DEFINE([HAVE_WEBP], [1], [Have webp])])

+AC_ARG_ENABLE(mtdev,
+  AS_HELP_STRING([--disable-mtdev],
+ [do not support multitouch library libmtdev]),,
+ enable_mtdev=auto)
+if test "x$enable_mtdev" != "xno"; then
+   PKG_CHECK_MODULES(MTDEV, [mtdev >= 1.1.0], [have_mtdev=yes], 
[have_mtdev=no])
+   AS_IF([test "x$have_mtdev" = "xyes"],
+ [AC_DEFINE([HAVE_MTDEV], [1], [Have Multitouch device 
support])])
+fi
+


Again, please put an AC_MSG_ERROR if it is explicitly enabled and the 
library is not found.




  AC_CHECK_LIB([jpeg], [jpeg_CreateDecompress], have_jpeglib=yes)
  if test x$have_jpeglib = xyes; then
JPEG_LIBS="-ljpeg"
@@ -259,8 +269,8 @@ AS_IF([test "x$enable_resize_optimization" = "xyes"],
[AC_DEFINE([USE_RESIZE_POOL], [1], [Use resize memory pool as a 
performance optimization])])

  AC_ARG_ENABLE(weston-launch, [  --enable-weston-launch],, 
enable_weston_launch=yes)
-AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch == xyes)
-if test x$enable_weston_launch == xyes; then
+AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch = xyes)
+if test x$enable_weston_launch = xyes; then
PKG_CHECK_MODULES(WESTON_LAUNCH, [libdrm])
PKG_CHECK_MODULES(SYSTEMD_LOGIN, [libsystemd-login],
[have_systemd_login=yes], [have_systemd_login=no])


You should remove that hunk (git checkout -p).



diff --git a/src/Makefile.am b/src/Makefile.am
index d06e773..b16bc80 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -100,6 +100,7 @@ module_LTLIBRARIES =\
$(tablet_shell) \
$(cms_static)   \
$(cms_colord)   \
+   $(libevdev) \
$(x11_backend)  \
$(drm_backend)  \
$(wayland_backend)  \


No, it is not a module, you must use noinst_LTLIBRARIES here, see below.



@@ -129,11 +130,20 @@ x11_backend_la_CFLAGS =   \
  x11_backend_la_SOURCES = compositor-x11.c
  endif

+libevdev = libevdev.la


noinst_LTLIBRARIES += libevdev.la



+libevdev_la_LIBADD = $(MTDEV_LIBS)
+evdev_la_CFLAGS =  \
+   $(MTDEV_CFLAGS)
+libevdev_la_SOURCES =  \
+   evdev.c \
+   evdev.h \
+   evdev-touchpad.c
+   
  if ENABLE_DRM_COMPOSITOR
  drm_backend = drm-backend.l

Re: [PATCH 03/18] evdev: automatic configuration of mtdev library support

[sardemff7+wayland]

On 21/06/2013 11:52, Marc Chalain wrote:

2013/6/21 


On 21/06/2013 10:39, mchalain [marc.chal...@gmail.com] wrote:


From: mchalain 

   it allows the --disable-mtdev option at configuration.
   evdev.c creates empty macros for mtdev functions not availlables

---
   weston/configure.ac |   17 ++---
   weston/src/evdev.c  |   11 ---
   2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/weston/configure.ac b/weston/configure.ac
index b625221..2bdff35 100644
--- a/weston/configure.ac
+++ b/weston/configure.ac
@@ -132,7 +132,7 @@ AC_ARG_ENABLE(drm-compositor, [
  --enable-drm-compositor],,
   AM_CONDITIONAL(ENABLE_DRM_**COMPOSITOR, test x$enable_drm_compositor =
xyes -a x$enable_egl = xyes)
   if test x$enable_drm_compositor = xyes -a x$enable_egl = xyes; then
 AC_DEFINE([BUILD_DRM_**COMPOSITOR], [1], [Build the DRM compositor])
-  PKG_CHECK_MODULES(DRM_**COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30
gbm mtdev >= 1.1.0])
+  PKG_CHECK_MODULES(DRM_**COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30
gbm])
   fi


@@ -161,7 +161,7 @@ AM_CONDITIONAL(ENABLE_RPI_**COMPOSITOR, test
"x$enable_rpi_compositor" = "xyes")
   have_bcm_host="no"
   if test "x$enable_rpi_compositor" = "xyes"; then
 AC_DEFINE([BUILD_RPI_**COMPOSITOR], [1], [Build the compositor for
Raspberry Pi])
-  PKG_CHECK_MODULES(RPI_**COMPOSITOR, [libudev >= 136 mtdev >= 1.1.0])
+  PKG_CHECK_MODULES(RPI_**COMPOSITOR, [libudev >= 136])
 PKG_CHECK_MODULES(RPI_BCM_**HOST, [bcm_host],
   [have_bcm_host="yes"
AC_DEFINE([HAVE_BCM_HOST], [1], [have Raspberry Pi
BCM headers])],
@@ -176,7 +176,7 @@ AM_CONDITIONAL([ENABLE_FBDEV_**COMPOSITOR],
  [test x$enable_fbdev_compositor = xyes])
   AS_IF([test x$enable_fbdev_compositor = xyes], [
 AC_DEFINE([BUILD_FBDEV_**COMPOSITOR], [1], [Build the fbdev
compositor])
-  PKG_CHECK_MODULES([FBDEV_**COMPOSITOR], [libudev >= 136 mtdev >=
1.1.0])
+  PKG_CHECK_MODULES([FBDEV_**COMPOSITOR], [libudev >= 136 ])
   ])

   AC_ARG_ENABLE([rdp-compositor]**, [  --enable-rdp-compositor],,
@@ -203,6 +203,17 @@ PKG_CHECK_MODULES(WEBP, [libwebp], [have_webp=yes],
[have_webp=no])
   AS_IF([test "x$have_webp" = "xyes"],
 [AC_DEFINE([HAVE_WEBP], [1], [Have webp])])

+AC_ARG_ENABLE(mtdev,
+  AS_HELP_STRING([--disable-**mtdev],
+ [do not support multitouch library
libmtdev]),,
+ enable_mtdev=auto)
+AM_CONDITIONAL(ENABLE_MTDEV, test "x$enable_mtdev" = "xyes")



If you do not use this, you should probably not set it.







  +if test "x$enable_mtdev" != "xno"; then

+   PKG_CHECK_MODULES(MTDEV, [mtdev >= 1.1.0], [have_mtdev=yes],
[have_mtdev=no])



Where do you use MTDEV_{CFLAGS,LIBS}?


Nowhere at this moment. But I don't know the future and this was done in
the prevsious version.


Why do you removed this usage then? I’m not sure what you mean by that. 
If you don’t know the future, you should even more use the provided 
flags. Specifically the LIBS so that mtdev is properly linked everywhere 
is it used. (And CFLAGS in case headers are not in a default location.)






  +   AS_IF([test "x$have_mtdev" = "xyes"],

+ [AC_DEFINE([HAVE_MTDEV], [1], [Have Multitouch device
support])])



What if the user specified --enable-mtdev but the package is not
available? It should be an error, not a silent ignore. :-)



If you set  --enable-mtde, you know that mtdev is available. After the
automatic check is the normal way in my opinion.


Not at all. You want mtdev support, but you might have missed the 
installation. Also, we (packagers) want to ensure that a specific 
feature has all its deps checked. Please, add an error if $enable_mtdev 
is yes and $have_mtdev is no. :-)





  +fi

+
   AC_CHECK_LIB([jpeg], [jpeg_CreateDecompress], have_jpeglib=yes)
   if test x$have_jpeglib = xyes; then
 JPEG_LIBS="-ljpeg"
diff --git a/weston/src/evdev.c b/weston/src/evdev.c
index 122a2d9..59af038 100644
--- a/weston/src/evdev.c
+++ b/weston/src/evdev.c
@@ -27,7 +27,15 @@
   #include 
   #include 
   #include 
+#ifdef HAVE_MTDEV
   #include 
+#else
+struct mtdev
+{ int none;};
+#define mtdev_close_delete(...) do{}while(0)
+#define mtdev_get(...) 0
+#define mtdev_new_open(...) NULL
+#endif

   #include "compositor.h"
   #include "evdev.h"
@@ -565,11 +573,8 @@ evdev_device_create(struct weston_seat *seat, const
char *path, int device_fd)
 if (device->dispatch == NULL)
 goto err1;

-
 if (device->is_mt) {
 device->mtdev = mtdev_new_open(device->fd);
-   if (!device->mtdev)
-   weston_log("mtdev failed to open for %s\n", path);



IMO, it should still log it if mtdev support is enabled.



  }


 device->source = wl_event_loop_add_fd(ec->**input_loop,
device->fd,




--

Quentin “Sardem FF7” Glidic






--

Quentin “Sardem FF7” Glidic
___

Re: [PATCH 03/18] evdev: automatic configuration of mtdev library support

[sardemff7+wayland]

On 21/06/2013 10:39, mchalain [marc.chal...@gmail.com] wrote:

From: mchalain 

  it allows the --disable-mtdev option at configuration.
  evdev.c creates empty macros for mtdev functions not availlables

---
  weston/configure.ac |   17 ++---
  weston/src/evdev.c  |   11 ---
  2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/weston/configure.ac b/weston/configure.ac
index b625221..2bdff35 100644
--- a/weston/configure.ac
+++ b/weston/configure.ac
@@ -132,7 +132,7 @@ AC_ARG_ENABLE(drm-compositor, [  --enable-drm-compositor],,
  AM_CONDITIONAL(ENABLE_DRM_COMPOSITOR, test x$enable_drm_compositor = xyes -a 
x$enable_egl = xyes)
  if test x$enable_drm_compositor = xyes -a x$enable_egl = xyes; then
AC_DEFINE([BUILD_DRM_COMPOSITOR], [1], [Build the DRM compositor])
-  PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm mtdev 
>= 1.1.0])
+  PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm])
  fi


@@ -161,7 +161,7 @@ AM_CONDITIONAL(ENABLE_RPI_COMPOSITOR, test "x$enable_rpi_compositor" 
= "xyes")
  have_bcm_host="no"
  if test "x$enable_rpi_compositor" = "xyes"; then
AC_DEFINE([BUILD_RPI_COMPOSITOR], [1], [Build the compositor for Raspberry 
Pi])
-  PKG_CHECK_MODULES(RPI_COMPOSITOR, [libudev >= 136 mtdev >= 1.1.0])
+  PKG_CHECK_MODULES(RPI_COMPOSITOR, [libudev >= 136])
PKG_CHECK_MODULES(RPI_BCM_HOST, [bcm_host],
  [have_bcm_host="yes"
   AC_DEFINE([HAVE_BCM_HOST], [1], [have Raspberry Pi BCM 
headers])],
@@ -176,7 +176,7 @@ AM_CONDITIONAL([ENABLE_FBDEV_COMPOSITOR],
 [test x$enable_fbdev_compositor = xyes])
  AS_IF([test x$enable_fbdev_compositor = xyes], [
AC_DEFINE([BUILD_FBDEV_COMPOSITOR], [1], [Build the fbdev compositor])
-  PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev >= 136 mtdev >= 1.1.0])
+  PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev >= 136 ])
  ])

  AC_ARG_ENABLE([rdp-compositor], [  --enable-rdp-compositor],,
@@ -203,6 +203,17 @@ PKG_CHECK_MODULES(WEBP, [libwebp], [have_webp=yes], 
[have_webp=no])
  AS_IF([test "x$have_webp" = "xyes"],
[AC_DEFINE([HAVE_WEBP], [1], [Have webp])])

+AC_ARG_ENABLE(mtdev,
+  AS_HELP_STRING([--disable-mtdev],
+ [do not support multitouch library libmtdev]),,
+ enable_mtdev=auto)
+AM_CONDITIONAL(ENABLE_MTDEV, test "x$enable_mtdev" = "xyes")


If you do not use this, you should probably not set it.



+if test "x$enable_mtdev" != "xno"; then
+   PKG_CHECK_MODULES(MTDEV, [mtdev >= 1.1.0], [have_mtdev=yes], 
[have_mtdev=no])


Where do you use MTDEV_{CFLAGS,LIBS}?



+   AS_IF([test "x$have_mtdev" = "xyes"],
+ [AC_DEFINE([HAVE_MTDEV], [1], [Have Multitouch device 
support])])


What if the user specified --enable-mtdev but the package is not 
available? It should be an error, not a silent ignore. :-)




+fi
+
  AC_CHECK_LIB([jpeg], [jpeg_CreateDecompress], have_jpeglib=yes)
  if test x$have_jpeglib = xyes; then
JPEG_LIBS="-ljpeg"
diff --git a/weston/src/evdev.c b/weston/src/evdev.c
index 122a2d9..59af038 100644
--- a/weston/src/evdev.c
+++ b/weston/src/evdev.c
@@ -27,7 +27,15 @@
  #include 
  #include 
  #include 
+#ifdef HAVE_MTDEV
  #include 
+#else
+struct mtdev
+{ int none;};
+#define mtdev_close_delete(...) do{}while(0)
+#define mtdev_get(...) 0
+#define mtdev_new_open(...) NULL
+#endif

  #include "compositor.h"
  #include "evdev.h"
@@ -565,11 +573,8 @@ evdev_device_create(struct weston_seat *seat, const char 
*path, int device_fd)
if (device->dispatch == NULL)
goto err1;

-
if (device->is_mt) {
device->mtdev = mtdev_new_open(device->fd);
-   if (!device->mtdev)
-   weston_log("mtdev failed to open for %s\n", path);


IMO, it should still log it if mtdev support is enabled.



}

device->source = wl_event_loop_add_fd(ec->input_loop, device->fd,




--

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

Re: [PATCH weston 6/7] weston.ini: Allow a relative path for input-method

[sardemff7+wayland]

On 18/06/2013 09:11, Quentin Glidic wrote:

From: Quentin Glidic 

Signed-off-by: Quentin Glidic 
---
  man/Makefile.am| 1 +
  man/weston.ini.man | 3 ++-
  src/text-backend.c | 8 
  weston.ini | 2 +-
  4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/man/Makefile.am b/man/Makefile.am
index 37174e2..b3a3881 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -6,6 +6,7 @@ endif

  MAN_SUBSTS = \
-e 's|__weston_native_backend__|$(WESTON_NATIVE_BACKEND)|g' \
+   -e 's|__weston_libexec_dir__|$(pkglibexecdir)|g' \
-e 's|__weston_modules_dir__|$(moduledir)|g' \
-e 's|__version__|$(PACKAGE_VERSION)|g'

diff --git a/man/weston.ini.man b/man/weston.ini.man
index c3e5747..e348c44 100644
--- a/man/weston.ini.man
+++ b/man/weston.ini.man
@@ -290,8 +290,9 @@ be one of the following 8 strings:
  .RE
  .SH "INPUT-METHOD SECTION"
  .TP 7
-.BI "path=" "/usr/libexec/weston-keyboard"
+.BI "path=" "/usr/libexec/weston/weston-keyboard"
  sets the path of the on screen keyboard input method (string).
+May be relative to __weston_libexec_dir__.
  .RE
  .RE
  .SH "KEYBOARD SECTION"
diff --git a/src/text-backend.c b/src/text-backend.c
index e078e3f..316b2c3 100644
--- a/src/text-backend.c
+++ b/src/text-backend.c
@@ -25,6 +25,7 @@

  #include 
  #include 
+#include 
  #include 
  #include 

@@ -916,12 +917,19 @@ static void
  text_backend_configuration(struct text_backend *text_backend)
  {
struct weston_config_section *section;
+   char path[PATH_MAX];

section = weston_config_get_section(text_backend->compositor->config,
"input-method", NULL, NULL);
weston_config_section_get_string(section, "path",
 &text_backend->input_method.path,
 PKGLIBEXECDIR "/weston-keyboard");
+   if (text_backend->input_method.path[0] != '/') {
+   snprintf(path, sizeof path, "%s/%s", PKGLIBEXECDIR, 
text_backend->input_method.path);
+   free(text_backend->input_method.path);
+   text_backend->input_method.path = strdup(path);
+   }
+   text_backend->input_method.path = path;


Of course this last line is a leftover. My bad.
Commit fixed locally.


  }

  static void
diff --git a/weston.ini b/weston.ini
index f2abceb..a9ddbc9 100644
--- a/weston.ini
+++ b/weston.ini
@@ -40,7 +40,7 @@ path=/usr/libexec/weston-screensaver
  duration=600

  [input-method]
-path=/usr/libexec/weston-keyboard
+path=weston-keyboard

  #[output]
  #name=LVDS1




--

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

Re: minimized and stick windows

[sardemff7+wayland]

On 12/06/2013 21:39, Bill Spitzak wrote:



Shell surface types, exclusive: - top-level - transient (umm,
what was this for, again?) - popup (menu?)


Transcient is for dialog (modal?) boxes, isn’t it?


It means "this window stays above another one".

Transient cannot be a type, but instead a state of a surface. It has
to be done by setting a "parent surface" which means that the
compositor keeps the surface above the parent. It does not imply
anything else, in particular the client decides whether either
surface is currently visible.


It can be a type as long as we allow type switching. Regarding the types
we more or less agreed on already, thas sounds sensible to me.



The client has to be able to arbitrarily rearrange the parent
pointers. This means it can set them to null (since otherwise it is
not possible to get all rearrangements if the compositor rejects any
attempts that make a loop). Therefore a "transient surface" can
become a "main surface" and thus they must be the same object.

This is a requirement so that non-trivial clients can be written
that are not forced to blink the transient windows to change their
parenting.


Do you have a use case for this scenario ? There are probably some I 
cannot see, but maybe could we solve them another way.




Popups are also transient windows (and thus normal windows) but they
have some effects on event delivery when they are first mapped.


Same question, do you have a use case for a popup surface that you would
reparent? For our current use case (menus, do we have another one?) this 
is unlikely (afaict, I am not a toolkit guy).



Thanks,

--

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

Re: minimized and stick windows

[sardemff7+wayland]

On 12/06/2013 11:18, Pekka Paalanen wrote:

On Wed, 12 Jun 2013 10:23:33 +0200
sardemff7+wayl...@sardemff7.net wrote:


On 12/06/2013 09:57, Pekka Paalanen wrote:

To get the big picture, let me reiterate the surface classification as
a whole, the way I see it.

Surface roles, exclusive:
- cursor
- drag icon
- shell surface


Each role is an interface then? Simple and efficient, I love it.


No, a role is just a concept. In protocol it is currently assigned by
passing the wl_surface as an argument for a specific request, that
assigns the role.

Only shell surface has a new interface associated, IIRC.


That’s fine: if the role is complex enough, put it in an interface.



Shell surface types, exclusive:
- top-level
- transient (umm, what was this for, again?)
- popup (menu?)


Transcient is for dialog (modal?) boxes, isn’t it?


Tooltips and alike, rather.


Ok, so we should add something here for modal dialogs.


[snip]

Protocol-wise, this means that requests set_maximized and
set_fullscreen would be deprecated as is, and replaced with the state
setting request. Request set_toplevel would deprecate the part of its
behaviour where it changes a surface into normal state.

We cannot remove the deprecated functionality, I believe, so it must be
kept working, and just plumbed into the new kind of internal state
change machinery inside weston.

However, it's not that simple. Some states need parameters. Maximized
needs an output, and fullscreen a few things more. Always-on-top
equivalent might want a layer number or something. Therefore I'm not
sure a single set_state request will work.


At protocol level, we may be better using new interfaces.

wl_shell will gain three requests:
— get_toplevel_surface(class, title): returns a new
wl_shell_toplevel_surface
— get_transcient_surface(wl_shell_toplevel_surface): returns a
transcient one
— get_popup(wl_shell_toplevel_surface): returns a popup surface

That would duplicate some requests between the three interfaces (or
maybe two, if transcient and popup can share one).
Backward-compatibility would be both easier and harder than keeping
wl_shell_surface around, as we have to maintain a compatibility struct
in the compositor, but that would be a simple struct { type; union {
toplevel; transcient; popup; }; }.

That would allow to extend the configure event in a nice fashion, that
tiling WM will love (e.g. for decorations).


That is certainly a novel suggestion. I wonder what toolkit authors
would think.


I would probably provide patches for GTK+ at least, to test the stuff, 
and the old interface (less powerful) would still be there for a while.




Uh, I didn't mean to start another bikeshedding party, but I guess I
didn't really understand Rafael's question.


Sorry. ^^'


--

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

Re: minimized and stick windows

[sardemff7+wayland]

On 12/06/2013 09:57, Pekka Paalanen wrote:

To get the big picture, let me reiterate the surface classification as
a whole, the way I see it.

Surface roles, exclusive:
- cursor
- drag icon
- shell surface


Each role is an interface then? Simple and efficient, I love it.



Shell surface types, exclusive:
- top-level
- transient (umm, what was this for, again?)
- popup (menu?)


Transcient is for dialog (modal?) boxes, isn’t it?
Each type is a one-shot request on a new created surface. Again, simple 
and efficient, love it too.

It may be a bit more clear, see below.


Top-level shell surface states, each more or less toggleable on its own:
- maximized
- fullscreen
- minimized
- sticky
- always-on-top or some equivalent layer thing
...



Does this make sense?


Yes.



That is, only a top-level surface, which we should probably be calling
as an application window, can be maximized etc., and I think the
discussion was that it can be many things at once, like maximized and
minimized.


Right, it is useful and not that hard to implement.



I don't think the states make sense as types, I would prefer the above
hierarchy. A shell surface can only have one type at a time, but the
states are not that restricted. It gives a nice tree-like hierarchy,
instead of a directed graph where several surface types can have the
same states. The tiling-WM developers would be concerned only about the
top-level shell surface states, and could hopefully support all the
shell surface types, which should make the difference between floating
and tiling WMs more manageable.


I agree.



Protocol-wise, this means that requests set_maximized and
set_fullscreen would be deprecated as is, and replaced with the state
setting request. Request set_toplevel would deprecate the part of its
behaviour where it changes a surface into normal state.

We cannot remove the deprecated functionality, I believe, so it must be
kept working, and just plumbed into the new kind of internal state
change machinery inside weston.

However, it's not that simple. Some states need parameters. Maximized
needs an output, and fullscreen a few things more. Always-on-top
equivalent might want a layer number or something. Therefore I'm not
sure a single set_state request will work.


At protocol level, we may be better using new interfaces.

wl_shell will gain three requests:
— get_toplevel_surface(class, title): returns a new 
wl_shell_toplevel_surface
— get_transcient_surface(wl_shell_toplevel_surface): returns a 
transcient one

— get_popup(wl_shell_toplevel_surface): returns a popup surface

That would duplicate some requests between the three interfaces (or 
maybe two, if transcient and popup can share one).
Backward-compatibility would be both easier and harder than keeping 
wl_shell_surface around, as we have to maintain a compatibility struct 
in the compositor, but that would be a simple struct { type; union { 
toplevel; transcient; popup; }; }.


That would allow to extend the configure event in a nice fashion, that 
tiling WM will love (e.g. for decorations).



Anyway, that's just what came to my mind now. I don't recall any of the
earlier discussions anymore, maybe there were solutions to some of
these issues, maybe not.

Did we ever discuss the possiblity of fullscreen being a special kind
of maximized, btw? If you look at the state list above, everything is
orthogonal (toggleable independently) except maximized vs. fullscreen.
This is just as a concept, how it maps into protocol is a different
matter.


Fullscreen, especially for games, is a completely different thing (e.g. 
modesetting). We can have two cases here: “basic” fullscreen, which is 
just maximize with panel removed (and the app will use the normal 
decoration mechanism here, no fullscreen state), and plain fullscreen, 
which would be another surface type.
I *think* most apps (games) already have heavy switching, so destroying 
and creating a new surface should not be a problem here, imo.



Cheers,

--

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

Re: Things that killed my motivation to play with wayland

[sardemff7+wayland]

On 12/06/2013 02:49, dar...@chaosreigns.com wrote:

1) This mesa bug:  https://bugs.freedesktop.org/show_bug.cgi?id=61919
make fails without C_INCLUDE_PATH set.  It pretty much destroyed my build
testing setup (I was build testing 46 related repos every few hours).
I never managed to work out the obvious workaround of just setting
C_INCLUDE_PATH for mesa builds (which I had working for another repo).
I included the commit where the problem started.  Three months ago.
(Build test script I wrote: http://www.chaosreigns.com/code/buildtest/ )


I provided a patch on this one, and even if I didn’t test it, it should 
work in your case. If not, I’m willing to help, just ask me for another 
patch with some relevant logs.




2) The XWayland segfault bug:
https://bugs.freedesktop.org/show_bug.cgi?id=59983
This was the reason I stopped using weston as my primary UI at home in
September.  Tiago said he had a fix for it in one of his branches a long
time ago, but I guess it wasn't compatible with the changes made to the
plan to handle xwm.  Blows my mind that this isn't the top priority of the
project.  I'm sure there's fine reasons.  It would be nice to know what
they are.


I just rebased the full xwayland branch to xorg-server master, and also 
the intel and wlshm DDX.


http://git.sardemff7.net/wayland/xorg-server/log/?h=xwayland-1.15
http://git.sardemff7.net/wayland/xf86-video-intel/log/?h=xwayland
http://git.sardemff7.net/wayland/xf86-video-wlshm/

If Tiago can point me to the fix commit, I can include it in there, so 
we can start using a new base to hack on.




3) The state of cairo's build testing, particularly this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=62375
Cairo has a huge and glorious build test suite.  But it looked very
much to me like nobody could've gotten it to pass all tests in any
subset in years.  psychon was very helpful in tracking down and fixing
problems.  This one last bug was in the way of me being able to get a full
subset of tests to pass, so I could automate running them reasonably.
The maintainer of cairo, Chris Wilson, included a patch to fix it in a
comment to that bug, but we haven't been able to get him to commit it,
in three months.  (Lots of stuff, including weston and gtk, are heavily
dependent on cairo, which tends to break.  Which isn't surprising with
its unusable build tests.  And the fact that the build test instructions
specify a method that doesn't allow cairo-gl to be tested.)


Tests are good, but if all of them fail badly, you *can* ignore them. In 
this case, they should be fixed, but that shouldn’t prevent you from 
using cairo. IMO, you should keep trying to get the tests fixed, without 
forcing them in your test script.
I’ll try to support you and provide patches on cairo too, please point 
me to the relevant bugs.


Cheers,

--

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

Re: [PATCH] weston.pc: Added libexecdir and pkglibexecdir variables

[sardemff7+wayland]

On 11/06/2013 08:05, Pekka Paalanen wrote:

On Mon, 10 Jun 2013 14:40:19 -0300
"Eduardo Lima (Etrunko)"  wrote:


I have added the pkglibexedir in an attempt to avoid crowding libexecdir
too much. Other than that, no special reason.



Ok, so should the weston install paths be adjusted to pkglibexecdir?
Could you write a patch for that? I think it might be a good idea.


I can include it in a series to clean and move a few stuff around to 
“more standard paths” if you want.



--

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

Re: [PATCH weston v2 4/4] weston.pc: Provide moduledir

[sardemff7+wayland]

On 10/06/2013 18:23, Othman, Ossama wrote:

Hi,

--- a/src/Makefile.am

+++ b/src/Makefile.am
@@ -94,7 +94,6 @@ westoninclude_HEADERS =   \
 ../shared/matrix.h  \
 ../shared/config-parser.h

-moduledir = $(libdir)/weston
  module_LTLIBRARIES =   \



On a related note, any idea why Weston doesn't use Automake's pkglib
prefix?  The corresponding pkglibdir variable ends up having the same
value.  Is it just a convention/clarity thing?  I realize Autoconf doesn't
support pkglibdir without help.


The point of having moduledir is that we may use e.g. 
$(pkglibdir)/modules if weston shipped a real package-wide libraries.
libtoytoolkit and libshared would be in $(pkglib) if they were not 
static libraries (and having them static is good enough since they have 
only a few installed customers each).


But in this regard, we may set moduledir to $(pkglibdir) for now, or 
directly to $(pkglibdir)/modules.


I will send a patch or two on this directories’ thing.

Thanks for the comment.

--

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

Re: [PATCH] clients/nested: Fix compilation

[sardemff7+wayland]

On 04/06/2013 13:19, Armin K. wrote:

On 06/04/2013 01:19 PM, sardemff7+wayl...@sardemff7.net wrote:

On 04/06/2013 13:05, Armin K wrote:

diff --git a/clients/nested.c b/clients/nested.c
index baaff64..132724d 100644
--- a/clients/nested.c
+++ b/clients/nested.c
@@ -34,8 +34,11 @@

  #include 
  #include 
+
+#ifdef USE_CAIRO_GLESV2
  #include 
  #include 
+#endif /* USE_CAIRO_GLESV2 */

  #include 



Are you sure the nested client work with desktop GL then?




I think that this needs to be ported to GLESv2 first, since the example
calls cairo_gl_surface_create_for_texture which is GL only function (I
guess). Includes could've been removed without any problem.



Wrong guess, cairo_gl_surface_create_for_texture is provided by either 
cairo-gl or cairo-glesv2 which are using the same code.


If the nested client does not use any GLESv2 (or GL) function, it should 
then work on both. I just wanted to know if you tested with desktop GL, 
since Kristian probably developed with GLESv2.


--

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

Re: [PATCH] clients/nested: Fix compilation

[sardemff7+wayland]

On 04/06/2013 13:05, Armin K wrote:

---
  clients/Makefile.am | 2 +-
  clients/nested.c| 3 +++
  configure.ac| 1 +
  3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/clients/Makefile.am b/clients/Makefile.am
index 1379c4b..d84f575 100644
--- a/clients/Makefile.am
+++ b/clients/Makefile.am
@@ -124,7 +124,7 @@ resizor_SOURCES = resizor.c
  resizor_LDADD = libtoytoolkit.la

  nested_SOURCES = nested.c
-nested_LDADD = libtoytoolkit.la
+nested_LDADD = libtoytoolkit.la $(SERVER_LIBS)

  nested_client_SOURCES = nested-client.c
  nested_client_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm


Fine.



diff --git a/clients/nested.c b/clients/nested.c
index baaff64..132724d 100644
--- a/clients/nested.c
+++ b/clients/nested.c
@@ -34,8 +34,11 @@

  #include 
  #include 
+
+#ifdef USE_CAIRO_GLESV2
  #include 
  #include 
+#endif /* USE_CAIRO_GLESV2 */

  #include 



Are you sure the nested client work with desktop GL then?



diff --git a/configure.ac b/configure.ac
index ba1fcac..98798c9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -227,6 +227,7 @@ if test x$enable_clients = xyes; then
AC_DEFINE([BUILD_CLIENTS], [1], [Build the Wayland clients])

PKG_CHECK_MODULES(CLIENT, [wayland-client cairo >= 1.10.0 xkbcommon 
wayland-cursor])
+  PKG_CHECK_MODULES(SERVER, [wayland-server])
PKG_CHECK_MODULES(WESTON_INFO, [wayland-client])

PKG_CHECK_MODULES(POPPLER, [poppler-glib glib-2.0 gobject-2.0 gio-2.0 ],



Fine.


--

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

Re: Compiling weston now needs colord

[sardemff7+wayland]

On 30/05/2013 08:24, Michael Hasselmann wrote:

On Tue, 2013-05-28 at 22:16 -0700, Bill Spitzak wrote:

Running autogen.sh in weston with --disable-colord works to avoid this,
I suspect nothing I care about is lost this way.


I ran into the very same problems. I would have preferred if such new
dependencies were optional or if someone would explain what we will miss
if we disable them. For colord, trying to build the latest required
version from git just pulls in more dependencies that you also have to
build from git (as Bill mentioned).

It's kind of frustrating, even if weston is meant to be a playground and
thus new dependencies have to be expected.

http://wayland.freedesktop.org/building.html should be updated I guess?

ciao Michael


colord is an optional dependency: you just need to pass --disable-colord 
to ./configure (or ./autogen.sh), and it is gone.


It is not an automagic dependency (which automatically detect the 
package’s presence), because it is more work for the developer to add 
the autotools logic to do so. Also, it is much more work to make 
packagers happy (packagers hate automagic dependencies, it makes either 
more work by patching or hard-dependency on optional features).


A little configure switch, and you are done, nothing to complain about. :-)

--

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