Re: [PATCH weston v3 07/13] window: implement shm triple-buffering

[Pekka Paalanen]

On Thu, 25 Apr 2013 12:34:13 -0700
Bill Spitzak  wrote:

> Pekka Paalanen wrote:
> 
> > Triple-buffering is especially for sub-surfaces, where the
> > compositor may have one wl_buffer busy on screen, and another
> > wl_buffer busy in the sub-surface cached state due to the
> > synchronized commit mode. To be able to forcibly repaint at that
> > situation for e.g. resize, we need a third buffer.
> 
> I cannot see any difference between a subsurface waiting for a commit
> on a parent and a normal surface that has not done a commit yet.
> There is no need for triple buffering, or if there is it is not a
> subsurface requirement.

In the server, there are three slots per sub-surface, that may hold a
wl_buffer reference: the current buffer on display, the pending buffer
waiting for commit, and the cached buffer waiting for the parent commit.

Having a buffer in the pending slot does not actually count as the
buffer being reserved for the server. Instead, the current slot may
temporarily hold two buffers at the same time: before compositor
refresh cycle completes, the old current buffer may be kept by the
renderer and backend, and the new current buffer is just waiting to get
on screen.

When a sub-surface is committed (wl_surface.commit), the buffer in
pending is moved to either the current or the cache slot, depending on
the effective commit mode, and the buffer becomes reserved by the
server.

This should be clear in the protocol specification.

If the target is the cache slot, the previous buffer (if any) in the
cache slot is released. If the target is the current slot, the previous
buffer (if any) in the current slot will be released when the
compositor refresh cycle completes.

When the parent's current buffer gets replaced (that is, when the new
surface state is _applied_), each of its sub-surfaces' cached buffer is
moved to the current slot (new state is applied), depending on the
effective commit mode.

Why we should not need *four* buffers is because the application should
throttle its resizing to the server refresh cycle by using the frame
callback on one of the window's surfaces. This guarantees that the old
current buffer gets released, before the application repaints again.

Just to clarify, the four buffer case would be this:
- buffer A is currently on screen, the old current, because the
  renderer or backend needs it continuously (e.g. directly scanned out)
- buffer B is going to screen, the new current
- buffer C is in the cache slot, because it is waiting for the parent
  commit to apply state, and this sub-surface is in synchronized mode
- buffer D is being drawn into
This is a temporary state, where buffer A is soon released, but the
unthrottled client decided to draw before that, so it needs buffer D.

> What do you mean by "forcibly repaint for resize"? Resizes of windows 
> cannot happen until the client produces a new buffer with the resized 
> contents and does a commit. Otherwise it has to keep showing the old 
> buffer. Unless you really want to reproduce the biggest ugliness
> problem with X?

This is all *inside* the client. This is a toolkit patch.

The canonical use case for a sub-surface is an application, which has a
main surface, and a component in a sub-surface. The forcing is about the
application forcing the component to redraw in a new size.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v3 01/13] protocol: add sub-surfaces

[Pekka Paalanen]

On Thu, 25 Apr 2013 16:47:15 +0200
David Herrmann  wrote:

> Hi Pekka
> 
> On Thu, Apr 25, 2013 at 12:57 PM, Pekka Paalanen  wrote:
> > Add protocol for sub-surfaces, wl_subcompositor as the global interface,
> > and wl_subsurface as the per-surface interface extension.
> >
> > This patch is meant to be reverted, once sub-surfaces are moved into
> > Wayland core.
> >
> > Changes in v2:
> >
> > - Rewrite wl_subcompositor.get_subsurface description, and move mapping
> >   and commit details into wl_subsurface description. Check the wording
> >   in wl_subsurface.set_position description.
> >
> > - Add wl_subsurface.set_commit_mode request, and document it, with the
> >   commit_mode enum. Add bad_value error code for wl_subsurface.
> >
> > - Moved the protocol into Weston repository so we can land it upstream
> >   sooner for public exposure. It is to be moved into Wayland core later.
> >
> > - Add destroy requests to both wl_subcompositor and wl_subsurface, and
> >   document them. Experience has showed, that interfaces should always
> >   have a destructor unless there is a good and future-proof reason to not
> >   have it.
> >
> > Changes in v3:
> >
> > - Specify, that wl_subsurface will become inert, if the corresponding
> >   wl_surface is destroyed, instead of requiring a certain destruction
> >   order.
> >
> > - Replaced wl_subsurface.set_commit_mode with wl_subsurface.set_sync and
> >   wl_subsurface.set_desync. Parent-cached commit mode is now called
> >   synchronized, and independent mode is desynchronized. Removed
> >   commit_mode enum, and bad_vBut if we introduce other protocol operations 
> > that cause state to be applied, a recursive definition is alue error.
> >
> > - Added support for nested sub-surfaces.
> 
> Nice! \o/
> 
> > Signed-off-by: Pekka Paalanen 
> > ---
> >  clients/.gitignore  |   2 +
> >  clients/Makefile.am |   4 +
> >  clients/window.h|   1 +
> >  protocol/subsurface.xml | 236 
> > 
> >  src/.gitignore  |   3 +
> >  src/Makefile.am |   4 +
> >  src/compositor.h|   1 +
> >  tests/.gitignore|   2 +
> >  tests/Makefile.am   |   4 +
> >  9 files changed, 257 insertions(+)
> >  create mode 100644 protocol/subsurface.xml
> >
> > diff --git a/clients/.gitignore b/clients/.gitignore
> > index dcd4564..16088e8 100644
> > --- a/clients/.gitignore
> > +++ b/clients/.gitignore
> > @@ -20,6 +20,8 @@ simple-egl
> >  simple-shm
> >  simple-touch
> >  smoke
> > +subsurface-client-protocol.h
> > +subsurface-protocol.c
> >  tablet-shell-client-protocol.h
> >  tablet-shell-protocol.c
> >  text-client-protocol.h
> > diff --git a/clients/Makefile.am b/clients/Makefile.am
> > index 8c9bcd4..5f83acd 100644
> > --- a/clients/Makefile.am
> > +++ b/clients/Makefile.am
> > @@ -81,6 +81,8 @@ libtoytoolkit_la_SOURCES =\
> > window.h\
> > text-cursor-position-protocol.c \
> > text-cursor-position-client-protocol.h  \
> > +   subsurface-protocol.c   \
> > +   subsurface-client-protocol.h\
> > workspaces-protocol.c   \
> > workspaces-client-protocol.h
> >
> > @@ -185,6 +187,8 @@ BUILT_SOURCES = \
> > desktop-shell-protocol.c\
> > tablet-shell-client-protocol.h  \
> > tablet-shell-protocol.c \
> > +   subsurface-client-protocol.h\
> > +   subsurface-protocol.c   \
> > workspaces-client-protocol.h\
> > workspaces-protocol.c
> >
> > diff --git a/clients/window.h b/clients/window.h
> > index c2946d8..815b3f1 100644
> > --- a/clients/window.h
> > +++ b/clients/window.h
> > @@ -27,6 +27,7 @@
> >  #include 
> >  #include 
> >  #include "../shared/config-parser.h"
> > +#include "subsurface-client-protocol.h"
> >
> >  #define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
> >
> > diff --git a/protocol/subsurface.xml b/protocol/subsurface.xml
> > new file mode 100644
> > index 000..60b4002
> > --- /dev/null
> > +++ b/protocol/subsurface.xml
> > @@ -0,0 +1,236 @@
> > +
> > +
> > +
> > +  
> > +Copyright © 2012-2013 Collabora, Ltd.
> > +
> > +Permission to use, copy, modify, distribute, and sell this
> > +software and its documentation for any purpose is hereby granted
> > +without fee, provided that the above copyright notice appear in
> > +all copies and that both that copyright notice and this permission
> > +notice appear in supporting documentation, and that the name of
> > +the copyright holders not be used in advertising or publicity
> > +pertaining to distribution of the software without specific,
> > +written prior permission.  The copyright holders make no
> > +representations about the suitability of this software for any
> > +purpose.  It is provided

Re: [PATCH weston 2/6] weston: Allow relative paths for modules

[Pekka Paalanen]

On Tue, 23 Apr 2013 17:16:48 +0200
John Kåre Alsaker  wrote:

> You should drop the code changes since they already allow relative paths.
> You just changed it to only allow base filenames.

Paths relative to what? Looks like there is a difference.

> On Tue, Apr 23, 2013 at 2:54 PM, Quentin Glidic <
> sardemff7+wayl...@sardemff7.net> wrote:
> 
> > From: Quentin Glidic 
> >
> > Signed-off-by: Quentin Glidic 
> > ---
> >  man/weston.man   | 4 ++--
> >  src/compositor.c | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/man/weston.man b/man/weston.man
> > index a25e619..97db3c8 100644
> > --- a/man/weston.man
> > +++ b/man/weston.man
> > @@ -102,7 +102,7 @@ Load
> >  .I backend.so
> >  instead of the default backend. The file is searched for in
> >  .IR "__weston_modules_dir__" ,
> > -or you can pass an absolute path. The default backend is
> > +or you can pass a path. The default backend is
> >  .I __weston_native_backend__
> >  unless the environment suggests otherwise, see
> >  .IR DISPLAY " and " WAYLAND_DISPLAY .
> > @@ -131,7 +131,7 @@ instead of writing them to stderr.
> >  Load the comma-separated list of modules. Only used by the test
> >  suite. The file is searched for in
> >  .IR "__weston_modules_dir__" ,
> > -or you can pass an absolute path.
> > +or you can pass a path.
> >  .TP
> >  \fB\-\^S\fR\fIname\fR, \fB\-\-socket\fR=\fIname\fR
> >  Weston will listen in the Wayland socket called
> > diff --git a/src/compositor.c b/src/compositor.c
> > index 693df2c..fe51061 100644
> > --- a/src/compositor.c
> > +++ b/src/compositor.c
> > @@ -3349,7 +3349,7 @@ load_module(const char *name, const char *entrypoint)
> > char path[PATH_MAX];
> > void *module, *init;
> >
> > -   if (name[0] != '/')
> > +   if (!strchr(name, '/'))
> > snprintf(path, sizeof path, "%s/%s", MODULEDIR, name);
> > else
> > snprintf(path, sizeof path, "%s", name);

Any specific use case, like tests? I guess I should read the following
patches to find out, but that would be nice to tell in the commit
message.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 3/6] weston-test: Get the test client path from args

[Pekka Paalanen]

On Tue, 23 Apr 2013 14:54:47 +0200
Quentin Glidic  wrote:

> From: Quentin Glidic 
> 
> Signed-off-by: Quentin Glidic 
> ---
>  tests/weston-test.c| 18 --
>  tests/weston-tests-env |  3 ++-
>  2 files changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/tests/weston-test.c b/tests/weston-test.c
> index 55c5da4..c19db3a 100644
> --- a/tests/weston-test.c
> +++ b/tests/weston-test.c
> @@ -29,6 +29,7 @@
>  #include "wayland-test-server-protocol.h"
>  
>  struct weston_test {
> + char *client;
>   struct weston_compositor *compositor;
>   struct weston_layer layer;
>   struct weston_process process;
> @@ -202,19 +203,15 @@ idle_launch_client(void *data)
>   struct weston_test *test = data;
>   pid_t pid;
>   sigset_t allsigs;
> - char *path;
>  
> - path = getenv("WESTON_TEST_CLIENT_PATH");
> - if (path == NULL)
> - exit(EXIT_FAILURE);
>   pid = fork();
>   if (pid == -1)
>   exit(EXIT_FAILURE);
>   if (pid == 0) {
>   sigfillset(&allsigs);
>   sigprocmask(SIG_UNBLOCK, &allsigs, NULL);
> - execl(path, path, NULL);
> - weston_log("compositor: executing '%s' failed: %m\n", path);
> + execl(test->client, test->client, NULL);
> + weston_log("compositor: executing '%s' failed: %m\n", 
> test->client);
>   exit(EXIT_FAILURE);
>   }
>  
> @@ -229,6 +226,7 @@ module_init(struct weston_compositor *ec,
>  {
>   struct weston_test *test;
>   struct wl_event_loop *loop;
> + int i;
>  
>   test = malloc(sizeof *test);
>   if (test == NULL)
> @@ -242,6 +240,14 @@ module_init(struct weston_compositor *ec,
> test, bind_test) == NULL)
>   return -1;
>  
> + if (*argc < 2)
> + exit(EXIT_FAILURE);
> + test->client = strdup(argv[1]);
> + for (i = 1; i < *argc; ++i)
> + argv[i] = argv[i+1];
> + *argc = i-1;
> +
> +
>   loop = wl_display_get_event_loop(ec->wl_display);
>   wl_event_loop_add_idle(loop, idle_launch_client, test);
>  
> diff --git a/tests/weston-tests-env b/tests/weston-tests-env
> index 2e5fa95..8ae0bcf 100755
> --- a/tests/weston-tests-env
> +++ b/tests/weston-tests-env
> @@ -27,10 +27,11 @@ case $1 in
>   &> "$OUTLOG"
>   ;;
>   *)
> - WESTON_TEST_CLIENT_PATH=$abs_builddir/$1 $WESTON \
> + $WESTON \
>   --socket=test-$(basename $1) \
>   --backend=$BACKEND \
>   --log="$SERVERLOG" \
>   
> --modules=$abs_builddir/.libs/weston-test.so,xwayland.so \
> + $abs_builddir/$1 \
>   &> "$OUTLOG"
>  esac

Hi Quentin,

it seems quite fragile to use an anonymous argument. What if something
else used an anonymous argument, too? Who gets what will start to
depend on the module loading order.

Why not use the command line parser with a real long option?


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 4/6] shared/option-parser: Add string list options

[Pekka Paalanen]

On Tue, 23 Apr 2013 14:54:48 +0200
Quentin Glidic  wrote:

