Added cLUT profile creation to validate linearization algorithm
for DToB3 tag (direction dev to PCS). The 3DLUT is
built by using raw matrix conversion from dev to XYZ and reverse
(XYZ to device).
The test uses floating point pipeline, known as unbounded mode of LCMS.
The details are described in ICCSpecRevision_02_11_06_Float.pdf
The purpose of these new test cases is to keep the GL-renderer 3D LUT
path tested even after color-lcms and GL-renderer start using
specialized matrix-shaper paths.
These also exercise build_eotf_from_clut_profile() in color-lcms, but do
not actually verify it. These cases only test that the recovered EOTF
and its inverse produce an identity mapping together.
BT.2020 is not used in these tests, because the RGB-XYZ conversion
matrix does not stay inside [0.0, 1.0] in either direction, which would
be a problem for the 3D LUT element in the multiProcessingElement
pipelines. Handling that would have been possible, but testing with
AdobeRGB color space should suffice while keeping the test code from
being even more complicated.
roundtrip_verification() tests that we succeed in creating cms
pipelines correctly in both directions so that the resulting ICC file is
better behaved. The Weston test itself only cares about the BToD
direction.
Credits to:
Vladimir Lachine <vladimir.lachine@amd.com>
Graeme Gill <graeme@argyllcms.com>
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We will want to run the same color spaces with different types of ICC
profiles. To help with that:
1. Let struct lcms_pipeline define the test color space and
transformations and move the tolerance into a new per test case
structure.
2. Added profile type: PTYPE_MATRIX_SHAPER, PTYPE_CLUT.
PTYPE_MATRIX_SHAPER is the previously implemented type.
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This function sets some basic text tags to make an ICC file better
formed.
The code is taken from LittleCMS, https://github.com/mm2/Little-CMS.git
git revision
lcms2.13.1-28-g6ae2e99 (6ae2e99a3535417ca5c95b602eb61fdd29d294d0)
file src/cmsvirt.c.
Suggested-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds a new test helper library that depends on LittleCMS 2.
For starters, the library implements conversion from enum transfer_fn to
ICC multiProcessingElements compatible LittleCMS curve object.
That conversion allows encoding transfer funtions in ICC files and
LittleCMS pipelines with full float32 precision instead of forcing a
conversion to a 1D LUT which for power-type curves is surprisingly
imprecise.
This also adds CI tests to make sure the conversion matches our
hand-coded transfer functions.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These helpers allow collecting color difference statistics easily.
To be used in color-shaper-matrix-test.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When defining a color space with a transfer function, this looks up the
inverse transfer function without needing to store that separately.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This will be useful to make a curve in a color pipeline pass-through
without needing to special-case skipping the curve.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fix up whitespace and document what this array is for.
For the sake of slightly better readability.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Re-use color_float_apply_curve() instead of open-coding it.
Maybe makes reading the code a little easier.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Make process_pixel_using_pipeline() slightly easier to read by
extracting a meaningful function.
Pure refactoring, no behavioral changes.
Compared to previous, flip the scalar multiplication around, so that it
matches the mathematical order of matrix-vector multiplication.
Also document the layout conventions for lcmsVEC3 and lcmsMAT3. These
follow the convention used in LittleCMS for cmsVEC3 and cmsMAT3, and are
necessary to understand to review the matrix-vector multiplication for
correctness.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Make process_pixel_using_pipeline() slightly easier to read by
extracting a meaningful function.
Pure refactoring, no changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Looks like this was forgotten, and I managed to get compiler errors
about redeclaring all enums.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
It's bad form to set the same variable in multiple places, and not all
of them were even equivalent.
Move lcms2 finding to the root level build file only. It is still an
optional dependency like before, and the if-not-found checks are still
in place where actually needed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This reverts commit 1618697dc3.
The original commit was a workaround for
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2219 which was fixed
in Mesa:
- c7617d8908a970124321ce731b43d5996c3c5775 released as 20.1.0-rc1
- a0e6341fe4417e41cda0b19e4fa7f8bbe4e1dba1 released as 19.3.5
- f27e5d9df5bc9c85d45c2cb1f2a4997b453365fe released as 20.0.0
This workaround should not be necessary anymore, we don't use it in our
CI, and it was manual to begin with. Therefore remove it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
We support this as an explicit YUV fallback path in gl-renderer's dmabuf
EGLImage import path, so might as well support it in the SHM path, given
it's just YUV420 with no subsampling.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Make it obvious that weston_surface has a reference counting happening
and destruction of the weston_surface happens when the last
weston_surface reference has been accounted for.
Signed-off-by: Marius Vlad <marius.vlad@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 will allow us to create a solid weston_buffer as well, since we
need to store that separately.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Not all solid-colour views want to be opaque: sometimes we use them with
non-opaque alpha values in order to shade views underneath them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Given that we have a struct for argument params, we might as well use it
rather than have them split between the struct and native params. For
consistency between the implementations, this also includes a shift from
float to int positioning for the base offset within the compositor's
global co-ordinate space.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The name implied that it was a surface in and of itself, rather than
parameters used by a helper to create a surface and view.
Rename it now that we have weston_curtain as a name, and clean up
initialisers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
create_solid_color_surface actually returns a weston_view that it
creates internally. Since weston_solid_color_view is long and dull,
rename it to weston_curtain.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fbdev backend was deprecated in the Weston 10.0.0 release with
6338dbd581. Before that, I suggested
already in 2019 to remove it, but it was too soon then. Now it seems the
final voices asking for fbdev to be kept have been satisfied, see the
linked issue.
Fbdev-backend uses a kernel graphics UAPI (fbdev) which is sub-par for a
Wayland compositor: you cannot do GPU accelerated graphics in any
reasonable way, no hotplug support, multi-output support is tedious, and
so on. Most importantly, Linux has deprecated fbdev a long time ago due
to the UAPI fitting modern systems and use cases very poorly, but cannot
get rid of it if any users remain. Let's do here what we can to reduce
fbdev usage.
I am doing color management related additions to libweston which require
adding checks to every backend. One backend less is less churn to write
and review.
Libweston major version has already been bumped to 11, so the next
release will be Weston 11, without fbdev. enum weston_compositor_backend
entries change their numerical values.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/581
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We have a string helper which wraps asprintf(). Uses that one because it
clears out the destination string, but also it won't return the number
of bytes unlinke asprintf().
Fixes warnings like:
warning: ignoring return value of ‘asprintf’ declared with attribute
‘warn_unused_result’.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
weston_config_section_get_double() was not covered with tests before.
This patch follows the testing style already present in the file.
Cannot use ZUC_ASSERT_EQ() here, because that would convert the values
to integers before comparison. Luckily, simple strict equality
comparison works here, because we are testing conversion to float, not
the results of lossy calculations.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Everywhere else where use this trick, we also have 'used' in the
attributes, except here. Make this consistent.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/517
Signed-off-by: Pekka Paalanen <pekka.paalanen@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>
Iterate over rgb[] array instead of repeating the code for .r, .g and
.b.
Also in process_pipeline_comparison() f_max_err variable is dropped
since it was not used much.
This should make the code easier to read.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Individual struct fields are inconvenient to index into, yet most
operations on a color just repeat the same for each of RGB channel.
Being able to index into RGB avoids repeating the same code for each
channel.
Alpha channel is left as separate, since it is almost never handled the
same as RGB.
The union keeps the old .r, .g and .b addressing working. The static
asserts ensure the aliasing is correct.
For demonstration, two simple functions in color_util.c are converted.
Unfortunately initializers need to be corrected everywhere. Field .a is
not explicitly initialized because it is unused in these cases.
This change should make code easier to read.
This change requires gnu99 or c11 standard. gnu99 is already the default
in top-level meson.build.
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>
Test different scenarios where child subsurfaces of unmapped
subsurfaces would get mapped. This test will fail in various
ways without the commit
"libweston/compositor: Do not map subsurfaces without buffer"
Also try to test potential regressions of that patch.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Changing `wl_surface_damage()` to `wl_surface_damage_buffer()`
should not have an effect on the existing tests.
The new test will fail without the commit
"libweston/compositor: Cache buffer damage for synced subsurfaces"
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Give a role and a label for the test desktop shell background surface.
This makes it easier reading scenegraph dumps and other surface related
debug messages in tests when you don't have to guess what this
mysterious "PID 0, surface ID 0" surface is.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Leak found running drm-smoke-test with ASan.
Do not forget to destroy the SHM buffer by the end of the test.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This fixes a leak found running drm-smoke-test with ASan. Do not forget
to call prog_args_fini() when:
- skipping DRM-backend tests because we don't have
WESTON_TEST_SUITE_DRM_DEVICE set.
- we fail to acquire the lock needed to run DRM-backend tests.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We need to unlink this before freeing it since it's being called from
weston_signal_emit_mutable.
Signed-off-by: Derek Foreman <derek.foreman@collabora.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>
