It is better to load ivi controller modules as a
generic weston module. Then, we do not need to
have a specific ivi way of loading modules.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Set the env var to override the system data directory so we can run
tests with uninstalled icons.
We don't yet use the code that checks this env var, so make distcheck
will still fail.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
weston-tests-env is a beast to handle, when you would like to start
weston manually for a test you wan to start inside gdb. This patch
causes the full command line to be printed to the automake test logs, so
you can copy it from there and run it by hand.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Cleaned up test runner script to unify sections launching weston.
This makes the sections more legible and differences easier to spot.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
make check failed for out of tree builds because we didn't set up
WESTON_TEST_REFERENCE_PATH in weston-tests-env
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Tested-by: Bryce Harrington <bryce@osg.samsung.com>
Implements a simple mechanism to allow tests to customize the
configuration. For a given <name>-test.c just place a <name>.ini file
at the same location as the test itself. Alternately, you can generate
a <name>.ini in the same directory that the compiled test is placed
(i.e. the top builddir). If no configuration file is found, then no
configuration will be used (i.e. --no-config is specified.)
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
Testing the ivi_layout API requires two things:
- the tests must be written as a controller module to access the API
- the tests need a helper client to create some objects that can then be
managed via the API
This patch adds all the infrastructure and two different kinds of
example tests.
Internal ivi-shell (ivi_layout) API tests are listed as ivi-*.la files
in TESTS in Makefile.am. Weston-tests-env detects these, and runs Weston
with ivi-shell, and loads the given module as a controller module, not
as a normal plugin.
The test controller module ivi-*.la will launch a helper client. For
ivi-layout-test.la the helper client is ivi-layout.ivi.
The helper client uses the weston-test-runner framework to fork and exec
each TEST with a fresh connection to the compositor.
The actual test is triggered by the weston_test_runner protocol
interface, a new addition to weston-test.xml. The helper client uses
weston_test_runner to trigger a test, and the server side of the
interface is implemented by the test controller module
(ivi-layout-test.la).
The server side of weston_test_runner uses the same trick as
weston-test-runner.h to gather a list of defined tests. A test is
defined with the RUNNER_TEST macro.
If a test defined by RUNNER_TEST succeeds, an event is sent to the
helper client that it can continue (or exit). If a test fails, a fatal
protocol error is sent to the helper client.
Once the helper client has iterated over all of its tests, it signals
the batch success/failure via process exit code. That is cought in the
test controller module, and forwarded as Weston's exit code.
In summary: each ivi_layout test is a combination of a client side
helper/setup and server side actual tests.
v2: Load weston-test.so, because create_client() needs it.
v3: add a comment about IVI_TEST_SURFACE_ID_BASE.
v4: Rebased to upstream weston-tests-env changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com> (v2)
This simply tests that Weston starts with ivi-shell, and ivi_application
is present.
Changes in v3:
- Rebased to upstream weston-tests-env changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com> (v2)
Also use variable default assignment to eliminate an if clause
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The log files were being named like:
surface-global-test.la-log.txt
surface-global-test.la-serverlog.txt
surface-test.la-log.txt
surface-test.la-serverlog.txt
text.weston-log.txt
text.weston-serverlog.txt
For consistency, omit the test filename's extension (.la/.so).
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
basename returns the filename without path information (but with
the file extension). We can get this more efficiently via shell
variables.
Also, for the socket name, use the test's name without the file
extension.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
[Pekka: rebased without "tests: Support --config to enable tests to
override config defaults".]
Make a little short-hand for the module directory.
This also cleans up the redefinition of BACKEND in the script.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Tests will now return the extra command line parameters they need
when run with --params
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
desktop shell and weston keyboard both refer to themselves prefixed by
LIBEXECDIR, however this is only valid once installed. make check will
currently either fail or run pre-existing versions.
This patch adds a way to override that location by setting the env var
WESTON_BUILD_DIR - which is then set by the test env script so make check
will test the versions in the build directory regardless of whether they're
installed or not.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Again, load the shell plugin with full path, rather than possibly find an
old version from a previous installation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If we do not specify the full path to xwayland.so, Weston can find an
old one installed in a $prefix and use that instead of the freshly built
one.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Use --no-config to avoid loading arbitrary weston.ini files from unit
tests. It may affect the unit test results.
I actually hit the following case:
[13:34:04.636] Using config file '/home/pq/local/etc/weston.ini'
[13:34:04.636] Loading module '/home/pq/git/weston/.libs/headless-backend.so'
[13:34:04.637] launching '/home/pq/local/libexec/weston-keyboard'
[13:34:04.644] Loading module '/home/pq/local/lib/weston/desktop-shell.so'
[13:34:04.644] Loading module '/home/pq/local/lib/weston/xwayland.so'
[13:34:04.648] unlinking stale lock file /tmp/.X1-lock
[13:34:04.648] xserver listening on display :1
[13:34:04.648] Loading module '/home/pq/git/weston/.libs/./xwayland.so'
[13:34:04.648] xserver listening on display :2
[13:34:04.648] Module '/home/pq/local/lib/weston/xwayland.so' already loaded
Weston tries to load xwayland module three times, or which twice it
succeeds. This might not make the xwayland test end well. Or at all,
actually.
Adding --no-config should remove one of these loads of xwayland.so.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Other backends can be used by passing BACKEND=some-backend.so, e.g.
$ make check BACKEND=x11-backend.so
Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
By default enabled but one can disable it by passing --disable-xwayland-test
to the configure script. Also, the weston-tests-env script is trying to load
xwayland.so in either case, but it behaves resilient in the absence of that
meaning all the other tests are still going to be kicked for running.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Without this we try to load the installed backends, which is nasty for
regular runs, and just doesn't work for make distcheck, which sets
prefix to $PWD/_inst. This makes sure we load the right backend
and make distcheck pass. Other modules (xwayland, shells etc) just don't
get loaded for distcheck and for make check we still try to load the
installed modules.
This cleans up the 'make check' output considerably. When all goes well,
you will only see the "PASS" line for each of $TESTS.
Weston logs into a separate file than stdout and stderr, so server logs
end up in one file per test, and other output to another file per test.
'make distclean' does not remove the tests/logs/ directory.
Also changes the weston-tests-env interpreter to bash, since I think &>
and ${1/.la/.so} might be bashisms.
The weston-tests-env script needs to be able to handle weston
test extension style tests as well as module style tests.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Renamed weston-test test environment script to weston-tests-env
to avoid ambiguity with weston-test.c (the weston test extension).
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
We can now load any number of general modules, and the shell and xwayland
are just two of them. We continue to use the mechanism for testing but
custom input drivers or logging mechanisms, for example are other use cases.
Emre Ucan
Derek Foreman
Quentin Glidic
Pekka Paalanen
Jon A. Cruz
Bryce Harrington
Emilio Pozuelo Monfort
Kristian Høgsberg
Peter Hutterer
Tiago Vignatti
Pekka Paalanen
U. Artie Eoff