> From: Quentin Glidic 
> 
> Signed-off-by: Quentin Glidic 
> ---
>  man/weston.man |  6 +++---
>  shared/config-parser.h |  1 +
>  shared/option-parser.c | 13 +
>  src/compositor.c   | 27 ---
>  tests/weston-tests-env |  6 --
>  5 files changed, 45 insertions(+), 8 deletions(-)
> 
> diff --git a/man/weston.man b/man/weston.man
> index 97db3c8..1812be7 100644
> --- a/man/weston.man
> +++ b/man/weston.man
> @@ -127,9 +127,9 @@ Append log messages to the file
>  .I file.log
>  instead of writing them to stderr.
>  .TP
> -\fB\-\-modules\fR=\fImodule1.so,module2.so\fR
> -Load the comma-separated list of modules. Only used by the test
> -suite. The file is searched for in
> +\fB\-\-modules\fR=\fImodule.so\fR
> +Load the modules (the option may be specified multiple times).
> +Only used by the test suite. The file is searched for in
>  .IR "__weston_modules_dir__" ,
>  or you can pass a path.
>  .TP
> diff --git a/shared/config-parser.h b/shared/config-parser.h
> index 1d0ee3f..37af064 100644
> --- a/shared/config-parser.h
> +++ b/shared/config-parser.h
> @@ -59,6 +59,7 @@ enum weston_option_type {
>   WESTON_OPTION_INTEGER,
>   WESTON_OPTION_UNSIGNED_INTEGER,
>   WESTON_OPTION_STRING,
> + WESTON_OPTION_STRING_LIST,
>   WESTON_OPTION_BOOLEAN
>  };
>  
> diff --git a/shared/option-parser.c b/shared/option-parser.c
> index 023fe72..9e0a740 100644
> --- a/shared/option-parser.c
> +++ b/shared/option-parser.c
> @@ -32,6 +32,8 @@
>  static bool
>  handle_option(const struct weston_option *option, char *value)
>  {
> + char **string_list, **str;
> + int size = 0;
>   switch (option->type) {
>   case WESTON_OPTION_INTEGER:
>   * (int32_t *) option->data = strtol(value, NULL, 0);
> @@ -42,6 +44,17 @@ handle_option(const struct weston_option *option, char 
> *value)
>   case WESTON_OPTION_STRING:
>   * (char **) option->data = strdup(value);
>   return true;
> + case WESTON_OPTION_STRING_LIST:
> + string_list = * (char ***) option->data;
> + if (string_list != NULL) {
> + for (str = string_list; *str != NULL; ++str)
> + ++size;
> + }
> + string_list = realloc(string_list, (size+2) * sizeof(char *));
> + string_list[size] = strdup(value);
> + string_list[size+1] = NULL;
> + * (char ***) option->data = string_list;
> + return true;
>   case WESTON_OPTION_BOOLEAN:
>   * (int32_t *) option->data = 1;
>   return false;
> diff --git a/src/compositor.c b/src/compositor.c
> index fe51061..5296df2 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -3406,6 +3406,26 @@ load_modules(struct weston_compositor *ec, const char 
> *modules,
>   return 0;
>  }
>  
> +static int
> +load_modules_strv(struct weston_compositor *ec, char **modules,
> +   int *argc, char *argv[], const char *config_file)
> +{
> + char **module;
> + int (*module_init)(struct weston_compositor *ec,
> +int *argc, char *argv[], const char *config_file);
> +
> + if (modules == NULL)
> + return 0;
> +
> + for (module = modules; *module != NULL; ++module) {
> + module_init = load_module(*module, "module_init");
> + if (module_init)
> + module_init(ec, argc, argv, config_file);
> + }
> +
> + return 0;
> +}
> +
>  static const char xdg_error_message[] =
>   "fatal: environment variable XDG_RUNTIME_DIR is not set.\n";
>  
> @@ -3525,7 +3545,8 @@ int main(int argc, char *argv[])
>int *argc, char *argv[], const char 
> *config_file);
>   int i;
>   char *backend = NULL;
> - const char *modules = "desktop-shell.so", *option_modules = NULL;
> + const char *modules = "desktop-shell.so";
> + char **option_modules = NULL;
>   char *log = NULL;
>   int32_t idle_time = 300;
>   int32_t help = 0;
> @@ -3546,7 +3567,7 @@ int main(int argc, char *argv[])
>   { WESTON_OPTION_STRING, "backend", 'B', &backend },
>   { WESTON_OPTION_STRING, "socket", 'S', &socket_name },
>   { WESTON_OPTION_INTEGER, "idle-time", 'i', &idle_time },
> - { WESTON_OPTION_STRING, "modules", 0, &option_modules },
> + { WESTON_OPTION_STRING_LIST, "modules", 0, &option_modules },
>   { WESTON_OPTION_STRING, "log", 0, &log },
>   { WESTON_OPTION_BOOLEAN, "help", 'h', &help },
>   { WESTON_OPTION_BOOLEAN, "version", 0, &version },
> @@ -3619,7 +3640,7 @@ int main(int argc, char *argv[])
>  
>   if (load_modules(ec, modules, &argc, argv, config_file) < 0)
>   goto out;
> - if (load_modules(ec, option_modules, &argc, argv, config_file) < 0)
> + i

Re: [PATCH weston 5/6] tests: Drop weston-tests-env

[Pekka Paalanen]

On Tue, 23 Apr 2013 14:54:49 +0200
Quentin Glidic  wrote:

> From: Quentin Glidic 
> 
> Signed-off-by: Quentin Glidic 

Any explanation why doing this?

> ---
>  tests/.gitignore   | 10 +++--
>  tests/Makefile.am  | 56 
> --
>  tests/weston-tests-env | 39 ---
>  3 files changed, 44 insertions(+), 61 deletions(-)
>  delete mode 100755 tests/weston-tests-env
> 
> diff --git a/tests/.gitignore b/tests/.gitignore
> index 05bc024..fe61189 100644
> --- a/tests/.gitignore
> +++ b/tests/.gitignore
> @@ -1,13 +1,9 @@
> -logs
> -matrix-test
> +*.test
> +*.log
> +*.trs
>  setbacklight
>  test-client
>  test-text-client
>  wayland-test-client-protocol.h
>  wayland-test-protocol.c
>  wayland-test-server-protocol.h
> -text-test
> -keyboard-test
> -event-test
> -button-test
> -xwayland-test
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 2729545..453c567 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -1,36 +1,62 @@
>  TESTS = $(module_tests) $(weston_tests)
>  
> +# Keep them in sync
>  module_tests =   \
> + .libs/surface-test.so   \
> + .libs/surface-global-test.so
> +
> +module_tests_la = \
>   surface-test.la \
>   surface-global-test.la
>  
>  weston_tests =   \
> - keyboard-test   \
> - event-test  \
> - button-test \
> - text-test   \
> + keyboard.test   \
> + event.test  \
> + button.test \
> + text.test   \
>   $(xwayland_test)
>  
> -AM_TESTS_ENVIRONMENT = \
> - abs_builddir='$(abs_builddir)'; export abs_builddir;
> +TEST_WESTON  ?= $(top_builddir)/src/weston
>  
> -LOG_COMPILER = $(srcdir)/weston-tests-env
> + #ifneq ($(strip $(WAYLAND_DISPLAY)),)
> + ifdef WAYLAND_DISPLAY
> +TEST_BACKEND ?= $(top_builddir)/src/.libs/wayland-backend.so
> + else ifneq ($(strip $(DISPLAY)),)
> +TEST_BACKEND ?= $(top_builddir)/src/.libs/x11-backend.so
> + else
> +TEST_BACKEND ?= $(top_builddir)/src/.libs/headless-backend.so
> + endif
>  
> -clean-local:
> - -rm -rf logs
> +TEST_EXTENSIONS = .test .so
>  
> -# To remove when automake 1.11 support is dropped
> -export abs_builddir

Dropping automake 1.11 support should be a separate patch. It is an
important change that deserves special attention.

Or if this patch does not drop 1.11 support, you should state that in
the commit message. The first question popping to my mind, when I
looked at this patch, was: does this still work with the older automake?


Thanks,
pq

> +LOG_COMPILER = $(TEST_WESTON)
> +TEST_LOG_COMPILER = $(LOG_COMPILER)
> +SO_LOG_COMPILER = $(LOG_COMPILER)
>  
> -noinst_LTLIBRARIES = \
> - $(weston_test)
> +AM_LOG_FLAGS = \
> + --modules xwayland.so \
> + --backend $(TEST_BACKEND) \
> + --socket test-socket-$(notdir $@)
> +
> +AM_TEST_LOG_FLAGS = \
> + $(AM_LOG_FLAGS) \
> + --modules .libs/weston-test.so
> +
> +# Keep --modules as the last arg, so it grabs the test module in
> +AM_SO_LOG_FLAGS = \
> + $(AM_LOG_FLAGS) \
> + --modules
> +
> +clean-local:
> + -rm -rf logs
>  
>  noinst_PROGRAMS =\
>   $(setbacklight) \
>   matrix-test
>  
>  check_LTLIBRARIES =  \
> - $(module_tests)
> + $(module_tests_la)  \
> + $(weston_test)
>  
>  check_PROGRAMS = \
>   $(weston_tests)
> @@ -89,7 +115,7 @@ xwayland_test_SOURCES = xwayland-test.c
> $(weston_test_client_src)
>  xwayland_test_LDADD = $(weston_test_client_libs) $(XWAYLAND_TEST_LIBS)
>  
>  if ENABLE_XWAYLAND_TEST
> -xwayland_test = xwayland_test
> +xwayland_test = xwayland.test
>  endif
>  
>  matrix_test_SOURCES =\
> diff --git a/tests/weston-tests-env b/tests/weston-tests-env
> deleted file mode 100755
> index ed10d68..000
> --- a/tests/weston-tests-env
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -#!/bin/bash
> -
> -WESTON=$abs_builddir/../src/weston
> -LOGDIR=$abs_builddir/logs
> -
> -mkdir -p "$LOGDIR"
> -
> -SERVERLOG="$LOGDIR/$1-serverlog.txt"
> -OUTLOG="$LOGDIR/$1-log.txt"
> -
> -rm -f "$SERVERLOG"
> -
> -if test x$WAYLAND_DISPLAY != x; then
> - BACKEND=$abs_builddir/../src/.libs/wayland-backend.so
> -elif test x$DISPLAY != x; then
> - BACKEND=$abs_builddir/../src/.libs/x11-backend.so
> -else
> - BACKEND=$abs_builddir/../src/.libs/wayland-backend.so
> -fi
> -
> -case $1 in
> - *.la|*.so)
> - $WESTON --backend=$BACKEND \
> - --socket=test-$(basename $1) \
> - --modules=xwayland.so \
> - --modules=$abs_builddir/.libs/${1/.la/.so} \
> - --log="$SERVERLOG" \
> - &> "$OUTLOG"
> - ;;

Re: [PATCH weston 1/6] shared/option-parser: Allow spaced options

[Quentin Glidic]

On 23/04/2013 17:05, Bill Spitzak wrote:

On 04/23/2013 05:54 AM, Quentin Glidic wrote:


+You can specify short options having an argument with a following
space. Long
+options with argument can be specified either with or without an
equal sign.



-static void
+static bool
  handle_option(const struct weston_option *option, char *value)
  {


This can be called with NULL from the code below (if the option is last
on in argv with no argument after it).


@@ -62,14 +63,20 @@ parse_options(const struct weston_option *options,
  if (options[k].name &&
  argv[i][0] == '-' &&
  argv[i][1] == '-' &&
-strncmp(options[k].name, &argv[i][2], len) == 0 &&
-(argv[i][len + 2] == '=' || argv[i][len + 2] == '\0')) {
-handle_option(&options[k], &argv[i][len + 3]);
+strncmp(options[k].name, &argv[i][2], len) == 0) {
+
+if (argv[i][len + 2] == '=')
+handle_option(&options[k], &argv[i][len + 3]);


You need to check if argv[i][len + 2] == 0, if not then the option did
not match.


+else if (handle_option(&options[k], argv[i+1]))
+++i;
  break;
  } else if (options[k].short_name &&
 argv[i][0] == '-' &&
 options[k].short_name == argv[i][1]) {
-handle_option(&options[k], &argv[i][2]);
+if (argv[i][2] != '\0')
+handle_option(&options[k], &argv[i][2]);


If this returns false then it should continue parsing the next letter as
another single-letter option.


+else if (handle_option(&options[k], argv[i+1]))


I think you should also make '=' work (ie "-x=12").


I think I will just change the whole code to get a more consistent 
behaviour for all the mentioned cases.

I should add proper error checking too, to fail on missing value.

--

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/6] weston: Allow relative paths for modules

[Quentin Glidic]

On 26/04/2013 11:21, Pekka Paalanen wrote:

Any specific use case, like tests? I guess I should read the following
patches to find out, but that would be nice to tell in the commit
message.


Mostly tests and in-tree launch, to test a WIP module.

--

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/6] weston: Allow relative paths for modules

[Quentin Glidic]

On 23/04/2013 17:10, Bill Spitzak wrote:

This disallows any subdirectories in MODULEDIR. Is this ok?


Good question.



An alternative would be to use the name unchanged if it starts with
either '/' or '.' so the user can type "./foo" to get a file in the
current directory.


I’ll go this way, it sounds saner.


--

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

Re: [PATCH weston 3/6] weston-test: Get the test client path from args

[Quentin Glidic]

On 26/04/2013 11:28, Pekka Paalanen wrote:

Hi Quentin,

it seems quite fragile to use an anonymous argument. What if something
else used an anonymous argument, too? Who gets what will start to
depend on the module loading order.

Why not use the command line parser with a real long option?


I hadn’t added the spaced options at this time, so yes, better use a 
spaced option here.


--

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

Re: [PATCH weston 4/6] shared/option-parser: Add string list options

[Quentin Glidic]

On 26/04/2013 11:37, Pekka Paalanen wrote:

There's a free(option_modules) further down below, right?
What about freeing all the individual strings stored in it?



No. But no option (string) is freed while all are strdup()-ed.




Otherwise seems ok, though this does change the format of the --modules
option.


And the man page says it’s for tests only, with bothering? ;-)


--

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

Re: [PATCH weston 5/6] tests: Drop weston-tests-env

[Quentin Glidic]

On 26/04/2013 11:44, Pekka Paalanen wrote:

Any explanation why doing this?

[snip]

Dropping automake 1.11 support should be a separate patch. It is an
important change that deserves special attention.

Or if this patch does not drop 1.11 support, you should state that in
the commit message. The first question popping to my mind, when I
looked at this patch, was: does this still work with the older automake?


My main point was to remove the export hack for automake 1.11.

It also allows the user to pass additional options to weston while 
running tests, or force a backend (e.g. headless for automated build 
even if we have X around).



