This a new matrix inversion test written from scratch to be suitable for
running in CI: quick to run and automatically detects success/failure.
This all is a result of what I learnt while working on
https://gitlab.freedesktop.org/pq/fourbyfour
Computing the residual error with infinity norm comes straight from
fourbyfour documentation on how to evaluate matrix inversion error.
Most of the hard-coded test matrices have been generated with fourbyfour
project as well, as it contains the generator code. The matrices are
hard-coded here also to make testing faster, but primarily because the
generator code needs BLAS and LAPACK, and having those as Weston
dependencies would be far too much just for this.
Now, if someone wants to modify weston_matrix stuff, we should at least
detect matrix inversion and multiplication bugs.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This #define was used only by the matrix-test program, which was removed
in the previous commit.
Remove it as unused and fold away MATRIX_TEST_EXPORT.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This test program was useful a decade ago when weston_matrix_invert()
was being developed. It was a manual test program that ran for a certain
number of seconds and required human interpretation of numbers to see if
results were acceptable or not. Hence it was foundamentally unsuitable
for CI.
The way it generated random matrices for inversion testing was also very
naive, and it used the determinant value to determine invertability
which is completely bogus. This made it also a bad test for correctness.
Much better speed and correctness testing is implemented in
https://gitlab.freedesktop.org/pq/fourbyfour
with documented testing procedures. It has a copy of the weston_matrix
implementation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
'color_characteristics_config_error' test ensures that all code paths in
parse_color_characteristics() and wet_output_set_color_characteristics()
get exercised. The return value and logged error messages are checked.
Other cases test the weston_hdr_metadata_type1 validation.
These are for the sake of test coverage, but also an example of how to
test a function from main.c, and how to capture messages from
weston_log().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Check that weston.ini settings to eotf-mode and basic color
characteristics are correctly parsed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the helper we have for these, rather than open-coding.
This commit is not believed to result in any functional changes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
shell-utils contains a number of helpers which are currently in use by
both desktop-shell and kiosk-shell. In order to extend this use to
fullscreen-shell as well (which can benefit from reusing the
weston_curtain infrastructure to be able to create solid-colour views
which may or may not be opaque, as well as one function within
fullscreen-shell which was copied wholesale to shell-utils), we need to
create a separate Meson dependency object, and avoid the existing
pattern of including the source from shared/ within the source list for
each shell.
This requires creating a new top-level directory for these shared helper
functions which are required by each shell, but are not part of
libweston in and of itself.
shell-utils depends on libweston-desktop; libweston-desktop depends on
libweston; libweston depends on shared.
Thus it is not possible to expose a dependency object from the shared/
directory which declares a dependency on the libweston-desktop
dependency, as Meson processes directories in order and resolves
variable references as they are parsed.
In order to break this deadlock, this commit creates a new top-level
directory called 'shell-utils' containing only this file, which can be
parsed by Meson after libweston-desktop (making the libweston-desktop
Meson dependency variable available to the build file to declare a
dependency on that), but before the shells (making the new Meson
depenendency object available to each shell which wishes to use it).
This commit contains no functional changes to any observable code.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This is probably the simplest case to demonstrate how to use
WESTON_EXPORT_FOR_TESTS.
Previously, vertex-clip test re-built vertex-clipping.c for itself. Now
it directly links in gl-renderer.so instead as that is where
vexter-clipping.c gets built into for actual use. This probably will not
work for any installed program, but luckily tests are never installed,
so Meson makes sure the DSO is found.
Unfortunately we cannot remove the definition of dep_vertex_clipping
yet, because clients/cliptest.c needs it.
This makes vertex-clip test depend on GL-renderer, but that is where the
code is really used.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Given that the test-helper code relies on the screenshooter protocol,
make sure it's available for us to build, and the dependency ensures we
build in order.
Fixes: #588
Signed-off-by: Daniel Stone <daniels@collabora.com>
1. Use fixture_setup to set the generated by LCMS output profile based on
given chromaticities and white points. The following list of well known
chromaticities:
- sRGB
- adobe RGB
- bt2020
and white point is D65. Use INTENT_ABSOLUTE_COLORIMETRIC to avoid BPC.
Input profile is always sRGB and it is used internally by Weston as
stock profile.
2. Use these hardcoded matrixes as part of pipeline 1DLUT->3x3->1DLUT.
The diagnostic code to retrieve the transform matrix is availble into
test in the comments. The conversion matrixes generated for the
following cases:
- sRGB to sRGB (unity)
- sRGB to adobeRGB
- sRGB to BT2020
3. Compare GPU shaders(gl texture3D) vs manual pipeline calculation
Use different max tolerable error per transform.
There are comments how number of points in 3DLUT is related to tolerance.
Tolerance depends more on the 1D LUT used for the inv EOTF than
the tested 3D LUT size: 9x9x9, 17x17x17, 33x33x33, 127x127x127.
4. Enable build matrix-shaper test if color-management-lcms is enabled.
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
This simulates an output removal which should trigger a crash when
the compositor is shutdown abruptly by having a view with a listener installed
on its output_destroy signal.
This patch assumes that weston_compositor_remove_output() has already
been amended to use the more safer version for triggering signal
emission.
As both shells use this construct it should catch any potential signal
corruption.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
drm-smoke-test can't run at the same time as anything else which touches
DRM devices. This includes any test which would use the GL renderer or
GL/GBM on the client side, since they will open DRM devices to probe
them at init time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
No functional change. Moved color processing
functions into shared files which can be used
between different tests.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
This is prompted by the spurious CI failure
https://gitlab.freedesktop.org/wayland/weston/-/jobs/13891809
saying:
31/36 output-damage TIMEOUT 122.52s 8 subtests passed
32/36 output-transforms TIMEOUT 122.52s 16 subtests passed
33/36 subsurface TIMEOUT 122.52s
34/36 xwayland TIMEOUT 122.51s
35/36 ivi-shell-app TIMEOUT 122.51s
ERROR: Job failed: execution took longer than 5m0s seconds
That is hitting both kinds of timeouts at the same time: the per-test
timeouts, and the CI job total timeout.
That run seems to have had a particularly ill fortune, as a simple retry
finished the same job in 2 minutes, and the longest running test took
only 24 seconds.
Nevertheless, by Daniel Stone's suggestion let's bump both timeouts:
- the per-test timeout to 120 seconds, which with the multiplier in CI
goes up to 8 minutes
- the job timeout for all build related jobs to 15 minutes
The timeout for tests_standalone is not bumped as we are not adding
significant amounts of new tests there.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Instead of checking just the monotonicity of the blending results, this
changes the alpha-blending test to compute the reference blend result
itself and then comparing to the compositor result. This way we can be
sure that the compositor implements the exact correct formula and not
something that just looks nice, as verifying the reference images are
actually correct is hard.
The reference image is renamed to follow the fact that this is not
primarily a monotonicity test anymore. The reference image is also
redundant, but I think it has documentary value.
The #if 0'd block of code was very useful in figuring out blending
errors in a future test case, so it is included here. I have a feeling
we are going to need it again.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add a regression test to verify that the cursor image is correctly
updated when setting a cursor surface with an already committed buffer
from a previous pointer entry, without recommitting a cursor buffer for
the current entry.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
In commit "libweston: add struct weston_drm_format" we've added an API
to store and manage DRM formats and modifiers. As it has a couple of set
operations that are not so obvious, this adds unit tests to ensure
correctness. In the future we may expand this API and also improve
performance, so it is important to have this.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This will be useful in CI, where we do not want to see any skips. If
something starts to skip, that's a mistake somewhere, and want to catch
it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Code is using the form
#if ENABLE_JUNIT_XML
which is fine until we start using -Wundef. I think the existing code
would fail or at least warn if you disabled test-junit-xml with -Wundef.
Make sure ENABLE_JUNIT_XML is always defined so that -Wundef can be
added to build flags.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This test ensures that client submitted damage goes to the screen
correctly, regardless of output scale or transform.
The added quirk is explained in the test that uses it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This makes sub-tests visible in the junit output, making Gitlab test
reports more detailed.
This does not apply to zuc tests, which look like they could produce
junit XML directly. And maybe TAP? Left for another time.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds a test to ensure that the wl_shm formats YUV420, NV12 and YUYV
are decoded and converted to RGB correctly in GL-renderer.
The test deliberately uses a 256 x 256 test image so that effects from
width vs. pitch vs. stride cannot be observed, and row padding is zero.
Also padding between planes is zero. Attempting to use a test image with
less "round" dimensions lead to stride mismatch in GL-renderer, likely
due to GL_UNPACK_ALIGNMENT being left at value 4. It is unclear if YUV
wl_shm buffers' row stride needs to be aligned to 4 bytes or not, so I
did not pursue fixing it. GL-renderer seems to be confusing width, pitch
and stride even further, and not e.g. allow padding with ARGB buffers.
See also: https://gitlab.freedesktop.org/wayland/weston/-/issues/354
Furthermore, the test arranges so that each 2x2 pixel block has the same
color. This avoids having to consider chroma siting when sub-sampling.
This way all the test cases can use the same reference image.
The source image chocolate-cake.png is taken and copyright by Pekka
Paalanen, hereby licensed as
http://creativecommons.org/licenses/by-sa/4.0/ .
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
In anticipation of invasive future work on color management, add an
alpha blending test to make sure we don't break alpha blending.
The idea for doing a monotonicity test came from glennk on #dri-devel in
Freenode IRC.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Until now we had two different protocol extensions: one for the
test suite screenshooter and other for the screenshooter client.
As they are identical and this won't change, make the test suite
use the same protocol that the screenshooter client uses.
Besides the cleanup, this change will also allow us to use the
DRM writeback screenshooter in the test suite, as the test suite
implementation is hardcoded to use a renderer based screenshooter.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Convert ivi-shell-app-test.c to use `weston_ini_setup`. It also removes
the pre-made weston.ini and all the related code in the meson files.
Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Currently doesn't exist a standard way to write a weston.ini inside a test.
Here, two new functions `weston_ini_setup` and `cfgln` are introduced to
help the test writer to write a weston.ini file and load it to the test.
And `internal-screenshot-test` is converted to use the new method of write
a weston.ini. This conversion serves as example and initial API test.
The tester needs to call `weston_test_harness_execute_as_client` or
`weston_test_harness_execute_as_plugin` in the same way as before.
The `weston_ini_setup` will fill the setup->config_file with the
correct path to the weston.ini file.
The main design goal is to avoid pre-made or build-made weston.ini(s)
and keep the test as self-contained as possible.
Closes:#410
Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
This adds the first DRM-backend test. It is very simple
and was made in order to make easier to add more complex
DRM-backend tests in the future.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
With this patch we add support to run DRM-backend tests locally
in the test suite. For now this won't work in the CI, as there
are no cards available. But the plan is to achieve this by using
VKMS (virtual KMS) in the future.
To run DRM-backend tests locally, first of all the user has to
set the environment variable WESTON_TEST_SUITE_DRM_DEVICE to
'card0', 'card1' or any other device where he wants to run
the tests. Also, for now it only works if it is run as root,
but in the future this problem will be solved.
The tests will run on a non-default seat. The reason for that
is that we want to avoid opening input devices unnecessarily.
Also, since DRM-backend usage requires gaining DRM master status
on a DRM KMS device, nothing else must be using the device at
the same time. To achieve this we use a lock to run the
DRM-backend tests sequentially.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This test ensures that
"pixman-renderer: half-fix bilinear sampling on edges"
keeps on working.
Unlike in the original report
https://gitlab.freedesktop.org/wayland/weston/issues/373, here we use buffer
scale 2 instead of output scale 2 to trigger bilinear filter. The effect is the
same, the actual resulting image in the failing case is just a little
different. This is so that it will be easy to add more viewport screenshooting
tests in this program in the future.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
There will be a new test program using viewports and would like to share this
bit of code.
There are two behavioral changes:
- Compositor wp_viewporter interface version is no longer checked.
- client_create_viewport() does not leak the viewporter object.
test_viewporter_double_create needs to call bind_to_singleton_global() itself
so that the viewporter object still exists when the error event arrives.
Otherwise error verification fails.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch continues the buffer and output transforms testing by iterating
through a representative selection of buffer transforms and scales.
For more details, see the previous patch "tests: add output transform tests".
https://gitlab.freedesktop.org/wayland/weston/issues/52
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This goes through all output transforms with two different buffer transforms
and verifies the visual output against reference images.
This commit introduces a new test input image 'basic-test-card.png'. It is a
small image with deliberately odd and indivisible dimensions to provoke bad
assumptions about image sizes. It contains red, green and blue areas which are
actually text that makes it very obvious if you have e.g. color channels
swapped. It has a white thick circle to highlight aspect ratio issues, and an
orange cross to show a mixed color. The white border is for contrast and a 1px
wide detail. The whole design makes it clear if the image happens to be rotated
or flipped in any way.
The image has one pixel wide transparent border so that bilinear sampling
filter near the edges of the image would produce the same colors with both
Pixman- and GL-renderers which handle the out-of-image samples fundamentally
differently: Pixman assumes (0, 0, 0, 0) samples outside of the image, while
GL-renderer clamps sample coordinates to the edge essentially repeating the
edge pixels.
It would have been "easy" to create a full matrix of
every output scale & transform x every buffer scale & transform, but that
would have resulted in 2 renderers * 8 output transforms * 3 output scales *
8 buffer transforms * 3 buffer scales = 1152 test cases that would have all
ran strictly serially because our test harness has no parallelism inside one
test program. That would have been slow to run, and need a lot more reference
images too.
Instead, I chose to iterate separately through all output scales & transforms
(this patch) and all buffer scales & transforms (next patch). This limits the
number of test cases in this patch to 56, and allows the two test programs to
run in parallel.
I did not even pick all possible scale & transform combinations here, but just
what I think is a representative sub-set to hopefully exercise all the code
paths.
https://gitlab.freedesktop.org/wayland/weston/issues/52
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Move xwayland test to the new harness.
This is the only test that can actually skip. It does it by exit(77) and that
is fine, because there is only one test case in the file so far. To get rid of
the exit() calls we need to return a value from the TEST() function but that is
a big surgery for another time.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This migrates all the client tests that have nothing special in them to the new
test harness.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The devices test was actually using the defaults instead of
weston-test-desktop-shell in meson.build, so this patch keeps it that way.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
All plugin tests have been converted to the new harness, so the old definition
can be removed.
The one remaining test surface-screenshot is a manual test, the plugin only
installs a debug key binding. Hence it is open-coded as a normal plugin, not as
a test.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Moving to the new test harness.
Carrying the test ini file still just to keep it the same even though I
accidentally noticed the test succeeds also with --no-config.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Moving to the new harness.
It would be possible to convert every case here into a separate PLUGIN_TEST,
but I did not see the value in that at this time.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The ivi-layout-test comprises of two halves: the client and the plugin. This
migrates the test to the new test harness.
In the old harness, the plugin was built as the test in meson.build and it fork
& exec'd the client part. In the new harness client tests start from the client
program which sets up the compositor in-process, so now the client is built as
the test in meson.build and the plugin is just an additional file.
Therefore there is not need for the plugin for fork & exec anything anymore, so
all that code is removed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These are the only remaining standalone non-ZUC tests. They do not need any
changes to be built with the new harness - in fact they have already been
running through the new harness.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Instead of relying on Meson setting up environment so that Weston and tests
find all their files, build those values into the tests. This way one can
execute a test program successfully wihtout Meson, simply by running it.
The old environment variables are still honoured if set. This might change in
the future.
Baking the source or build directory paths into the tests should not regress
reproducible builds, because the binaries where test-config.h values are used
will not be installed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This replaces the old test harness with a new one.
The old harness relied on fork()'ing each test which makes tests independent,
but makes debugging them harder. The new harness runs client code in a thread
instead of a new process. A side-effect of not fork()'ing anymore is that any
failure will stop running a test series short. Fortunately we do not have any
tests that are expected to crash or fail.
The old harness executed 'weston' from Meson, with lots of setup as both
command line options and environment variables. The new harness executes
wet_main() instead: the test program itself calls the compositor main function
to execute the compositor in-process. Command line arguments are configured in
the test program itself, not in meson.build. Environment variables aside, you
are able to run a test by simply executing the test program, even if it is a
plugin test.
The new harness adds a new type of iteration: fixtures. For now, fixtures are
used to set up the compositor for tests that need a compositor. If necessary, a
fixture setup may include a data array of arbitrary type for executing the test
series for each element in the array. This will be most useful for running
screenshooting tests with both Pixman- and GL-renderers.
The new harness outputs TAP formatted results into stdout. Meson is not
switched to consume TAP yet though, because it would require a Meson version
requirement bump and would not have any benefits at this time. OTOH outputting
TAP is trivial and sets up a clear precedent of random test chatter belonging
to stderr.
This commit migrates only few tests to actually make use of the new features:
roles is a basic client test, subsurface-shot is a client test that
demonstrates the fixture array, and plugin-registry is a plugin test. The rest
of the tests will be migrated later.
Once all tests are migrated, we can remove the test-specific setup from
meson.build, leaving only the actual build instructions in there.
The not migrated tests and stand-alone tests suffer only a minor change: they
no longer fork() for each TEST(), otherwise they keep running as before.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Pekka Paalanen
Daniel Stone
Vitaly Prosyak
Marius Vlad
Simon Ser
Alexandros Frantzis
Leandro Ribeiro
Igor Matheus Andrade Torrente