The remaining module tests don't need to fork and talk to a test client,
so just convert them to regular modules and let them handle running their
tests themselves. Then drop test-runner.[ch].
This test case is the last user of the test-client code and it only
tests launching the test-client. In other words it's a minimal test
of the framework we're dropping, so just drop this test.
This adds a weston-test-runner for the weston test extension and
some weston test client helper methods.
Converted keyboard-test to use the new test interface, runner,
and helper methods.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=56822
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>
The weston test extension, called weston-test.so, can be loaded
from the "modules" configuration option on the command line
or in the .ini file.
Clients can bind to the "wl_test" interface to interact with
the weston test extension.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Modify the pkg-config check for setbacklight so that failure only
disables building setbacklight, instead of failing the whole configure.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
We check that we get surface.enter_output and move the pointer into
the window and make sure we get input_device.pointer_enter with
the right coordinates.
There's a lot of code for a very simple test here, so we need to
figure out how to reuse most of the event handling and such. It's also
not clear that a custom, text based protocol is practical here, we might
just use a wayland extension after all.
There are no dependencies or requirements there that we don't already
need for weston itself. So lets just always build them.
Use check_PROGRAMS for the matrix unit test case.
This test uses files from src/ so use COMPOSITOR_CFLAGS to find headers
in non-standard locations.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
The compositor will likely do an order of magnitude less matrix
inversions than point transformations with an inverse, hence we do not
really need the optimised path for single-shot invert-and-transform.
Expose only the computing of the explicit inverse matrix in the API.
However, the matrix inversion tests need access to the internal
functions. Designate a unit test build by #defining UNIT_TEST, and
export the internal functions in that case.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add a new directory tests/ for unit test applications. This directory
will be built only if --enable-tests is given to ./configure.
Add matrix-test application. It excercises especially the
weston_matrix_invert() and weston_matrix_inverse_transform() functions.
It has one test for correctness and precision, and other tests for
measuring the speed of various matrix operations.
For the record, the correctness test prints:
a random matrix:
1.112418e-02 2.628150e+00 8.205844e+02 -1.147526e-04
4.943677e-04 -1.117819e-04 -9.158849e-06 3.678122e-02
7.915063e-03 -3.093254e-04 -4.376583e+02 3.424706e-02
-2.504038e+02 2.481788e+03 -7.545445e+01 1.752909e-03
The matrix multiplied by its inverse, error:
0.000000e+00 -0.000000e+00 -0.000000e+00 -0.000000e+00
0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
-0.000000e+00 -0.000000e+00 0.000000e+00 -0.000000e+00
0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
max abs error: 0, original determinant 11595.2
Running a test loop for 10 seconds...
test fail, det: -0.00464805, error sup: inf
test fail, det: -0.0424053, error sup: 1.30787e-06
test fail, det: 5.15191, error sup: 1.15956e-06
tests: 6791767 ok, 1 not invertible but ok, 3 failed.
Total: 6791771 iterations.
These results are expected with the current precision thresholds in
src/matrix.c and tests/matrix-test.c. The random number generator is
seeded with a constant, so the random numbers should be the same on
every run. Machine speed and scheduling affect how many iterations are
run.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>