--

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

Re: [PATCH weston 5/6] tests: Drop weston-tests-env

[Pekka Paalanen]

On Fri, 26 Apr 2013 12:29:52 +0200
Quentin Glidic  wrote:

> On 26/04/2013 11:44, Pekka Paalanen wrote:
> > Any explanation why doing this?
> [snip]
> > Dropping automake 1.11 support should be a separate patch. It is an
> > important change that deserves special attention.
> >
> > Or if this patch does not drop 1.11 support, you should state that in
> > the commit message. The first question popping to my mind, when I
> > looked at this patch, was: does this still work with the older automake?
> 
> My main point was to remove the export hack for automake 1.11.
> 
> It also allows the user to pass additional options to weston while 
> running tests, or force a backend (e.g. headless for automated build 
> even if we have X around).

Ok, that should be in the commit message.

But, does this still work with 1.11 or not? :-)


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Midori browser should now work on Wayland

[MoD]

For testing Midori against Wayland, I use "./configure --enable-gtk3 
--disable-unique". But at present there hasn't been a WebkitGTK+ release that 
has proper wayland support. I've been using GTK3 master and the webkit patch 
from , rebased against 
WebkitGTK+ 2.0.0; some weeks ago I asked #webkitgtk+ IRC what the status of 
that bug was and didn't hear anything, but I haven't had time to look into it 
since. They may be waiting on subsurfaces so that Webkit2 (which does 
out-of-process rendering) can be supported more easily.

So technically nothing has changed recently from Midori's perspective; we're 
still just waiting on released versions of dependencies to lose their internal 
Xlib calls.

On 26 de abril de 2013 at 3:56 AM, "Chang Liu"  wrote:
>
>Sorry I CC'ed wayland-devel-request. I have to resend the mail.
>
>I tried this morning. Midori crashed on start. Both midori and
>libunique are latest git version.
>
>Backtrace:
>Launching command: '/usr/bin/gdb' --batch -ex 'set print thread-
>events
>off' -ex run -ex 'set logging on /run/user/1000/midori/gdb.bt' -ex
>'bt' --return-child-result --args midori
>[Thread debugging using libthread_db enabled]
>Using host libthread_db library "/usr/lib/libthread_db.so.1".
>
>Program received signal SIGSEGV, Segmentation fault.
>slowly_and_stupidly_obtain_
>timestamp (display=display@entry=0x71a060)
>at ./uniqueapp.c:129
>129  xwindow = XCreateWindow (xdisplay, RootWindow (xdisplay, 
>0),
>#0  slowly_and_stupidly_obtain_timestamp
>(display=display@entry=0x71a060) at ./uniqueapp.c:129
>#1  0x773870b8 in set_startup_id (startup_id=out>,
>backend=0x71b4c0) at ./uniqueapp.c:198
>#2  unique_app_set_property (gobject=0x7142d0, prop_id=out>, value=0x7fffdd60, pspec=0x78bcf0) at ./uniqueapp.c:300
>#3  0x77ba10d2 in ?? () from /usr/lib/libgobject-2.0.so.0
>#4  0x773870f8 in unique_app_constructor (gtype=7863568,
>n_params=3, params=0x77fd80) at ./uniqueapp.c:271
>#5  0x77ba2509 in g_object_newv () from 
>/usr/lib/libgobject-2.0.so.0
>#6  0x77ba2cd6 in g_object_new_valist () from
>/usr/lib/libgobject-2.0.so.0
>#7  0x77ba3044 in g_object_new () from /usr/lib/libgobject-
>2.0.so.0
>#8  0x0042ccfc in midori_app_instance_is_running ()
>#9  0x0043ffa5 in midori_normal_app_new ()
>#10 0x0042924c in main ()
>
>Looks like libunique still has reference to Xlib functions. Or am I
>doing things wrong? (Is there a build-time switch for libunique to
>change this?)
>
>
>2013/4/25  :
>>
>> I just noticed the bug for preliminary wayland support was just 
>closed.  I
>> haven't tried it.
>>
>> http://twotoasts.de/index.php/midori/
>> http://en.wikipedia.org/wiki/Midori_%28web_browser%29
>> Bug: https://bugs.launchpad.net/midori/+bug/975355
>>
>> It's based on WebKitGTK+, so maybe that should work now as well?
>>
>> - Forwarded message -
>>
>> Date: Thu, 25 Apr 2013 22:16:49 -
>> Subject: [Bug 975355] Re: Preliminary Wayland support
>>
>> ** Summary changed:
>>
>> - Wayland support
>> + Preliminary Wayland support
>>
>> ** Changed in: midori
>>Status: In Progress => Fix Released
>>
>> ** Changed in: midori
>>Importance: Undecided => Low
>>
>> --
>> You received this bug notification because you are subscribed to 
>the bug
>> report.
>> https://bugs.launchpad.net/bugs/975355
>>
>> Title:
>>   Preliminary Wayland support
>>
>> Status in Midori: Webkit Web browser:
>>   Fix Released
>>
>> Bug description:
>>   To work with wayland, gdk_x11_ calls and Xlib calls need to be 
>wrapped
>>   in build-time and run-time backend checks:
>>   http://developer.gnome.org/gtk3/3.3/ch24s02.html#id1502079
>>
>>   $ grep -r gdk_x11 .
>>   ./midori/sokoke.c:Atom save_mode_atom = 
>gdk_x11_get_xatom_by_name_for_display (
>>   ./midori/midori-browser.c: 
>gdk_x11_xatom_to_atom (XA_INTEGER),
>>
>>   $ grep -r Xlib .
>>   ./midori/main.c:#include 
>>
>>   http://wayland.freedesktop.org/gtk.html
>>
>>   The wayland backend in GTK+ 3.4 works, so as soon as these are 
>done
>>   midori should be usable with wayland.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/midori/+bug/975355/+subscriptions
>>
>>
>> - End forwarded message -
>>
>> --
>> "Will I ever learn? I hope not, I'm having too much fun."
>> - Brent "Minime" Avis, motorcycle.com
>> http://www.ChaosReigns.com
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>___
>wayland-devel mailing list
>wayland-devel@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

Re: [PATCH weston v3 01/13] protocol: add sub-surfaces

[Pekka Paalanen]

On Fri, 26 Apr 2013 12:02:52 +0300
Pekka Paalanen  wrote:

> On Thu, 25 Apr 2013 16:47:15 +0200
> David Herrmann  wrote:
> 
> > Hi Pekka
> > 
> > On Thu, Apr 25, 2013 at 12:57 PM, Pekka Paalanen  
> > wrote:
> > > Add protocol for sub-surfaces, wl_subcompositor as the global interface,
> > > and wl_subsurface as the per-surface interface extension.
> > >
> > > This patch is meant to be reverted, once sub-surfaces are moved into
> > > Wayland core.
> > >
> > > Changes in v2:
> > >
> > > - Rewrite wl_subcompositor.get_subsurface description, and move mapping
> > >   and commit details into wl_subsurface description. Check the wording
> > >   in wl_subsurface.set_position description.
> > >
> > > - Add wl_subsurface.set_commit_mode request, and document it, with the
> > >   commit_mode enum. Add bad_value error code for wl_subsurface.
> > >
> > > - Moved the protocol into Weston repository so we can land it upstream
> > >   sooner for public exposure. It is to be moved into Wayland core later.
> > >
> > > - Add destroy requests to both wl_subcompositor and wl_subsurface, and
> > >   document them. Experience has showed, that interfaces should always
> > >   have a destructor unless there is a good and future-proof reason to not
> > >   have it.
> > >
> > > Changes in v3:
> > >
> > > - Specify, that wl_subsurface will become inert, if the corresponding
> > >   wl_surface is destroyed, instead of requiring a certain destruction
> > >   order.
> > >
> > > - Replaced wl_subsurface.set_commit_mode with wl_subsurface.set_sync and
> > >   wl_subsurface.set_desync. Parent-cached commit mode is now called
> > >   synchronized, and independent mode is desynchronized. Removed
> > >   commit_mode enum, and bad_vBut if we introduce other protocol 
> > > operations that cause state to be applied, a recursive definition is alue 
> > > error.
> > >
> > > - Added support for nested sub-surfaces.
> > 
> > Nice! \o/
> > 
> > > Signed-off-by: Pekka Paalanen 
> > > ---
> > >  clients/.gitignore  |   2 +
> > >  clients/Makefile.am |   4 +
> > >  clients/window.h|   1 +
> > >  protocol/subsurface.xml | 236 
> > > 
> > >  src/.gitignore  |   3 +
> > >  src/Makefile.am |   4 +
> > >  src/compositor.h|   1 +
> > >  tests/.gitignore|   2 +
> > >  tests/Makefile.am   |   4 +
> > >  9 files changed, 257 insertions(+)
> > >  create mode 100644 protocol/subsurface.xml
> > >
...
> > > diff --git a/protocol/subsurface.xml b/protocol/subsurface.xml
> > > new file mode 100644
> > > index 000..60b4002
> > > --- /dev/null
> > > +++ b/protocol/subsurface.xml
> > > @@ -0,0 +1,236 @@
> > > +
> > > +
> > > +
> > > +  
> > > +Copyright © 2012-2013 Collabora, Ltd.
> > > +
> > > +Permission to use, copy, modify, distribute, and sell this
> > > +software and its documentation for any purpose is hereby granted
> > > +without fee, provided that the above copyright notice appear in
> > > +all copies and that both that copyright notice and this permission
> > > +notice appear in supporting documentation, and that the name of
> > > +the copyright holders not be used in advertising or publicity
> > > +pertaining to distribution of the software without specific,
> > > +written prior permission.  The copyright holders make no
> > > +representations about the suitability of this software for any
> > > +purpose.  It is provided "as is" without express or implied
> > > +warranty.
> > > +
> > > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> > > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> > > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> > > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
> > > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> > > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
> > > +THIS SOFTWARE.
> > > +  
> > > +
> > > +  
> > > +
> > > +  The global interface exposing sub-surface compositing capabilities.
> > > +  A wl_surface, that has sub-surfaces associated, is called the
> > > +  parent surface. Sub-surfaces can be arbitrarily nested and create
> > > +  a tree of sub-surfaces.
> > > +
> > > +  The root surface in a tree of sub-surfaces is the main
> > > +  surface. The main surface cannot be a sub-surface, because
> > > +  sub-surfaces must always have a parent.
> > > +
> > > +  A main surface with its sub-surfaces forms a (compound) window.
> > > +  For window management purposes, this set of wl_surface objects is
> > > +  to be considered as a single window, and it should also behave as
> > > +  such.
> > > +
> > > +  The aim of sub-surfaces is to offload some of the compositing work
> > > +  within a window from clients 

Re: [PATCH weston v3 01/13] protocol: add sub-surfaces

[David Herrmann]

Hi Pekka

On Fri, Apr 26, 2013 at 1:12 PM, Pekka Paalanen  wrote:
>> > > diff --git a/protocol/subsurface.xml b/protocol/subsurface.xml
>> > > new file mode 100644
>> > > index 000..60b4002
>> > > --- /dev/null
>> > > +++ b/protocol/subsurface.xml
>> > > @@ -0,0 +1,236 @@
>> > > +
>> > > +
>> > > +
>> > > +  
>> > > +Copyright © 2012-2013 Collabora, Ltd.
>> > > +
>> > > +Permission to use, copy, modify, distribute, and sell this
>> > > +software and its documentation for any purpose is hereby granted
>> > > +without fee, provided that the above copyright notice appear in
>> > > +all copies and that both that copyright notice and this permission
>> > > +notice appear in supporting documentation, and that the name of
>> > > +the copyright holders not be used in advertising or publicity
>> > > +pertaining to distribution of the software without specific,
>> > > +written prior permission.  The copyright holders make no
>> > > +representations about the suitability of this software for any
>> > > +purpose.  It is provided "as is" without express or implied
>> > > +warranty.
>> > > +
>> > > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
>> > > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
>> > > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
>> > > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
>> > > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
>> > > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
>> > > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
>> > > +THIS SOFTWARE.
>> > > +  
>> > > +
>> > > +  
>> > > +
>> > > +  The global interface exposing sub-surface compositing 
>> > > capabilities.
>> > > +  A wl_surface, that has sub-surfaces associated, is called the
>> > > +  parent surface. Sub-surfaces can be arbitrarily nested and create
>> > > +  a tree of sub-surfaces.
>> > > +
>> > > +  The root surface in a tree of sub-surfaces is the main
>> > > +  surface. The main surface cannot be a sub-surface, because
>> > > +  sub-surfaces must always have a parent.
>> > > +
>> > > +  A main surface with its sub-surfaces forms a (compound) window.
>> > > +  For window management purposes, this set of wl_surface objects is
>> > > +  to be considered as a single window, and it should also behave as
>> > > +  such.
>> > > +
>> > > +  The aim of sub-surfaces is to offload some of the compositing work
>> > > +  within a window from clients to the compositor. A prime example is
>> > > +  a video player with decorations and video in separate wl_surface
>> > > +  objects. This should allow the compositor to pass YUV video buffer
>> > > +  processing to dedicated overlay hardware when possible.
>> > > +
>> > > +
>> > > +
>> > > +  
>> > > +   Informs the server that the client will not be using this
>> > > +   protocol object anymore. This does not affect any other
>> > > +   objects, wl_subsurface objects included.
>> > > +  
>> > > +
>> > > +
>> > > +
>> > > +  > > > + summary="the to-be sub-surface is invalid"/>
>> > > +  > > > + summary="the given parent is a sub-surface"/>
>> > > +
>> > > +
>> > > +
>> > > +  
>> > > +   Create a sub-surface interface for the given surface, and
>> > > +   associate it with the given parent surface. This turns a
>> > > +   plain wl_surface into a sub-surface.
>> > > +
>> > > +   The to-be sub-surface must not already have a dedicated
>> > > +   purpose, like any shell surface type, cursor image, drag icon,
>> > > +   or sub-surface. Otherwise a protocol error is raised.
>> > > +  
>> > > +
>> > > +  > > > +   summary="the new subsurface object id"/>
>> > > +  > > > +   summary="the surface to be turned into a sub-surface"/>
>> > > +  > > > +   summary="the parent surface"/>
>> > > +
>> > > +  
>> > > +
>> > > +  
>> > > +
>> > > +  An additional interface to a wl_surface object, which has been
>> > > +  made a sub-surface. A sub-surface has one parent surface.
>> > > +
>> > > +  A sub-surface becomes mapped, when a non-NULL wl_buffer is applied
>> > > +  and the parent surface is mapped. The order of which one happens
>> > > +  first is irrelevant. A sub-surface is hidden if the parent becomes
>> > > +  hidden, or if a NULL wl_buffer is applied. These rules apply
>> > > +  recursively through the tree of surfaces.
>> > > +
>> > > +  The behaviour of wl_surface.commit request on a sub-surface
>> > > +  depends on the sub-surface's mode. The possible modes are
>> > > +  synchronized and desynchronized, see methods
>> > > +  wl_subsurface.set_sync and wl_subsurface.set_desync. Synchronized
>> > > +  mode caches wl_su

Re: Midori browser should now work on Wayland

[darxus]

Can you write that up as directions to add to
http://wayland.freedesktop.org/extras.html ?

Also, for interested folks, there is a #midori channel on
irc.freenode.net.

On 04/26, MoD wrote:
> For testing Midori against Wayland, I use "./configure --enable-gtk3 
> --disable-unique". But at present there hasn't been a WebkitGTK+ release that 
> has proper wayland support. I've been using GTK3 master and the webkit patch 
> from , rebased against 
> WebkitGTK+ 2.0.0; some weeks ago I asked #webkitgtk+ IRC what the status of 
> that bug was and didn't hear anything, but I haven't had time to look into it 
> since. They may be waiting on subsurfaces so that Webkit2 (which does 
> out-of-process rendering) can be supported more easily.
> 
> So technically nothing has changed recently from Midori's perspective; we're 
> still just waiting on released versions of dependencies to lose their 
> internal Xlib calls.
> 
> On 26 de abril de 2013 at 3:56 AM, "Chang Liu"  wrote:
> >
> >Sorry I CC'ed wayland-devel-request. I have to resend the mail.
> >
> >I tried this morning. Midori crashed on start. Both midori and
> >libunique are latest git version.
> >
> >Backtrace:
> >Launching command: '/usr/bin/gdb' --batch -ex 'set print thread-
> >events
> >off' -ex run -ex 'set logging on /run/user/1000/midori/gdb.bt' -ex
> >'bt' --return-child-result --args midori
> >[Thread debugging using libthread_db enabled]
> >Using host libthread_db library "/usr/lib/libthread_db.so.1".
> >
> >Program received signal SIGSEGV, Segmentation fault.
> >slowly_and_stupidly_obtain_
> >timestamp (display=display@entry=0x71a060)
> >at ./uniqueapp.c:129
> >129  xwindow = XCreateWindow (xdisplay, RootWindow (xdisplay, 
> >0),
> >#0  slowly_and_stupidly_obtain_timestamp
> >(display=display@entry=0x71a060) at ./uniqueapp.c:129
> >#1  0x773870b8 in set_startup_id (startup_id= >out>,
> >backend=0x71b4c0) at ./uniqueapp.c:198
> >#2  unique_app_set_property (gobject=0x7142d0, prop_id= >out>, value=0x7fffdd60, pspec=0x78bcf0) at ./uniqueapp.c:300
> >#3  0x77ba10d2 in ?? () from /usr/lib/libgobject-2.0.so.0
> >#4  0x773870f8 in unique_app_constructor (gtype=7863568,
> >n_params=3, params=0x77fd80) at ./uniqueapp.c:271
> >#5  0x77ba2509 in g_object_newv () from 
> >/usr/lib/libgobject-2.0.so.0
> >#6  0x77ba2cd6 in g_object_new_valist () from
> >/usr/lib/libgobject-2.0.so.0
> >#7  0x77ba3044 in g_object_new () from /usr/lib/libgobject-
> >2.0.so.0
> >#8  0x0042ccfc in midori_app_instance_is_running ()
> >#9  0x0043ffa5 in midori_normal_app_new ()
> >#10 0x0042924c in main ()
> >
> >Looks like libunique still has reference to Xlib functions. Or am I
> >doing things wrong? (Is there a build-time switch for libunique to
> >change this?)
> >
> >
> >2013/4/25  :
> >>
> >> I just noticed the bug for preliminary wayland support was just 
> >closed.  I
> >> haven't tried it.
> >>
> >> http://twotoasts.de/index.php/midori/
> >> http://en.wikipedia.org/wiki/Midori_%28web_browser%29
> >> Bug: https://bugs.launchpad.net/midori/+bug/975355
> >>
> >> It's based on WebKitGTK+, so maybe that should work now as well?
> >>
> >> - Forwarded message -
> >>
> >> Date: Thu, 25 Apr 2013 22:16:49 -
> >> Subject: [Bug 975355] Re: Preliminary Wayland support
> >>
> >> ** Summary changed:
> >>
> >> - Wayland support
> >> + Preliminary Wayland support
> >>
> >> ** Changed in: midori
> >>Status: In Progress => Fix Released
> >>
> >> ** Changed in: midori
> >>Importance: Undecided => Low
> >>
> >> --
> >> You received this bug notification because you are subscribed to 
> >the bug
> >> report.
> >> https://bugs.launchpad.net/bugs/975355
> >>
> >> Title:
> >>   Preliminary Wayland support
> >>
> >> Status in Midori: Webkit Web browser:
> >>   Fix Released
> >>
> >> Bug description:
> >>   To work with wayland, gdk_x11_ calls and Xlib calls need to be 
> >wrapped
> >>   in build-time and run-time backend checks:
> >>   http://developer.gnome.org/gtk3/3.3/ch24s02.html#id1502079
> >>
> >>   $ grep -r gdk_x11 .
> >>   ./midori/sokoke.c:Atom save_mode_atom = 
> >gdk_x11_get_xatom_by_name_for_display (
> >>   ./midori/midori-browser.c: 
> >gdk_x11_xatom_to_atom (XA_INTEGER),
> >>
> >>   $ grep -r Xlib .
> >>   ./midori/main.c:#include 
> >>
> >>   http://wayland.freedesktop.org/gtk.html
> >>
> >>   The wayland backend in GTK+ 3.4 works, so as soon as these are 
> >done
> >>   midori should be usable with wayland.
> >>
> >> To manage notifications about this bug go to:
> >> https://bugs.launchpad.net/midori/+bug/975355/+subscriptions
> >>
> >>
> >> - End forwarded message -
> >>
> >> --
> >> "Will I ever learn? I hope not, I'm having too much fun."
> >> - Brent "Minime" Avis, motorcycle.com
> >> http://www.ChaosReigns.com
> >> ___
> >> wayland-devel mailing l

[PATCH weston v2 1/7] tests: Add .weston extension to clients tests

[Quentin Glidic]

From: Quentin Glidic 

Signed-off-by: Quentin Glidic 
---
 tests/.gitignore  |  6 +-
 tests/Makefile.am | 34 ++
 2 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/tests/.gitignore b/tests/.gitignore
index 05bc024..a48ed40 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -1,3 +1,4 @@
+*.weston
 logs
 matrix-test
 setbacklight
@@ -6,8 +7,3 @@ test-text-client
 wayland-test-client-protocol.h
 wayland-test-protocol.c
 wayland-test-server-protocol.h
-text-test
-keyboard-test
-event-test
-button-test
-xwayland-test
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 2729545..03492d7 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -5,16 +5,18 @@ module_tests =\
surface-global-test.la
 
 weston_tests = \
-   keyboard-test   \
-   event-test  \
-   button-test \
-   text-test   \
+   keyboard.weston \
+   event.weston\
+   button.weston   \
+   text.weston \
$(xwayland_test)
 
 AM_TESTS_ENVIRONMENT = \
abs_builddir='$(abs_builddir)'; export abs_builddir;
 
-LOG_COMPILER = $(srcdir)/weston-tests-env
+TEST_EXTENSIONS = .la .weston
+LA_LOG_COMPILER = $(srcdir)/weston-tests-env
+WESTON_LOG_COMPILER = $(srcdir)/weston-tests-env
 
 clean-local:
-rm -rf logs
@@ -69,27 +71,27 @@ weston_test_client_libs =   \
$(SIMPLE_CLIENT_LIBS)   \
../shared/libshared.la
 
-keyboard_test_SOURCES = keyboard-test.c $(weston_test_client_src)
-keyboard_test_LDADD = $(weston_test_client_libs)
+keyboard_weston_SOURCES = keyboard-test.c $(weston_test_client_src)
+keyboard_weston_LDADD = $(weston_test_client_libs)
 
-event_test_SOURCES = event-test.c $(weston_test_client_src)
-event_test_LDADD = $(weston_test_client_libs)
+event_weston_SOURCES = event-test.c $(weston_test_client_src)
+event_weston_LDADD = $(weston_test_client_libs)
 
-button_test_SOURCES = button-test.c $(weston_test_client_src)
-button_test_LDADD = $(weston_test_client_libs)
+button_weston_SOURCES = button-test.c $(weston_test_client_src)
+button_weston_LDADD = $(weston_test_client_libs)
 
-text_test_SOURCES =\
+text_weston_SOURCES =  \
text-test.c \
../clients/text-protocol.c  \
$(weston_test_client_src)
-text_test_LDADD = $(weston_test_client_libs)
+text_weston_LDADD = $(weston_test_client_libs)
 
-xwayland_test_SOURCES = xwayland-test.c$(weston_test_client_src)
+xwayland_weston_SOURCES = xwayland-test.c  $(weston_test_client_src)
 
-xwayland_test_LDADD = $(weston_test_client_libs) $(XWAYLAND_TEST_LIBS)
+xwayland_weston_LDADD = $(weston_test_client_libs) $(XWAYLAND_TEST_LIBS)
 
 if ENABLE_XWAYLAND_TEST
-xwayland_test = xwayland_test
+xwayland_test = xwayland.weston
 endif
 
 matrix_test_SOURCES =  \
-- 
1.8.2.1

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

[PATCH weston v2 2/7] shared/option-parser: Rework option parsing

[Quentin Glidic]

From: Quentin Glidic 

Long options with argument support two formats: equal ("--long=arg") and
space ("--long arg")
Short options now support three formats: short ("-sarg"), equal
("-s=arg") and space ("-s value")

Provide a test program

Signed-off-by: Quentin Glidic 
---
 man/weston.man |   4 +
 shared/option-parser.c | 111 ---
 tests/.gitignore   |   1 +
 tests/Makefile.am  |  11 +-
 tests/option-parser-test.c | 342 +
 5 files changed, 450 insertions(+), 19 deletions(-)
 create mode 100644 tests/option-parser-test.c

diff --git a/man/weston.man b/man/weston.man
index 39d854b..79d4588 100644
--- a/man/weston.man
+++ b/man/weston.man
@@ -92,6 +92,10 @@ and
 .\" ***
 .SH OPTIONS
 .
+Long options with an argument support two format: equal ("--long=arg") and
+space ("--long arg"). Short options with argument support three format: short
+("-sarg"), equal ("-s=arg") and space ("-s arg").
+.
 .SS Weston core options:
 .TP
 \fB\-\^B\fR\fIbackend.so\fR, \fB\-\-backend\fR=\fIbackend.so\fR
diff --git a/shared/option-parser.c b/shared/option-parser.c
index a7e497f..0c5d1af 100644
--- a/shared/option-parser.c
+++ b/shared/option-parser.c
@@ -28,22 +28,34 @@
 
 #include "config-parser.h"
 
-static void
-handle_option(const struct weston_option *option, char *value)
+enum state {
+   OK,
+   EATEN,
+   ERROR
+};
+
+static enum state
+handle_option(const struct weston_option *option, const char *value)
 {
switch (option->type) {
case WESTON_OPTION_INTEGER:
+   if (value == NULL || value[0] == '\0')
+   return ERROR;
* (int32_t *) option->data = strtol(value, NULL, 0);
-   return;
+   return EATEN;
case WESTON_OPTION_UNSIGNED_INTEGER:
+   if (value == NULL || value[0] == '\0')
+   return ERROR;
* (uint32_t *) option->data = strtoul(value, NULL, 0);
-   return;
+   return EATEN;
case WESTON_OPTION_STRING:
+   if (value == NULL)
+   return ERROR;
* (char **) option->data = strdup(value);
-   return;
+   return EATEN;
case WESTON_OPTION_BOOLEAN:
* (int32_t *) option->data = 1;
-   return;
+   return OK;
default:
assert(0);
}
@@ -54,26 +66,89 @@ parse_options(const struct weston_option *options,
  int count, int *argc, char *argv[])
 {
int i, j, k, len = 0;
+   const char *arg, *value;
 
for (i = 1, j = 1; i < *argc; i++) {
-   for (k = 0; k < count; k++) {
-   if (options[k].name)
+   arg = argv[i];
+   value = argv[i+1];
+
+   if (arg[0] != '-')
+   {
+   /* Not an option, just skip it */
+   argv[j++] = argv[i];
+   continue;
+   }
+   ++arg; /* Skip the first dash */
+
+   /* We have an option, check for which one */
+   if (arg[0] == '-') {
+   /* Long option */
+   ++arg; /* Skip the second dash */
+   for (k = 0; k < count; k++) {
+   if (!options[k].name)
+   /* No long variant for this option */
+   continue;
+
len = strlen(options[k].name);
-   if (options[k].name &&
-   argv[i][0] == '-' &&
-   argv[i][1] == '-' &&
-   strncmp(options[k].name, &argv[i][2], len) == 0 &&
-   (argv[i][len + 2] == '=' || argv[i][len + 2] == 
'\0')) {
-   handle_option(&options[k], &argv[i][len + 3]);
+   if (strncmp(options[k].name, arg, len) != 0)
+   /* Not matching */
+   continue;
+
+   switch (arg[len]) {
+   case '=': value = arg + (len+1);
+   case '\0': break;
+   default: continue; /* Not fully matching */
+   }
+
+   switch (handle_option(&options[k], value)) {
+   case OK: break;
+   case EATEN:
+   if (arg[len] == '\0')
+   ++i;
+   break;
+   case ERROR: return -1;
+   }
+
break;

[PATCH weston v2 3/7] shared/option-parser: Add string list options

[Quentin Glidic]

From: Quentin Glidic 

Signed-off-by: Quentin Glidic 
---
 man/weston.man |  6 +++---
 shared/config-parser.h |  1 +
 shared/option-parser.c | 15 +++
 src/compositor.c   | 27 ---
 tests/weston-tests-env |  6 --
 5 files changed, 47 insertions(+), 8 deletions(-)

diff --git a/man/weston.man b/man/weston.man
index 79d4588..6175b0e 100644
--- a/man/weston.man
+++ b/man/weston.man
@@ -128,9 +128,9 @@ Append log messages to the file
 .I file.log
 instead of writing them to stderr.
 .TP
-\fB\-\-modules\fR=\fImodule1.so,module2.so\fR
-Load the comma-separated list of modules. Only used by the test
-suite. The file is searched for in
+\fB\-\-modules\fR=\fImodule.so\fR
+Load the modules (the option may be specified multiple times).
+Only used by the test suite. The file is searched for in
 .IR "__weston_modules_dir__" ,
 or you can pass an absolute path.
 .TP
diff --git a/shared/config-parser.h b/shared/config-parser.h
index 1d0ee3f..37af064 100644
--- a/shared/config-parser.h
+++ b/shared/config-parser.h
@@ -59,6 +59,7 @@ enum weston_option_type {
WESTON_OPTION_INTEGER,
WESTON_OPTION_UNSIGNED_INTEGER,
WESTON_OPTION_STRING,
+   WESTON_OPTION_STRING_LIST,
WESTON_OPTION_BOOLEAN
 };
 
diff --git a/shared/option-parser.c b/shared/option-parser.c
index 0c5d1af..a45060f 100644
--- a/shared/option-parser.c
+++ b/shared/option-parser.c
@@ -37,6 +37,8 @@ enum state {
 static enum state
 handle_option(const struct weston_option *option, const char *value)
 {
+   char **string_list, **str;
+   int size = 0;
switch (option->type) {
case WESTON_OPTION_INTEGER:
if (value == NULL || value[0] == '\0')
@@ -53,6 +55,19 @@ handle_option(const struct weston_option *option, const char 
*value)
return ERROR;
* (char **) option->data = strdup(value);
return EATEN;
+   case WESTON_OPTION_STRING_LIST:
+   if (value == NULL)
+   return ERROR;
+   string_list = * (char ***) option->data;
+   if (string_list != NULL) {
+   for (str = string_list; *str != NULL; ++str)
+   ++size;
+   }
+   string_list = realloc(string_list, (size+2) * sizeof(char *));
+   string_list[size] = strdup(value);
+   string_list[size+1] = NULL;
+   * (char ***) option->data = string_list;
+   return EATEN;
case WESTON_OPTION_BOOLEAN:
* (int32_t *) option->data = 1;
return OK;
diff --git a/src/compositor.c b/src/compositor.c
index 693df2c..15196a7 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3406,6 +3406,26 @@ load_modules(struct weston_compositor *ec, const char 
*modules,
return 0;
 }
 
+static int
+load_modules_strv(struct weston_compositor *ec, char **modules,
+ int *argc, char *argv[], const char *config_file)
+{
+   char **module;
+   int (*module_init)(struct weston_compositor *ec,
+  int *argc, char *argv[], const char *config_file);
+
+   if (modules == NULL)
+   return 0;
+
+   for (module = modules; *module != NULL; ++module) {
+   module_init = load_module(*module, "module_init");
+   if (module_init)
+   module_init(ec, argc, argv, config_file);
+   }
+
+   return 0;
+}
+
 static const char xdg_error_message[] =
"fatal: environment variable XDG_RUNTIME_DIR is not set.\n";
 
@@ -3525,7 +3545,8 @@ int main(int argc, char *argv[])
 int *argc, char *argv[], const char 
*config_file);
int i;
char *backend = NULL;
-   const char *modules = "desktop-shell.so", *option_modules = NULL;
+   const char *modules = "desktop-shell.so";
+   char **option_modules = NULL;
char *log = NULL;
int32_t idle_time = 300;
int32_t help = 0;
@@ -3546,7 +3567,7 @@ int main(int argc, char *argv[])
{ WESTON_OPTION_STRING, "backend", 'B', &backend },
{ WESTON_OPTION_STRING, "socket", 'S', &socket_name },
{ WESTON_OPTION_INTEGER, "idle-time", 'i', &idle_time },
-   { WESTON_OPTION_STRING, "modules", 0, &option_modules },
+   { WESTON_OPTION_STRING_LIST, "modules", 0, &option_modules },
{ WESTON_OPTION_STRING, "log", 0, &log },
{ WESTON_OPTION_BOOLEAN, "help", 'h', &help },
{ WESTON_OPTION_BOOLEAN, "version", 0, &version },
@@ -3619,7 +3640,7 @@ int main(int argc, char *argv[])
 
if (load_modules(ec, modules, &argc, argv, config_file) < 0)
goto out;
-   if (load_modules(ec, option_modules, &argc, argv, config_file) < 0)
+   if (load_modules_strv(ec, option_modules, &argc, argv, config_file) < 0)
got

[PATCH weston v2 4/7] weston: Allow relative paths for modules

[Quentin Glidic]

From: Quentin Glidic 

This is to be used by tests or when developping to load modules directly
from the build tree

Signed-off-by: Quentin Glidic 
---
 man/weston.man   | 5 +++--
 src/compositor.c | 9 ++---
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/man/weston.man b/man/weston.man
index 6175b0e..03307a0 100644
--- a/man/weston.man
+++ b/man/weston.man
@@ -103,7 +103,8 @@ Load
 .I backend.so
 instead of the default backend. The file is searched for in
 .IR "__weston_modules_dir__" ,
-or you can pass an absolute path. The default backend is 
+or you can pass a path (absolute, .-relative or ..-relative). The default 
+backend is
 .I __weston_native_backend__
 unless the environment suggests otherwise, see
 .IR DISPLAY " and " WAYLAND_DISPLAY .
@@ -132,7 +133,7 @@ instead of writing them to stderr.
 Load the modules (the option may be specified multiple times).
 Only used by the test suite. The file is searched for in
 .IR "__weston_modules_dir__" ,
-or you can pass an absolute path.
+or you can pass a path (absolute, .-relative or ..-relative).
 .TP
 \fB\-\^S\fR\fIname\fR, \fB\-\-socket\fR=\fIname\fR
 Weston will listen in the Wayland socket called
diff --git a/src/compositor.c b/src/compositor.c
index 15196a7..d616ca3 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3349,10 +3349,13 @@ load_module(const char *name, const char *entrypoint)
char path[PATH_MAX];
void *module, *init;
 
-   if (name[0] != '/')
-   snprintf(path, sizeof path, "%s/%s", MODULEDIR, name);
+   if (name[0] == '/' || /* If the path is absolute or .. */
+   (name[0] == '.' && /* ... relative to ... */
+(name[1] == '/' || /* ... current dir or ... */
+ (name[1] == '.' && name[2] == '/' /* ... parent dir ... */
+   snprintf(path, sizeof path, "%s", name); /* ... load the exact 
specified module */
else
-   snprintf(path, sizeof path, "%s", name);
+   snprintf(path, sizeof path, "%s/%s", MODULEDIR, name);
 
module = dlopen(path, RTLD_NOW | RTLD_NOLOAD);
if (module) {
-- 
1.8.2.1

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

[PATCH weston v2 5/7] weston-test: Get the test client path from args

[Quentin Glidic]

From: Quentin Glidic 

Signed-off-by: Quentin Glidic 
---
 tests/weston-test.c| 16 ++--
 tests/weston-tests-env |  3 ++-
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/tests/weston-test.c b/tests/weston-test.c
index 55c5da4..cf74e96 100644
--- a/tests/weston-test.c
+++ b/tests/weston-test.c
@@ -29,6 +29,7 @@
 #include "wayland-test-server-protocol.h"
 
 struct weston_test {
+   char *client;
struct weston_compositor *compositor;
struct weston_layer layer;
struct weston_process process;
@@ -202,19 +203,15 @@ idle_launch_client(void *data)
struct weston_test *test = data;
pid_t pid;
sigset_t allsigs;
-   char *path;
 
-   path = getenv("WESTON_TEST_CLIENT_PATH");
-   if (path == NULL)
-   exit(EXIT_FAILURE);
pid = fork();
if (pid == -1)
exit(EXIT_FAILURE);
if (pid == 0) {
sigfillset(&allsigs);
sigprocmask(SIG_UNBLOCK, &allsigs, NULL);
-   execl(path, path, NULL);
-   weston_log("compositor: executing '%s' failed: %m\n", path);
+   execl(test->client, test->client, NULL);
+   weston_log("compositor: executing '%s' failed: %m\n", 
test->client);
exit(EXIT_FAILURE);
}
 
@@ -242,6 +239,13 @@ module_init(struct weston_compositor *ec,
  test, bind_test) == NULL)
return -1;
 
+   const struct weston_option test_options[] = {
+   { WESTON_OPTION_STRING, "test-client", 0, &test->client },
+   };
+   if (parse_options(test_options, ARRAY_LENGTH(test_options), argc, argv) 
< 0)
+   exit(EXIT_FAILURE);
+
+
loop = wl_display_get_event_loop(ec->wl_display);
wl_event_loop_add_idle(loop, idle_launch_client, test);
 
diff --git a/tests/weston-tests-env b/tests/weston-tests-env
index 1bc06be..2c2d2fa 100755
--- a/tests/weston-tests-env
+++ b/tests/weston-tests-env
@@ -28,11 +28,12 @@ case $1 in
&> "$OUTLOG"
;;
*)
-   WESTON_TEST_CLIENT_PATH=$abs_builddir/$1 $WESTON \
+   $WESTON \
--socket=test-$(basename $1) \
--backend=$BACKEND \
--log="$SERVERLOG" \
--modules=xwayland.so \
--modules=$abs_builddir/.libs/weston-test.so \
+   --test-client=$abs_builddir/$1 \
&> "$OUTLOG"
 esac
-- 
1.8.2.1

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

[PATCH weston v2 7/7] headless-backend: Init fake pointer and keyboard

[Quentin Glidic]

From: "U. Artie Eoff" 

Signed-off-by: Quentin Glidic 
---
 src/compositor-headless.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compositor-headless.c b/src/compositor-headless.c
index 4720329..507d4bf 100644
--- a/src/compositor-headless.c
+++ b/src/compositor-headless.c
@@ -173,6 +173,8 @@ headless_compositor_create(struct wl_display *display,
goto err_free;
 
weston_seat_init(&c->fake_seat, &c->base);
+   weston_seat_init_pointer(&c->fake_seat);
+   weston_seat_init_keyboard(&c->fake_seat, NULL);
 
c->base.destroy = headless_destroy;
c->base.restore = headless_restore;
-- 
1.8.2.1

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

[PATCH weston v2 6/7] tests: Drop weston-tests-env

[Quentin Glidic]

From: Quentin Glidic 

This file is no longer needed using the parallel-tests feature of
automake
This also allows users to pass additional arguments to weston and to
force a backend
This change is still compatible with automake 1.11 without needing the
export hack any more

Signed-off-by: Quentin Glidic 
---
 tests/.gitignore   |  3 ++-
 tests/Makefile.am  | 53 +++---
 tests/weston-tests-env | 39 -
 3 files changed, 39 insertions(+), 56 deletions(-)
 delete mode 100755 tests/weston-tests-env

diff --git a/tests/.gitignore b/tests/.gitignore
index ab85338..441f66a 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -1,6 +1,7 @@
 *.test
 *.weston
-logs
+*.log
+*.trs
 matrix-test
 setbacklight
 test-client
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 2a48c12..23cc795 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -3,7 +3,12 @@ TESTS = $(shared_tests) $(module_tests) $(weston_tests)
 shared_tests = \
option-parser.test
 
+# Keep them in sync
 module_tests = \
+   .libs/surface-test.so   \
+   .libs/surface-global-test.so
+
+module_tests_la = \
surface-test.la \
surface-global-test.la
 
@@ -14,28 +19,44 @@ weston_tests =  \
text.weston \
$(xwayland_test)
 
-AM_TESTS_ENVIRONMENT = \
-   abs_builddir='$(abs_builddir)'; export abs_builddir;
-
-TEST_EXTENSIONS = .la .weston
-LA_LOG_COMPILER = $(srcdir)/weston-tests-env
-WESTON_LOG_COMPILER = $(srcdir)/weston-tests-env
-
-clean-local:
-   -rm -rf logs
-
-# To remove when automake 1.11 support is dropped
-export abs_builddir
-
-noinst_LTLIBRARIES =   \
-   $(weston_test)
+TEST_WESTON  ?= $(top_builddir)/src/weston
+
+ #ifneq ($(strip $(WAYLAND_DISPLAY)),)
+ ifdef WAYLAND_DISPLAY
+TEST_BACKEND ?= $(top_builddir)/src/.libs/wayland-backend.so
+ else ifneq ($(strip $(DISPLAY)),)
+TEST_BACKEND ?= $(top_builddir)/src/.libs/x11-backend.so
+ else
+TEST_BACKEND ?= $(top_builddir)/src/.libs/headless-backend.so
+ endif
+
+TEST_EXTENSIONS = .weston .so
+
+WESTON_LOG_COMPILER = $(TEST_WESTON)
+SO_LOG_COMPILER = $(TEST_WESTON)
+
+# Keep --test-client as the last arg, so it grabs the test client in
+AM_WESTON_LOG_FLAGS = \
+   --modules xwayland.so \
+   --backend $(TEST_BACKEND) \
+   --socket test-socket-$(notdir $@) \
+   --modules $(builddir)/.libs/weston-test.so \
+   --test-client
+
+# Keep --modules as the last arg, so it grabs the test module in
+AM_SO_LOG_FLAGS = \
+   --modules xwayland.so \
+   --backend $(TEST_BACKEND) \
+   --socket test-socket-$(notdir $@) \
+   --modules
 
 noinst_PROGRAMS =  \
$(setbacklight) \
matrix-test
 
 check_LTLIBRARIES =\
-   $(module_tests)
+   $(module_tests_la)  \
+   $(weston_test)
 
 check_PROGRAMS =   \
$(shared_tests) \
diff --git a/tests/weston-tests-env b/tests/weston-tests-env
deleted file mode 100755
index 2c2d2fa..000
--- a/tests/weston-tests-env
+++ /dev/null
@@ -1,39 +0,0 @@
-#!/bin/bash
-
-WESTON=$abs_builddir/../src/weston
-LOGDIR=$abs_builddir/logs
-
-mkdir -p "$LOGDIR"
-
-SERVERLOG="$LOGDIR/$1-serverlog.txt"
-OUTLOG="$LOGDIR/$1-log.txt"
-
-rm -f "$SERVERLOG"
-
-if test x$WAYLAND_DISPLAY != x; then
-   BACKEND=$abs_builddir/../src/.libs/wayland-backend.so
-elif test x$DISPLAY != x; then
-   BACKEND=$abs_builddir/../src/.libs/x11-backend.so
-else
-   BACKEND=$abs_builddir/../src/.libs/wayland-backend.so
-fi
-
-case $1 in
-   *.la|*.so)
-   $WESTON --backend=$BACKEND \
-   --socket=test-$(basename $1) \
-   --modules=xwayland.so \
-   --modules=$abs_builddir/.libs/${1/.la/.so} \
-   --log="$SERVERLOG" \
-   &> "$OUTLOG"
-   ;;
-   *)
-   $WESTON \
-   --socket=test-$(basename $1) \
-   --backend=$BACKEND \
-   --log="$SERVERLOG" \
-   --modules=xwayland.so \
-   --modules=$abs_builddir/.libs/weston-test.so \
-   --test-client=$abs_builddir/$1 \
-   &> "$OUTLOG"
-esac
-- 
1.8.2.1

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

Additional pixel formats for wl_shm

[Pekka Paalanen]

Hi Kristian,

I'm working on Raspberry Pi, where the VideoCore can deal directly with
a large number of pixel formats. However, wl_shm only exposes ARGB and
XRGB 32-bit per pixel formats, which on such tiny devices are very
wasteful.

Would it be acceptable to add more formats to the wl_shm formats enum?
I have happily forgot all the previous discussions about the topic, and
a quick search into the mailing list archives didn't turn up much.

We are especially interested in 16-bit per pixel formats to save memory
and bandwidth, and if I am reading the GLESv2 specification right,
RGB565, RGBA and RGBA5551 should be directly supported, so at least
those could be uploaded into textures without manual conversion. Of
course, the new rpi-renderer I am working on does not use GL for
compositing anymore, but it should be able to use those formats
directly, too.

I have also another proposition: an extension to let wl_shm support
custom pixel formats outside of the core protocol listed formats.

It would have a new global interface, which when bound, would advertise
additional pixel formats as a (string, uint) tuple, where the string
describes the pixel format, and the uint is the corresponding format
name to pass into wl_shm_pool.create_buffer as the format argument.
wl_shm would not advertise these format names itself. We would need to
define a WL_SHM_FORMAT_CUSTOM_BASE to reserve some name space for the
custom formats.

Or something along those lines.

Of course, this is just working around the pixel format enum wl_shm has
anyway, so if you would be willing to take more exotic pixel formats
into the wl_shm format enum, this extension would not be needed.

Does any of this sound acceptable for upstream Wayland, or do you think
we'd better just write a new wl_buffer factory with everything we need?

Btw. Google found this:
http://people.freedesktop.org/~krh/fourcc.patch
Why was that or similar never used? :-)


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Additional pixel formats for wl_shm

[Jason Ekstrand]

pq,
On Fri, Apr 26, 2013 at 8:13 AM, Pekka Paalanen  wrote:

> Hi Kristian,
>
> I'm working on Raspberry Pi, where the VideoCore can deal directly with
> a large number of pixel formats. However, wl_shm only exposes ARGB and
> XRGB 32-bit per pixel formats, which on such tiny devices are very
> wasteful.
>
> Would it be acceptable to add more formats to the wl_shm formats enum?
> I have happily forgot all the previous discussions about the topic, and
> a quick search into the mailing list archives didn't turn up much.
>
> We are especially interested in 16-bit per pixel formats to save memory
> and bandwidth, and if I am reading the GLESv2 specification right,
> RGB565, RGBA and RGBA5551 should be directly supported, so at least
> those could be uploaded into textures without manual conversion. Of
> course, the new rpi-renderer I am working on does not use GL for
> compositing anymore, but it should be able to use those formats
> directly, too.
>

Yeah, I think that supporting 16-bit formats would be good for any embedded
application.  I think Android defaults to 565 for GLES surfaces for that
very reason.  Particularly when working with overlays and limited space,
the ability to use smaller formats is a good idea.  Also, I think
supporting YUV and similar would be good so that compositors could do
colorspace conversions via overlays rather than software or GLSL
client-side.


> I have also another proposition: an extension to let wl_shm support
> custom pixel formats outside of the core protocol listed formats.
>
> It would have a new global interface, which when bound, would advertise
> additional pixel formats as a (string, uint) tuple, where the string
> describes the pixel format, and the uint is the corresponding format
> name to pass into wl_shm_pool.create_buffer as the format argument.
> wl_shm would not advertise these format names itself. We would need to
> define a WL_SHM_FORMAT_CUSTOM_BASE to reserve some name space for the
> custom formats.
>

Personally, I think we should prefer putting things in wl_shm over having
additional formats being an extension.  That said, having it extendible
might not be a bad idea.  It would allow for playing with new color formats
without extending the core protocol and then they could be added later.
That said, unless your color format is pretty exotic, I'd rather see it in
wl_shm as an optional format than requiring an extension.

If we were to add a color format extension system, would it need to be a
new interface?  Why couldn't we just have an extended_formats event in
wl_shm that advertises both an enum and a string?  Having an extra
interface to add enums to wl_shm seems a bit odd.

Or something along those lines.
>
> Of course, this is just working around the pixel format enum wl_shm has
> anyway, so if you would be willing to take more exotic pixel formats
> into the wl_shm format enum, this extension would not be needed.
>
> Does any of this sound acceptable for upstream Wayland, or do you think
> we'd better just write a new wl_buffer factory with everything we need?
>
> Btw. Google found this:
> http://people.freedesktop.org/~krh/fourcc.patch
> Why was that or similar never used? :-)
>
>
> Thanks,
> pq
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>

Thanks,
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v3 01/13] protocol: add sub-surfaces

[Jason Ekstrand]

pq,

On Fri, Apr 26, 2013 at 7:09 AM, David Herrmann wrote:

> Hi Pekka
>
> On Fri, Apr 26, 2013 at 1:12 PM, Pekka Paalanen 
> wrote:
> >> > > diff --git a/protocol/subsurface.xml b/protocol/subsurface.xml
> >> > > new file mode 100644
> >> > > index 000..60b4002
> >> > > --- /dev/null
> >> > > +++ b/protocol/subsurface.xml
> >> > > @@ -0,0 +1,236 @@
> >> > > +
> >> > > +
> >> > > +
> >> > > +  
> >> > > +Copyright © 2012-2013 Collabora, Ltd.
> >> > > +
> >> > > +Permission to use, copy, modify, distribute, and sell this
> >> > > +software and its documentation for any purpose is hereby
> granted
> >> > > +without fee, provided that the above copyright notice appear in
> >> > > +all copies and that both that copyright notice and this
> permission
> >> > > +notice appear in supporting documentation, and that the name of
> >> > > +the copyright holders not be used in advertising or publicity
> >> > > +pertaining to distribution of the software without specific,
> >> > > +written prior permission.  The copyright holders make no
> >> > > +representations about the suitability of this software for any
> >> > > +purpose.  It is provided "as is" without express or implied
> >> > > +warranty.
> >> > > +
> >> > > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO
> THIS
> >> > > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
> AND
> >> > > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR
> ANY
> >> > > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> >> > > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
> WHETHER IN
> >> > > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> >> > > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
> >> > > +THIS SOFTWARE.
> >> > > +  
> >> > > +
> >> > > +  
> >> > > +
> >> > > +  The global interface exposing sub-surface compositing
> capabilities.
> >> > > +  A wl_surface, that has sub-surfaces associated, is called the
> >> > > +  parent surface. Sub-surfaces can be arbitrarily nested and
> create
> >> > > +  a tree of sub-surfaces.
> >> > > +
> >> > > +  The root surface in a tree of sub-surfaces is the main
> >> > > +  surface. The main surface cannot be a sub-surface, because
> >> > > +  sub-surfaces must always have a parent.
> >> > > +
> >> > > +  A main surface with its sub-surfaces forms a (compound)
> window.
> >> > > +  For window management purposes, this set of wl_surface
> objects is
> >> > > +  to be considered as a single window, and it should also
> behave as
> >> > > +  such.
> >> > > +
> >> > > +  The aim of sub-surfaces is to offload some of the
> compositing work
> >> > > +  within a window from clients to the compositor. A prime
> example is
> >> > > +  a video player with decorations and video in separate
> wl_surface
> >> > > +  objects. This should allow the compositor to pass YUV video
> buffer
> >> > > +  processing to dedicated overlay hardware when possible.
> >> > > +
> >> > > +
> >> > > +
> >> > > +  
> >> > > +   Informs the server that the client will not be using this
> >> > > +   protocol object anymore. This does not affect any other
> >> > > +   objects, wl_subsurface objects included.
> >> > > +  
> >> > > +
> >> > > +
> >> > > +
> >> > > +   >> > > + summary="the to-be sub-surface is invalid"/>
> >> > > +   >> > > + summary="the given parent is a sub-surface"/>
> >> > > +
> >> > > +
> >> > > +
> >> > > +  
> >> > > +   Create a sub-surface interface for the given surface, and
> >> > > +   associate it with the given parent surface. This turns a
> >> > > +   plain wl_surface into a sub-surface.
> >> > > +
> >> > > +   The to-be sub-surface must not already have a dedicated
> >> > > +   purpose, like any shell surface type, cursor image, drag
> icon,
> >> > > +   or sub-surface. Otherwise a protocol error is raised.
> >> > > +  
> >> > > +
> >> > > +   >> > > +   summary="the new subsurface object id"/>
> >> > > +   >> > > +   summary="the surface to be turned into a sub-surface"/>
> >> > > +   >> > > +   summary="the parent surface"/>
> >> > > +
> >> > > +  
> >> > > +
> >> > > +  
> >> > > +
> >> > > +  An additional interface to a wl_surface object, which has
> been
> >> > > +  made a sub-surface. A sub-surface has one parent surface.
> >> > > +
> >> > > +  A sub-surface becomes mapped, when a non-NULL wl_buffer is
> applied
> >> > > +  and the parent surface is mapped. The order of which one
> happens
> >> > > +  first is irrelevant. A sub-surface is hidden if the parent
> becomes
> >> > > +  hidden, or if a NULL wl_buffer is applied. These rules apply
> >> > > +  recursively through the tree of surfaces.
> >> > > +
> >> > > +

Touch screen not working under weston drm

[Rafael Antognolli]

Hey pq,

When I start weston-launch (or weston directly), it does recognize
that I have a touch screen device, but does not seem to make it
available later for use.

My findings when debugging:

 - touch_set_focus() fails at this point:

resource =
find_resource_for_client(&seat->touch->resource_list,
 surface->resource.client);
if (!resource) {
weston_log("couldn't find resource\n");
return;
}

and that's exactly the message that I get. It seems that the touch
resource is never added to that list. In fact, the seat_get_touch()
function is never called, and that seems to be the place where the
resource would be added to the list.

As I said in the beginning, the event device for the touchscreen is
being recognized somehow by weston, found as /dev/input/event11 (and
it's not the touchpad, that one is event5 and is working fine). The
touchscreen device is even added to the master->devices_list on the
device_added() function (src/udev-seat.c:97).

I don't know which place of the the code should be responsible for
triggering the seat_get_touch() callback, but I do think that this is
the problem here, maybe just a consequence of something else not
working (is it not being called because the wl_touch object wasn't
instantiated?)

Any help is welcome, but I'll not be able to test this soon, since I'm
using Rodrigo's notebook to test the touchscreen, and he's going to be
out of the office from tomorrow and during the entire next week. So
there's no hurry to make this work.

--
Rafael Antognolli
http://antognolli.org/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Buffer Filters

[Jason Ekstrand]

Wayland Devs,

What follows is an idea that's been kicking around my head for a little
while now due to a discussion on the list a month or so ago.  The basic
idea is to add an interface that provides some additional buffer types that
don't have any back-end data of their own, but act as filters for other
buffers.

As you would expect, the interface would have an enum representing all of
the filters supported by the compositor and an event that would announce
all of the supported filters upon binding by the client.  Then, there would
be a series of "create_" requests that would take a new_id of type
wl_buffer (for the newly created filter), a object argument of type
wl_buffer for the buffer being wrapped, and possibly some other arguments
depending on the filter.  In theory, you could stack filters, but that
might get dicey and we would have to define some semantics for that.  I'm
sure there are more filters that would be useful, but here are a couple
that come to mind.

INVISIBLE

This is not really a filter.  Rather, it would be a buffer that has a size,
but no content whatsoever.  The compositor would know that the surface to
which this buffer is attached and, while it would be mapped onscreen would
never be rendered.

I can think of a few different possible uses for this (mostly having to do
with sub-ssurfaces).  For example, you could use an invisible buffer the
size of your entire window to catch all of the input events and then patch
the window together out of input-unaware subsurfaces.  I don't remember all
of the details of subsurfaces and input, but this seems useful to me.

SCALE/ZOOM

This would create a buffer whose content is provided by another buffer but
has a different size.  The compositor would scale via GL or hardware
overlays.  We would probably need an additional argument for the type of
scaling (linear, cubic, etc.)

One possible use for this would be, for example, a video player.  A
standard DVD video is encoded at 720x480 but is *always* scaled (720x480 is
neither 16:9 or 4:3).  This would allow a media player to provide a 720x480
video stream at 24 or 30 FPS and then have the compositor scale it up to
1920x1080 or whatever.  For fullscreen surfaces, this isn't a problem, but
if they have a non-fullscreen but still big window, the client currently
has to provide it at full resolution.

This has huge bandwidth advantages if the client is using wl_shm.  Also, it
would allow the compositor to use hardware overlays when available to do
the scaling which are (from what I know) more efficient and often provide
better scaling than a client will get even with GL.

This is just a quick list of a couple ideas.  Perhaps more immediate
questions are, Is this useful? and, Is this too much of an abuse of
wl_buffer?

Thanks,
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Additional pixel formats for wl_shm

[Pekka Paalanen]

On Fri, 26 Apr 2013 09:09:28 -0500
Jason Ekstrand  wrote:

> pq,
> On Fri, Apr 26, 2013 at 8:13 AM, Pekka Paalanen  wrote:
> 
> > Hi Kristian,
> >
> > I'm working on Raspberry Pi, where the VideoCore can deal directly with
> > a large number of pixel formats. However, wl_shm only exposes ARGB and
> > XRGB 32-bit per pixel formats, which on such tiny devices are very
> > wasteful.
> >
> > Would it be acceptable to add more formats to the wl_shm formats enum?
> > I have happily forgot all the previous discussions about the topic, and
> > a quick search into the mailing list archives didn't turn up much.
> >
> > We are especially interested in 16-bit per pixel formats to save memory
> > and bandwidth, and if I am reading the GLESv2 specification right,
> > RGB565, RGBA and RGBA5551 should be directly supported, so at least
> > those could be uploaded into textures without manual conversion. Of
> > course, the new rpi-renderer I am working on does not use GL for
> > compositing anymore, but it should be able to use those formats
> > directly, too.
> >
> 
> Yeah, I think that supporting 16-bit formats would be good for any embedded
> application.  I think Android defaults to 565 for GLES surfaces for that
> very reason.  Particularly when working with overlays and limited space,
> the ability to use smaller formats is a good idea.  Also, I think
> supporting YUV and similar would be good so that compositors could do
> colorspace conversions via overlays rather than software or GLSL
> client-side.
> 
> 
> > I have also another proposition: an extension to let wl_shm support
> > custom pixel formats outside of the core protocol listed formats.
> >
> > It would have a new global interface, which when bound, would advertise
> > additional pixel formats as a (string, uint) tuple, where the string
> > describes the pixel format, and the uint is the corresponding format
> > name to pass into wl_shm_pool.create_buffer as the format argument.
> > wl_shm would not advertise these format names itself. We would need to
> > define a WL_SHM_FORMAT_CUSTOM_BASE to reserve some name space for the
> > custom formats.
> >
> 
> Personally, I think we should prefer putting things in wl_shm over having
> additional formats being an extension.  That said, having it extendible
> might not be a bad idea.  It would allow for playing with new color formats
> without extending the core protocol and then they could be added later.
> That said, unless your color format is pretty exotic, I'd rather see it in
> wl_shm as an optional format than requiring an extension.

I agree, having formats enumerated in wl_shm would be straightforward.

> If we were to add a color format extension system, would it need to be a
> new interface?  Why couldn't we just have an extended_formats event in
> wl_shm that advertises both an enum and a string?  Having an extra
> interface to add enums to wl_shm seems a bit odd.

It's just an option, that allows to leave the Wayland core protocol
untouched. The new global interface would not necessarily need to
be in the core. But that certainly limits its usefulness, too.

I'm just not sure what the current policy with wl_shm pixel formats
is, hence the whole question. :-)


Thanks,
pq

> Or something along those lines.
> >
> > Of course, this is just working around the pixel format enum wl_shm has
> > anyway, so if you would be willing to take more exotic pixel formats
> > into the wl_shm format enum, this extension would not be needed.
> >
> > Does any of this sound acceptable for upstream Wayland, or do you think
> > we'd better just write a new wl_buffer factory with everything we need?
> >
> > Btw. Google found this:
> > http://people.freedesktop.org/~krh/fourcc.patch
> > Why was that or similar never used? :-)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Input and games.

[Todd Showalter]

On Thu, Apr 25, 2013 at 8:50 AM, Pekka Paalanen  wrote:

> Todd has already listed what features a standard gamepad or controller
> has. Now someone should start designing the protocol. :-)

Based on the wl_pointer docs, I should think it would look
something like this:

--8<--

wl_gamepad::connect -- gamepad appears
The connect event occurs when a gamepad is plugged in, attaches
via wireless, or otherwise becomes available for use.  The message can
also be generated in response to a client "enumerate gamepads" query.

The name argument may or may not be empty, depending on what
information the server has available, but if present can be used by
the client to determine what to do with wl_gamepad::extended events.

The pad_index is used to tell messages from different gamepads
apart; a system may have multiple gamepads connected, and messages
from them need to be distinguishable.  The pad_index value may be much
higher than the number of gamepads currently connected if the user has
been connecting and disconnecting gamepads in pathological ways.

The cookie may or may not contain useful data, and shouldn't be
counted on, but it is a hint to the application using the data whether
a connecting gamepad has been seen before.  If the hardware has a
software-visible serial number, the cookie should be a hash of that
value.  If the hardware is plugging in at a specific USB port, the
cookie should be a hash of the device path.  The cookie exists so that
if the application sees a gamepad disappear and then another gamepad
appears, if the cookie for the old and new controllers match it can
assume it has the same physical gamepad.

Arguments:
time -- uint -- standard event timestamp
name -- string -- device name
pad_index -- uint -- which gamepad this is
cookie -- uint -- unique device hash; UNRELIABLE, hint only


wl_gamepad::disconnect -- gamepad disappears
The disconnect event occurs when a gamepad becomes unavailable,
either due to unplugging or signal loss.

Arguments:
time -- uint -- standard event timestamp
pad_index -- uint -- which gamepad this is


wl_gamepad::stick -- gamepad stick movement
A stick event occurs when there is stick movement on a gamepad.
It would be preferable if the protocol could handle float data, but
failing that the axis values can be mapped to a large integer range,
as below.  The precision of the fixed type is sufficient for most
current hardware, but not all; for example, the ps3 controller analog
sticks have a [-128 .. 127] range, but the ps3 dpad is actually
pressure sensitive, and therefore actually has an effective range of
[-255 .. 255].  It's not hard to imagine higher-precision controllers
in the future as prices come down.

The stick_index indicates which stick the message pertains to; for
hardware with more than the standard number of joysticks/thumbsticks,
higher index values are possible, but 0 is always left stick, 1 is
always right stick and 2 is always the dpad.  Even if the physical
hardware lacks one or more of those axis values, additional axis
values will be mapped above 2.

Arguments:
time -- uint -- standard event timestamp
pad_index -- uint -- which gamepad this is
stick_index -- uint -- 0 for left stick, 1 for right stick, 2 for dpad
x -- int -- the x axis of the stick mapped to [-2^15 .. 2^15 - 1]
y -- int -- the y axis of the stick mapped to [-2^15 .. 2^15 - 1]


wl_gamepad::trigger -- gamepad analog trigger movement
A trigger event occurs when there is analog trigger movement on a
gamepad.  As with stick messages, it would be preferable if the axis
value could be sent as float, but failing that the value can be mapped
to a large integer range.

The trigger_index is 0 for left stick values and 1 for right stick
values.  Hardware with more triggers can potentially supply higher
values; the pressure-sensitive buttons on the ps3 controller would go
here, for instance.

Arguments:
time -- uint -- standard event timestamp
pad_index -- uint -- which gamepad this is
trigger_index -- uint -- 0 for left trigger, 1 for right trigger
x -- uint -- the trigger value mapped to [0 .. 2^15 - 1]


wl_gamepad::button -- gamepad button press
A button event occurs when a button is pressed or released.  The
standard buttons are:

0 - BUTTON_FACE_NORTH -- triangle on ps3, y on xbox
1 - BUTTON_FACE_EAST -- circle on ps3, b on xbox
2 - BUTTON_FACE_SOUTH -- x on ps3, a on xbox
3 - BUTTON_FACE_WEST -- square on ps3, x on xbox
4 - BUTTON_SHOULDER_LEFT -- L1 on ps3, LT on xbox
5 - BUTTON_SHOULDER_RIGHT -- R1 on ps3, RT on xbox
6 - BUTTON_LEFT_STICK -- left stick click
7 -

Re: [PATCH weston v3 07/13] window: implement shm triple-buffering

[Bill Spitzak]

Pekka Paalanen wrote:


This is all *inside* the client. This is a toolkit patch.


You are right, the patch is in clients/window.c, I confused it with an 
adjacent patch.


I agree the client has to throttle resizes but I think this can avoid 
the triple buffer and removes the difference between main and subwindows.


For a single-surface client, it does not need a third, fourth, etc 
buffer because it does not draw until it receives the buffer-release for 
the old buffer. The same rule can be applied to subsurfaces. They should 
not draw until they get their buffer-release. I don't see this as being 
any more difficult than any kind of throttling, and removes the 
difference between main and subsurfaces.


For the toytoolkit this means that draw is not called until all the old 
buffers for all subsurfaces are released. Rather than the toytoolkit 
having to manage this, it may be easier for the server to send the 
release events for subsurfaces first, and the main surface last. Thus 
the toolkit only has to wait for the main surface.


I cannot think of any plausible compositor that will not release all the 
old buffers for an entire tree of subsurfaces at once so reordering the 
events like this should not be a problem.


If some subsurface buffers were not released, I also do not see any way 
that triple buffering is going to fix this, an infinite number of 
buffers are going to be needed. Throttling will have to block until the 
third buffer is released, so I see no reason not to have it block until 
the second buffer is released instead.

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

Re: [PATCH weston v2 2/7] shared/option-parser: Rework option parsing

[Bill Spitzak]

This looks good to me, especially with all the automatic tests added.

Quentin Glidic wrote:


-static void
-handle_option(const struct weston_option *option, char *value)
+enum state {
+   OK,
+   EATEN,
+   ERROR
+};
+
+static enum state
+handle_option(const struct weston_option *option, const char *value)
 {
switch (option->type) {
case WESTON_OPTION_INTEGER:
+   if (value == NULL || value[0] == '\0')
+   return ERROR;
* (int32_t *) option->data = strtol(value, NULL, 0);


Since you already checked for a zero-length string, you can detect 
non-numbers with:


const char* p;
... option->data = strtol(value, 0, &p);
if (*p) return ERROR;


-   return;
+   return EATEN;
case WESTON_OPTION_UNSIGNED_INTEGER:
+   if (value == NULL || value[0] == '\0')
+   return ERROR;
* (uint32_t *) option->data = strtoul(value, NULL, 0);
-   return;
+   return EATEN;
case WESTON_OPTION_STRING:
+   if (value == NULL)
+   return ERROR;
* (char **) option->data = strdup(value);
-   return;
+   return EATEN;
case WESTON_OPTION_BOOLEAN:
* (int32_t *) option->data = 1;
-   return;
+   return OK;
default:
assert(0);
}
@@ -54,26 +66,89 @@ parse_options(const struct weston_option *options,
  int count, int *argc, char *argv[])
 {
int i, j, k, len = 0;
+   const char *arg, *value;
 
 	for (i = 1, j = 1; i < *argc; i++) {

-   for (k = 0; k < count; k++) {
-   if (options[k].name)
+   arg = argv[i];
+   value = argv[i+1];
+
+   if (arg[0] != '-')
+   {
+   /* Not an option, just skip it */
+   argv[j++] = argv[i];
+   continue;
+   }
+   ++arg; /* Skip the first dash */
+
+   /* We have an option, check for which one */
+   if (arg[0] == '-') {
+   /* Long option */
+   ++arg; /* Skip the second dash */
+   for (k = 0; k < count; k++) {
+   if (!options[k].name)
+   /* No long variant for this option */
+   continue;
+
len = strlen(options[k].name);
-   if (options[k].name &&
-   argv[i][0] == '-' &&
-   argv[i][1] == '-' &&
-   strncmp(options[k].name, &argv[i][2], len) == 0 &&
-   (argv[i][len + 2] == '=' || argv[i][len + 2] == 
'\0')) {
-   handle_option(&options[k], &argv[i][len + 3]);
+   if (strncmp(options[k].name, arg, len) != 0)
+   /* Not matching */
+   continue;
+
+   switch (arg[len]) {
+   case '=': value = arg + (len+1);
+   case '\0': break;
+   default: continue; /* Not fully matching */
+   }
+
+   switch (handle_option(&options[k], value)) {
+   case OK: break;
+   case EATEN:
+   if (arg[len] == '\0')
+   ++i;
+   break;
+   case ERROR: return -1;
+   }
+
break;
-   } else if (options[k].short_name &&
-  argv[i][0] == '-' &&
-  options[k].short_name == argv[i][1]) {
-   handle_option(&options[k], &argv[i][2]);
+   }
+   } else {
+   /* Short option */
+   for (k = 0; k < count; k++) {
+   if (!options[k].short_name)
+   /* no short variant for this option */
+   continue;
+
+   if (options[k].short_name != arg[0])
+   /* Not matching */
+   continue;
+
+   if (arg[1] != '\0')
+   value = arg+1;
+
+   switch (arg[1]) {
+   case '\0': break;
+   case '=': val

Re: Additional pixel formats for wl_shm

[Bill Spitzak]

I would reuse PIXMAN_FORMAT for these values. No reason to come up with 
yet another enumeration. Though it means the current wl_shm values have 
to change, except it looks like 0 and 1 (and in fact any number less 
than 0x100) don't make any logical PIXMAN_FORMAT values so maybe 
they can be special-cased?


#define PIXMAN_FORMAT(bpp,type,a,r,g,b) (((bpp) << 24) |  \
 ((type) << 16) | \
 ((a) << 12) |\
 ((r) << 8) | \
 ((g) << 4) | \
 ((b)))

#define PIXMAN_TYPE_OTHER   0
#define PIXMAN_TYPE_A   1
#define PIXMAN_TYPE_ARGB2
#define PIXMAN_TYPE_ABGR3
#define PIXMAN_TYPE_COLOR   4
#define PIXMAN_TYPE_GRAY5
#define PIXMAN_TYPE_YUY26
#define PIXMAN_TYPE_YV127
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Input and games.

[Jason Ekstrand]

Hi Todd,
Thanks for putting this together.  I have a few general comments here and
more below.

My first general comment is about floating point.  I'm not 100% sure what
all went into the design decision to make wl_fixed have 8 bits of
fractional precision vs. 12 or 16.  I'm guessing that they wanted the
increased integer capability, but you'd have to ask Kristian about that.
My understanding is that most game controllers work with ranges of [0,1] or
[-1,1] which would be wasteful to put into wl_fixed.  Looking below, it
seems as if you're fairly consistently picking a 16 bit fractional part.
That breaks out of the norm of the wire format a bit, but I think it's
justified in this case.  The big thing is to be consistent which it looks
like you're doing anyway.

Another concern is how to map [0, 255] onto [0, 2^15 - 1] cleanly.
Unfortunately, there is no good way to do this so that 0 -> 0 and 255 ->
2^15 - 1.  Perhaps that doesn't matter much for games since you're sensing
human movements which will be slightly different for each controller anyway.


On Fri, Apr 26, 2013 at 1:28 PM, Todd Showalter wrote:

> On Thu, Apr 25, 2013 at 8:50 AM, Pekka Paalanen 
> wrote:
>
> > Todd has already listed what features a standard gamepad or controller
> > has. Now someone should start designing the protocol. :-)
>
> Based on the wl_pointer docs, I should think it would look
> something like this:
>
> --8<--
>
> wl_gamepad::connect -- gamepad appears
> The connect event occurs when a gamepad is plugged in, attaches
> via wireless, or otherwise becomes available for use.  The message can
> also be generated in response to a client "enumerate gamepads" query.
>
> The name argument may or may not be empty, depending on what
> information the server has available, but if present can be used by
> the client to determine what to do with wl_gamepad::extended events.
>
> The pad_index is used to tell messages from different gamepads
> apart; a system may have multiple gamepads connected, and messages
> from them need to be distinguishable.  The pad_index value may be much
> higher than the number of gamepads currently connected if the user has
> been connecting and disconnecting gamepads in pathological ways.
>
> The cookie may or may not contain useful data, and shouldn't be
> counted on, but it is a hint to the application using the data whether
> a connecting gamepad has been seen before.  If the hardware has a
> software-visible serial number, the cookie should be a hash of that
> value.  If the hardware is plugging in at a specific USB port, the
> cookie should be a hash of the device path.  The cookie exists so that
> if the application sees a gamepad disappear and then another gamepad
> appears, if the cookie for the old and new controllers match it can
> assume it has the same physical gamepad.
>
> Arguments:
> time -- uint -- standard event timestamp
> name -- string -- device name
> pad_index -- uint -- which gamepad this is
> cookie -- uint -- unique device hash; UNRELIABLE, hint only
>

Do we really need connect and disconnect timestampped?  Are those
timestamps going to be reliable/useful?  When you plug in a device, it
takes a second or two just to detect and show up in /dev.  On that time
scale, "when did I see the event?" is just as accurate as any timestamp.


> 
> wl_gamepad::disconnect -- gamepad disappears
> The disconnect event occurs when a gamepad becomes unavailable,
> either due to unplugging or signal loss.
>
> Arguments:
> time -- uint -- standard event timestamp
> pad_index -- uint -- which gamepad this is
>
> 
> wl_gamepad::stick -- gamepad stick movement
> A stick event occurs when there is stick movement on a gamepad.
> It would be preferable if the protocol could handle float data, but
> failing that the axis values can be mapped to a large integer range,
> as below.  The precision of the fixed type is sufficient for most
> current hardware, but not all; for example, the ps3 controller analog
> sticks have a [-128 .. 127] range, but the ps3 dpad is actually
> pressure sensitive, and therefore actually has an effective range of
> [-255 .. 255].  It's not hard to imagine higher-precision controllers
> in the future as prices come down.
>
> The stick_index indicates which stick the message pertains to; for
> hardware with more than the standard number of joysticks/thumbsticks,
> higher index values are possible, but 0 is always left stick, 1 is
> always right stick and 2 is always the dpad.  Even if the physical
> hardware lacks one or more of those axis values, additional axis
> values will be mapped above 2.
>
> Arguments:
> time -- uint -- standard event timestamp
> pad_index -- uint -- which gamepad this is
> stick_index -- uint -- 0 for le

Re: Input and games.

[Jason Ekstrand]

Todd,
I think you forgot reply-all.  I add wayland-devel again.

On Fri, Apr 26, 2013 at 5:50 PM, Todd Showalter wrote:

> On Fri, Apr 26, 2013 at 5:46 PM, Jason Ekstrand 
> wrote:
>
> > My first general comment is about floating point.  I'm not 100% sure what
> > all went into the design decision to make wl_fixed have 8 bits of
> fractional
> > precision vs. 12 or 16.  I'm guessing that they wanted the increased
> integer
> > capability, but you'd have to ask Kristian about that.  My understanding
> is
> > that most game controllers work with ranges of [0,1] or [-1,1] which
> would
> > be wasteful to put into wl_fixed.  Looking below, it seems as if you're
> > fairly consistently picking a 16 bit fractional part.  That breaks out of
> > the norm of the wire format a bit, but I think it's justified in this
> case.
> > The big thing is to be consistent which it looks like you're doing
> anyway.
>
> In my experience, most game controllers actually return byte
> values which you wind up interpreting either as signed or unsigned
> depending on what makes sense.  Certainly that's been the case
> historically.  In games we typically do something like:
>
> stick.x = ((float)raw_x) / (raw_x >= 0) ? 127.0f : 128.0f;
> stick.y = ((float)raw_y) / (raw_y >= 0) ? 127.0f : 128.0f;
>
> > Another concern is how to map [0, 255] onto [0, 2^15 - 1] cleanly.
> > Unfortunately, there is no good way to do this so that 0 -> 0 and 255 ->
> > 2^15 - 1.  Perhaps that doesn't matter much for games since you're
> sensing
> > human movements which will be slightly different for each controller
> anyway.
>
> There is, actually:
>
> expanded = (base << 7) | (base >> 1);
>
> ie: repeat the bit pattern down into the lower bits.  Examples:
>
>  -> (000) | (111) -> 111
> 000 -> () | (000) -> 000
> 100 -> (1000) | (10) -> 1000100
> 1011001 -> (1011001000) | (101100) -> 1011001101100
>
> And so forth.  It's the same scheme you use when doing color
> channel expansion.  I haven't seen a rigorous mathematical proof that
> it's correct, but I'd be surprised if someone more so inclined than I
> hasn't come up with one.
>

Wow, I've never seen that one before.  And yes, it is provably exactly
correct (up to a little integer round-off because of the implicit right
shift by 1).  I guess I learned a new trick today; that's really cool!


> [wl_gamepad::connect and disconnect]
>
> > Do we really need connect and disconnect timestampped?  Are those
> timestamps
> > going to be reliable/useful?  When you plug in a device, it takes a
> second
> > or two just to detect and show up in /dev.  On that time scale, "when
> did I
> > see the event?" is just as accurate as any timestamp.
>
> It seemed like all events had timestamps as part of the protocol,
> so I didn't know how fundamental that was to the underlying system.
> The only reason connect and disconnect might need to be timestamped is
> if events are going to be batched up, you might possibly have ordering
> issues with delivery.  If that's not a problem and the underlying
> system doesn't require timestamps, they can go.
>
> [wl_gamepad::button]
>
> >> The trigger_index is 0 for left stick values and 1 for right stick
> >> values.  Hardware with more triggers can potentially supply higher
> >> values; the pressure-sensitive buttons on the ps3 controller would go
> >> here, for instance.
> >
> > Could you be more clear about what other pressure-sensitive buttons on
> the
> > PS3 controller you're referring to here?  I know they went a bit
> overboard
> > on pressure sensitivity in the PS3 controller and seem to recall that
> even
> > buttons like triangle etc. were pressure-sensitive.  That said, those
> > buttons should map as buttons not triggers so that they can be picked up
> in
> > a canonical way.  Are you simply planning to double-report events there?
>
> I included this as a "this data could work without breaking the
> protocol", but it's not essential.
>
> In the particular case of the ps3 (and all of the dual shock
> controllers, IIRC), all of the buttons are pressure sensitive with a
> [0..255] range except "start", "select", "home" (on pads that have it)
> and the stick clicks.  The face buttons, the dpad and all four
> shoulder buttons are pressure sensitive.  Whether it's worth exporting
> that is another question entirely; I've heard rumour that the ps4
> controller removes pressure sensing from a lot of the buttons.
>
> [wl_gamepad::extended]
>
> > My feeling on this would be to wait until we have a use-case for it.  We
> can
> > always bump the version and add an event if it comes up.  I think that's
> > better than just assuming we can do something sensible with four generic
> > parameters.
>
> This is partly in response to things like the razer Wiimote-like
> contraption that apparently spits out piles of quaternions, and also
> things like har

Re: Input and games.

[Todd Showalter]

On Fri, Apr 26, 2013 at 8:40 PM, Jason Ekstrand  wrote:

> I think you forgot reply-all.  I add wayland-devel again.

Blast.  Sorry about that.  Thanks!

>> There is, actually:
>>
>> expanded = (base << 7) | (base >> 1);
>>
>> ie: repeat the bit pattern down into the lower bits.  Examples:
>>
>>  -> (000) | (111) -> 111
>> 000 -> () | (000) -> 000
>> 100 -> (1000) | (10) -> 1000100
>> 1011001 -> (1011001000) | (101100) -> 1011001101100
>>
>> And so forth.  It's the same scheme you use when doing color
>> channel expansion.  I haven't seen a rigorous mathematical proof that
>> it's correct, but I'd be surprised if someone more so inclined than I
>> hasn't come up with one.
>
> Wow, I've never seen that one before.  And yes, it is provably exactly
> correct (up to a little integer round-off because of the implicit right
> shift by 1).  I guess I learned a new trick today; that's really cool!

AFAIK folks in graphics hardware have been using that trick at the
hardware level to do color channel expansion (ie: turning RGB565 into
RGB888 or the like) since at least the 90s, but like a lot of the more
clever bit manipulation tricks it's not that widely disseminated.  I
actually came up with it independently back in the 90s and was pretty
proud of myself before a co-worker I was explaining it shot me down
with "oh, *that*, yeah, that's what my raytracer does.". :)

I meant to mention in my original reply that although most
physical hardware (especially historical hardware) is linearly mapped
signed byte or unsigned byte axis values, I think a protocol that's
going to be relatively future proof needs to handle higher precision
and convert well to float.  Most games are going to want the sticks to
map cleanly to either digital up/down/left/right buttons or to [-1.0
.. 1.0] ranges, and both of those are easy translations from the [-32k
.. 32k] range.

  Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Fwd: Input and games.

[Todd Showalter]

I failed to reply-all before, so I'm forwarding this back to the list.

On Fri, Apr 26, 2013 at 5:46 PM, Jason Ekstrand  wrote:

> My first general comment is about floating point.  I'm not 100% sure what
> all went into the design decision to make wl_fixed have 8 bits of fractional
> precision vs. 12 or 16.  I'm guessing that they wanted the increased integer
> capability, but you'd have to ask Kristian about that.  My understanding is
> that most game controllers work with ranges of [0,1] or [-1,1] which would
> be wasteful to put into wl_fixed.  Looking below, it seems as if you're
> fairly consistently picking a 16 bit fractional part.  That breaks out of
> the norm of the wire format a bit, but I think it's justified in this case.
> The big thing is to be consistent which it looks like you're doing anyway.

In my experience, most game controllers actually return byte
values which you wind up interpreting either as signed or unsigned
depending on what makes sense.  Certainly that's been the case
historically.  In games we typically do something like:

stick.x = ((float)raw_x) / (raw_x >= 0) ? 127.0f : 128.0f;
stick.y = ((float)raw_y) / (raw_y >= 0) ? 127.0f : 128.0f;

> Another concern is how to map [0, 255] onto [0, 2^15 - 1] cleanly.
> Unfortunately, there is no good way to do this so that 0 -> 0 and 255 ->
> 2^15 - 1.  Perhaps that doesn't matter much for games since you're sensing
> human movements which will be slightly different for each controller anyway.

There is, actually:

expanded = (base << 7) | (base >> 1);

ie: repeat the bit pattern down into the lower bits.  Examples:

 -> (000) | (111) -> 111
000 -> () | (000) -> 000
100 -> (1000) | (10) -> 1000100
1011001 -> (1011001000) | (101100) -> 1011001101100

And so forth.  It's the same scheme you use when doing color
channel expansion.  I haven't seen a rigorous mathematical proof that
it's correct, but I'd be surprised if someone more so inclined than I
hasn't come up with one.

[wl_gamepad::connect and disconnect]

> Do we really need connect and disconnect timestampped?  Are those timestamps
> going to be reliable/useful?  When you plug in a device, it takes a second
> or two just to detect and show up in /dev.  On that time scale, "when did I
> see the event?" is just as accurate as any timestamp.

It seemed like all events had timestamps as part of the protocol,
so I didn't know how fundamental that was to the underlying system.
The only reason connect and disconnect might need to be timestamped is
if events are going to be batched up, you might possibly have ordering
issues with delivery.  If that's not a problem and the underlying
system doesn't require timestamps, they can go.

[wl_gamepad::button]

>> The trigger_index is 0 for left stick values and 1 for right stick
>> values.  Hardware with more triggers can potentially supply higher
>> values; the pressure-sensitive buttons on the ps3 controller would go
>> here, for instance.
>
> Could you be more clear about what other pressure-sensitive buttons on the
> PS3 controller you're referring to here?  I know they went a bit overboard
> on pressure sensitivity in the PS3 controller and seem to recall that even
> buttons like triangle etc. were pressure-sensitive.  That said, those
> buttons should map as buttons not triggers so that they can be picked up in
> a canonical way.  Are you simply planning to double-report events there?

I included this as a "this data could work without breaking the
protocol", but it's not essential.

In the particular case of the ps3 (and all of the dual shock
controllers, IIRC), all of the buttons are pressure sensitive with a
[0..255] range except "start", "select", "home" (on pads that have it)
and the stick clicks.  The face buttons, the dpad and all four
shoulder buttons are pressure sensitive.  Whether it's worth exporting
that is another question entirely; I've heard rumour that the ps4
controller removes pressure sensing from a lot of the buttons.

[wl_gamepad::extended]

> My feeling on this would be to wait until we have a use-case for it.  We can
> always bump the version and add an event if it comes up.  I think that's
> better than just assuming we can do something sensible with four generic
> parameters.

This is partly in response to things like the razer Wiimote-like
contraption that apparently spits out piles of quaternions, and also
things like hardcore flightsticks that have things like fixed-range
throttles.  I'm not convinced it's needed either, but I figured if I
was making a proposed protocol it was worth throwing it in for the
sake of discussion.

Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailma