Now that GL-renderer and color manager implement linear light blending
for sRGB EOTF, add a test case to verify the result is expected.
As noted in test comments, this new tests is quite powerful in ensuring
the whole linear light pipeline is working correctly with 1D LUTs in
GL-renderer. This test will even catch smashing source_lut.scale = 1.0f
and source_lut.offset = 0.0f which would result in wrong texture sample
positions for LUT data.
As the assumption is that by default content and outputs are in sRGB
color space, this test should not need fix-ups or become stale when more
color management features are implemented.
The sRGB EOTF can be found in:
http://www.color.org/sRGB.pdf (beware, typos)
https://www.w3.org/Graphics/Color/srgbhttps://www.khronos.org/registry/DataFormat/specs/1.3/dataformat.1.3.html#TRANSFER_SRGB
Note on AMD Polaris 11 error threshold: this is quite likely due to
using fp16 format shadow framebuffer and GCN fp32 to fp16 conversion
instruction rounding mode. When using fp32 shadow framebuffer, the error
glitch is not present and the threshold could be significantly lower.
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>
Refactor the alpha-blending test to allow using all three images
foreground, background, and screenshot in a future new verification
function.
This is a pure refactoring, no change in behavior.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Initialize LittleCMS and use it to generate the sRGB EOTF and inverse
curves. Use these curves to define the blending color space as optical
(linear) sRGB by assuming that both content and output color spaces are
sRGB.
As a consequence, this causes Weston to do "gamma correct blending", as
in, blend in light linear space which should avoid distorting colors in
alpha gradients, when color-lcms is active.
This makes use of the 3x1D LUT support added in gl-renderer earlier, and
shows how the color manager is responsible for re-using existing color
transformation objects.
Co-authored-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the blending to output color space transformation when blitting from
the shadow to a framebuffer.
This allows the blending and output color spaces to differ as long as
shadow is used, in case a backend does not off-load the color
transformation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the sRGB to output color space transformation when blitting the
borders (decorations) into an output window (nested compositor).
Nested output does not need to be sRGB anymore, as far as the
decorations are concerned.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the sRGB to blending color space transformation for the censoring
color fill and triangle fan debug drawings.
This removes the assert that the output's blending space is (non-linear)
sRGB.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This makes weston_color_transform object be able to express
three-channel one-dimensional look-up table transformations. They are
useful for applying EOTF and EOTF^-1 mapping, or, gamma curves. They
will also be useful in optimizing a following 3D LUT tap distribution
once support for 3D LUT is added.
The code added here translates from the lut_3x1d fill_in() interface to
a GL texture to be used with SHADER_COLOR_CURVE_LUT_3x1D for
weston_surfaces.
It demonstrates how renderer data is attached to weston_color_transform
and cached.
GL_OES_texture_float_linear is required to be able to use bilinear
texture filtering with 32-bit floating-point textures, used for the LUT.
As the size of the LUT depends on what implements it, lut_3x1d fill_in()
interface is a callback to the color management component to ask for an
arbitrary size. For GL-renderer this is not important as it can easily
realize any LUT size, but when DRM-backend wants to offload the EOTF^-1
mapping to KMS (GAMMA_LUT), the LUT size comes from KMS.
Nothing actually implements lut_3x1d fill_in() yet, that will come in a
later patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds shader support for using a three-channel one-dimensional
look-up table for de/encoding input colors. This operation will be useful
for applying EOTF or its inverse, in other words, gamma curves. It will
also be useful in optimizing a following 3D LUT tap distribution once
support for 3D LUT is added.
Even though called three-channel and one-dimensional, it is actually
implemented as a one-channel two-dimensional texture with four rows.
Each row corresponds to a source color channel except the fourth one is
unused. The reason for having the fourth row is to get texture
coordinates in 1/8 steps instead of 1/6 steps. 1/6 may would not be
exact in floating- or fixed-point arithmetic and might perhaps risk
unintended results from bilinear texture filtering when we want linear
filtering only in x but not in y texture coordinates. I may be paranoid.
The LUT is applied on source colors after they have been converted to
straight RGB. It cannot be applied with pre-multiplied alpha. A LUT can
be used for both applying EOTF to go from source color space to blending
color space, and EOTF^-1 to go from blending space to output
(electrical) space. However, this type of LUT cannot do color space
conversions.
For now, this feature is hardcoded to off everywhere, to be enabled in
following patches.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Always when supported, make the fragment shader default floating point
precision high. The medium precision is roughly like half-floats, which
can be surprisingly bad. High precision does not reach even normal
32-bit float precision (by specification), but it's better. GL ES
implementations are allowed to exceed the minimum precision requirements
given in the specification.
This is an advance attempt to avoid nasty surprises from poor shader
precision.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add a new shader requirements bit input_is_premult which says whether
the texture sampling results in premultiplied alpha or not. Currently
this can be deduced fully from the shader texture variant, but in the
future there might a protocol extension to explicitly control it. Hence
the need for a new bit.
yuva2rgba() is changed to produce straight alpha always. This makes
sample_input_texture() sometimes produce straight or premultiplied
alpha. The input_is_premult bit needs to match sample_input_texture()
behavior. Doing this should save three multiplications in the shader for
straight alpha formats.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Found by ASan, several leaks like:
Direct leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x7f35fdc9c518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x55a77d6a4c6a in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x55a77d6a748e in create_shm_buffer ../../git/weston/tests/weston-test-client-helper.c:459
#3 0x55a77d6a78cd in create_shm_buffer_a8r8g8b8 ../../git/weston/tests/weston-test-client-helper.c:499
#4 0x55a77d6a4145 in surface_commit_color ../../git/weston/tests/pointer-shot-test.c:89
#5 0x55a77d6a4542 in pointer_cursor_retains_committed_buffer_after_reenter ../../git/weston/tests/pointer-shot-test.c:135
#6 0x55a77d6a4207 in wrappointer_cursor_retains_committed_buffer_after_reenter ../../git/weston/tests/pointer-shot-test.c:98
#7 0x55a77d6b15c2 in run_test ../../git/weston/tests/weston-test-runner.c:162
#8 0x55a77d6b1c63 in run_case ../../git/weston/tests/weston-test-runner.c:277
#9 0x55a77d6b1a09 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235
#10 0x55a77d6b1eeb in testsuite_run ../../git/weston/tests/weston-test-runner.c:311
#11 0x7f35f9510b6b in client_thread_routine ../../git/weston/tests/weston-test.c:479
#12 0x7f35fd7a4fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
#13 0x7f35fd8c64ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce)
Now this test has no more leaks.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes all the leaks reported by ASan in this test.
The manual pointer release in
pointer_timestamps_stop_after_client_releases_wl_pointer is slightly
awkward as we need to open-code a part of input_destroy() to avoid
double-freeing pointer->wl_pointer.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes all the leaks reported by ASan in this test.
The manual keyboard release in
keyboard_timestamps_stop_after_client_releases_wl_keyboard is slightly
awkward as we need to open-code a part of input_destroy() to avoid
double-freeing keyboard->wl_keyboard.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Found by ASan:
Direct leak of 30 byte(s) in 1 object(s) allocated from:
#0 0x7f4dcf029810 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x3a810)
#1 0x7f4dcefd2143 in handle_option ../../git/weston/shared/option-parser.c:56
#2 0x7f4dcefd2473 in long_option ../../git/weston/shared/option-parser.c:84
#3 0x7f4dcefd2bb6 in parse_options ../../git/weston/shared/option-parser.c:175
#4 0x7f4dcefc7b0d in wet_main ../../git/weston/compositor/main.c:3229
#5 0x5593dfa38ffd in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#6 0x5593dfa3ca69 in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#7 0x5593dfa2e511 in fixture_setup ../../git/weston/tests/ivi-shell-app-test.c:139
#8 0x5593dfa2e596 in fixture_setup_run_ ../../git/weston/tests/ivi-shell-app-test.c:141
#9 0x5593dfa3d01e in main ../../git/weston/tests/weston-test-runner.c:661
#10 0x7f4dcec2d09a in __libc_start_main ../csu/libc-start.c:308
#11 0x5593dfa2d769 in _start (/home/pq/build/weston-meson/tests/test-ivi-shell-app+0xd769)
when running
ASAN_OPTIONS=fast_unwind_on_malloc=0,malloc_context_size=50 \
LSAN_OPTIONS=suppressions=/home/pq/git/weston/.gitlab-ci/leak-sanitizer.supp \
./tests/test-ivi-shell-app
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes ASan reported leaks:
Direct leak of 88 byte(s) in 1 object(s) allocated from:
#0 0x7fcdc7382518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fcdc2d902f3 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7fcdc2d91cc2 in weston_desktop_xwayland_init ../../git/weston/libweston-desktop/xwayland.c:410
#3 0x7fcdc2d89aef in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:87
#4 0x7fcdc2db7300 in wet_shell_init ../../git/weston/ivi-shell/ivi-shell.c:642
#5 0x7fcdc7261de5 in wet_load_shell ../../git/weston/compositor/main.c:956
#6 0x7fcdc7272baa in wet_main ../../git/weston/compositor/main.c:3410
#7 0x55e12a669e29 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#8 0x55e12a66d85d in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#9 0x55e12a65dc48 in fixture_setup ../../git/weston/tests/ivi-layout-test-client.c:48
#10 0x55e12a65dcca in fixture_setup_run_ ../../git/weston/tests/ivi-layout-test-client.c:50
#11 0x55e12a66de12 in main ../../git/weston/tests/weston-test-runner.c:661
#12 0x7fcdc6ed709a in __libc_start_main ../csu/libc-start.c:308
#13 0x55e12a65d769 in _start (/home/pq/build/weston-meson/tests/test-ivi-layout-client+0xd769)
Indirect leak of 152 byte(s) in 1 object(s) allocated from:
#0 0x7fcdc7382518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fcdc2d89811 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7fcdc2d8992d in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:65
#3 0x7fcdc2db7300 in wet_shell_init ../../git/weston/ivi-shell/ivi-shell.c:642
#4 0x7fcdc7261de5 in wet_load_shell ../../git/weston/compositor/main.c:956
#5 0x7fcdc7272baa in wet_main ../../git/weston/compositor/main.c:3410
#6 0x55e12a669e29 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#7 0x55e12a66d85d in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#8 0x55e12a65dc48 in fixture_setup ../../git/weston/tests/ivi-layout-test-client.c:48
#9 0x55e12a65dcca in fixture_setup_run_ ../../git/weston/tests/ivi-layout-test-client.c:50
#10 0x55e12a66de12 in main ../../git/weston/tests/weston-test-runner.c:661
#11 0x7fcdc6ed709a in __libc_start_main ../csu/libc-start.c:308
#12 0x55e12a65d769 in _start (/home/pq/build/weston-meson/tests/test-ivi-layout-client+0xd769)
Indirect leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7fcdc7382518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fcdc2d8a5ae in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7fcdc2d8a89e in weston_desktop_client_create ../../git/weston/libweston-desktop/client.c:108
#3 0x7fcdc2d91d2a in weston_desktop_xwayland_init ../../git/weston/libweston-desktop/xwayland.c:415
#4 0x7fcdc2d89aef in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:87
#5 0x7fcdc2db7300 in wet_shell_init ../../git/weston/ivi-shell/ivi-shell.c:642
#6 0x7fcdc7261de5 in wet_load_shell ../../git/weston/compositor/main.c:956
#7 0x7fcdc7272baa in wet_main ../../git/weston/compositor/main.c:3410
#8 0x55e12a669e29 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#9 0x55e12a66d85d in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#10 0x55e12a65dc48 in fixture_setup ../../git/weston/tests/ivi-layout-test-client.c:48
#11 0x55e12a65dcca in fixture_setup_run_ ../../git/weston/tests/ivi-layout-test-client.c:50
#12 0x55e12a66de12 in main ../../git/weston/tests/weston-test-runner.c:661
#13 0x7fcdc6ed709a in __libc_start_main ../csu/libc-start.c:308
#14 0x55e12a65d769 in _start (/home/pq/build/weston-meson/tests/test-ivi-layout-client+0xd769)
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes ASan reported leak:
Direct leak of 136 byte(s) in 1 object(s) allocated from:
#0 0x7ff60173c518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7ff5fcfed3fa in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7ff5fcfed8bf in wet_module_init ../../git/weston/tests/ivi-layout-test-plugin.c:196
#3 0x7ff60161bd81 in wet_load_module ../../git/weston/compositor/main.c:941
#4 0x7ff60161c165 in load_modules ../../git/weston/compositor/main.c:1012
#5 0x7ff60162ced9 in wet_main ../../git/weston/compositor/main.c:3441
#6 0x559a98fd7d4c in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#7 0x559a98fdb780 in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#8 0x559a98fcbc48 in fixture_setup ../../git/weston/tests/ivi-layout-test-client.c:48
#9 0x559a98fcbcca in fixture_setup_run_ ../../git/weston/tests/ivi-layout-test-client.c:50
#10 0x559a98fdbd35 in main ../../git/weston/tests/weston-test-runner.c:661
#11 0x7ff60129109a in __libc_start_main ../csu/libc-start.c:308
#12 0x559a98fcb769 in _start (/home/pq/build/weston-meson/tests/test-ivi-layout-client+0xd769)
This also plugs the leak on wl_global_create() error path, though it
cannot really be tested.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Everything here was systematically leaking client and iviapp.
Discovered by ASan on ./tests/test-ivi-layout-client
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Leak found running drm-formats-test with ASan:
==59454==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f5302ff2459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f5302e75e3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7f5302e75e4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7f5302e76e33 in weston_drm_format_array_intersect ../libweston/drm-formats.c:340
#4 0x559dc2d3c69f in intersect_arrays_same_content ../tests/drm-formats-test.c:391
#5 0x559dc2d3c317 in wrapintersect_arrays_same_content ../tests/drm-formats-test.c:376
#6 0x559dc2d409ec in run_test ../tests/weston-test-runner.c:162
#7 0x559dc2d410f2 in run_case ../tests/weston-test-runner.c:277
#8 0x559dc2d40e8b in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x559dc2d4139b in testsuite_run ../tests/weston-test-runner.c:311
#10 0x559dc2d423c4 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x559dc2d423f4 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x559dc2d42887 in main ../tests/weston-test-runner.c:661
#13 0x7f5302c5eb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x559dc2d3642d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f5302ff2459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f5302e75e3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7f5302e75e4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x559dc2d3bc7b in intersect_arrays ../tests/drm-formats-test.c:352
#4 0x559dc2d3b678 in wrapintersect_arrays ../tests/drm-formats-test.c:339
#5 0x559dc2d409ec in run_test ../tests/weston-test-runner.c:162
#6 0x559dc2d410f2 in run_case ../tests/weston-test-runner.c:277
#7 0x559dc2d40e8b in for_each_test_case ../tests/weston-test-runner.c:235
#8 0x559dc2d4139b in testsuite_run ../tests/weston-test-runner.c:311
#9 0x559dc2d423c4 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#10 0x559dc2d423f4 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#11 0x559dc2d42887 in main ../tests/weston-test-runner.c:661
#12 0x7f5302c5eb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#13 0x559dc2d3642d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Leak found running drm-formats-test with ASan:
==58755==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67deca in subtract_arrays_modifier_invalid ../tests/drm-formats-test.c:613
#5 0x55723c67da3d in wrapsubtract_arrays_modifier_invalid ../tests/drm-formats-test.c:593
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67c9c0 in subtract_arrays_same_content ../tests/drm-formats-test.c:521
#5 0x55723c67c55b in wrapsubtract_arrays_same_content ../tests/drm-formats-test.c:504
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552
#5 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584
#5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 320 byte(s) in 5 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae74473c10 in wl_array_copy (/usr/lib/libwayland-client.so.0+0xac10)
#3 0x7fae744dbfe0 in add_format_and_modifiers ../libweston/drm-formats.c:108
#4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418
#5 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552
#6 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529
#7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#13 0x55723c680844 in main ../tests/weston-test-runner.c:661
#14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 256 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dbfb7 in add_format_and_modifiers ../libweston/drm-formats.c:104
#4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418
#5 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552
#6 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529
#7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#13 0x55723c680844 in main ../tests/weston-test-runner.c:661
#14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 256 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 128 byte(s) in 2 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae74473c10 in wl_array_copy (/usr/lib/libwayland-client.so.0+0xac10)
#3 0x7fae744dbfe0 in add_format_and_modifiers ../libweston/drm-formats.c:108
#4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418
#5 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#6 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#13 0x55723c680844 in main ../tests/weston-test-runner.c:661
#14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 96 byte(s) in 3 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dd142 in modifiers_subtract ../libweston/drm-formats.c:384
#3 0x7fae744dd408 in weston_drm_format_array_subtract ../libweston/drm-formats.c:431
#4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dd142 in modifiers_subtract ../libweston/drm-formats.c:384
#3 0x7fae744dd408 in weston_drm_format_array_subtract ../libweston/drm-formats.c:431
#4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584
#5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584
#5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67deca in subtract_arrays_modifier_invalid ../tests/drm-formats-test.c:613
#5 0x55723c67da3d in wrapsubtract_arrays_modifier_invalid ../tests/drm-formats-test.c:593
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67c9c0 in subtract_arrays_same_content ../tests/drm-formats-test.c:521
#5 0x55723c67c55b in wrapsubtract_arrays_same_content ../tests/drm-formats-test.c:504
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Fixes all ASan reported leaks for this test.
If frame_callback_wait_nofail() returns before the callback is handled,
the callback is not destroyed automatically. This happens on a protocol
error. This test intentionally triggers a protocol error.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reported by ASan.
Direct leak of 1468 byte(s) in 48 object(s) allocated from:
#0 0x7f20d7ae0330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x7f20d76894b7 in _IO_vasprintf /build/glibc-vjB4T1/glibc-2.28/libio/vasprintf.c:73
#2 0x7f20d7a66827 in __interceptor_vasprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6f827)
#3 0x7f20d7a66f76 in asprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6ff76)
#4 0x5598e3fbcdfc in buffer_transform ../../git/weston/tests/buffer-transforms-test.c:122
#5 0x5598e3fc9add in run_test ../../git/weston/tests/weston-test-runner.c:162
#6 0x5598e3fca17e in run_case ../../git/weston/tests/weston-test-runner.c:277
#7 0x5598e3fc9f24 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235
#8 0x5598e3fca406 in testsuite_run ../../git/weston/tests/weston-test-runner.c:311
#9 0x7f20d3523b6b in client_thread_routine ../../git/weston/tests/weston-test.c:479
#10 0x7f20d75e8fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
#11 0x7f20d770a4ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce)
Direct leak of 978 byte(s) in 42 object(s) allocated from:
#0 0x7f26fed07330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x7f26fe8b04b7 in _IO_vasprintf /build/glibc-vjB4T1/glibc-2.28/libio/vasprintf.c:73
#2 0x7f26fec8d827 in __interceptor_vasprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6f827)
#3 0x7f26fec8df76 in asprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6ff76)
#4 0x55989ba8c2bc in output_damage ../../git/weston/tests/output-damage-test.c:201
#5 0x55989ba8c0cb in wrapoutput_damage ../../git/weston/tests/output-damage-test.c:176
#6 0x55989ba99131 in run_test ../../git/weston/tests/weston-test-runner.c:162
#7 0x55989ba997d2 in run_case ../../git/weston/tests/weston-test-runner.c:277
#8 0x55989ba99578 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235
#9 0x55989ba99a5a in testsuite_run ../../git/weston/tests/weston-test-runner.c:311
#10 0x7f26fa57ab6b in client_thread_routine ../../git/weston/tests/weston-test.c:479
#11 0x7f26fe80ffa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
#12 0x7f26fe9314ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce)
Direct leak of 1696 byte(s) in 56 object(s) allocated from:
#0 0x7f077107f330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x7f0770c284b7 in _IO_vasprintf /build/glibc-vjB4T1/glibc-2.28/libio/vasprintf.c:73
#2 0x7f0771005827 in __interceptor_vasprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6f827)
#3 0x7f0771005f76 in asprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6ff76)
#4 0x563e6ae36dfc in output_transform ../../git/weston/tests/output-transforms-test.c:122
#5 0x563e6ae43add in run_test ../../git/weston/tests/weston-test-runner.c:162
#6 0x563e6ae4417e in run_case ../../git/weston/tests/weston-test-runner.c:277
#7 0x563e6ae43f24 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235
#8 0x563e6ae44406 in testsuite_run ../../git/weston/tests/weston-test-runner.c:311
#9 0x7f076ca26b6b in client_thread_routine ../../git/weston/tests/weston-test.c:479
#10 0x7f0770b87fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
#11 0x7f0770ca94ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce)
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The DRM backend uses changes in the cursor view memory address and
surface damage to detect when it needs to re-upload to a cursor plane
framebuffer.
However, when a cursor view is destroyed and then recreated, e.g., when
the pointer cursor surface is updated, the newly created view may have
the same memory address as the just destroyed one. If no new cursor
buffer is provided (because it was attached, committed and used
previously) when this address reuse occurs, then there also isn't any
updated surface damage and the backend doesn't update the cursor plane
framebuffer at all.
To fix this issue utilize the destroy signal to track when the cursor
view is destroyed, and clear the cached cursor_view value in drm_output.
After clearing the cached value, the next cursor view is always
considered new and thus uploaded to the plane properly.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
This reverts commit 81ef6d0ab3.
This also removes a bit from "tests: ensure color-lcms plugin loads".
Use of the shadow buffer is determined automatically based on
color transformations by the previous commit
"gl-renderer: use shadow framebuffer automatically".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This creates the FP16 shadow framebuffer automatically if the color
transformation from blending space to output space is not identity and
the backend does not claim to implement it on the renderer's behalf.
That makes the weston_output_set_renderer_shadow_buffer() API and
use-renderer-shadow weston.ini option obsolete.
To still cater for the one test that needs to enable the shadow
framebuffer in spite of not needing it for color correct blending, the
quirk it uses now also forces the shadow.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Compile time constants play an important role in keeping the shader
programs fast. Introduce an informal annotation to mark compile time
constants to make the shader code easier to reason with.
This will make much more sense once functions with compile time constant
parameters are added.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Trying to support GL ES 2.0 + extensions along with GL ES 3.0 for better
control is becoming too complicated fast. In this patch you see the
GL_RGBA vs. GL_RBA16F and GL_HALF_FLOAT vs. GL_HALF_FLOAT_OES paths.
More such cases will come, e.g. GL_RED_EXT vs. GL_R32F.
Make things simpler and require GL ES 3.0 +
GL_EXT_color_buffer_half_float for all color management related
functionality. If one doesn't have GL ES 3.0, all you lose is color
management.
Also, all extensions needed by color transformation operations are
gathered under one boolean flag instead of having a flag per extension,
again for simplicity.
This makes the GL ES extension handling much easier.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This reverts commit 36d699a164.
A different way to fix this same issue is the previous commit
"gl-renderer: do not unbind the context on output destroy"
which is needed for other reasons.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If we make EGL_NO_CONTEXT current, all following GL calls are
no-ops. This will be a problem when gl-renderer introduces
gl_renderer_color_transform containing GL textures and needs to destroy
them when weston_color_transform is destroyed. Mesa would print the the
warning that glDeleteTextures is no-op.
To fix this, keep our GL context current when destroying a GL output.
In case EGL_KHR_surfaceless_context is not available, we must use
dummy_surface.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This creates the color-lcms plugin that in the future will be using
Little CMS as the color matching module, processing ICC profiles, and
producing HDR tone mappings.
Right now, this new plugin is functionally equivalent to the no-op color
manager, except it already links to lcms2 and checks that the renderer
supports color operations.
Color-lcms is a libweston plugin that is loaded with explicit
weston_compositor API. This does not currently allow loading alternative
color manager plugins. External color manager plugins might be
considered in the future when the libweston APIs around color management
stabilize.
This libweston plugin uses the same build option as the old cms-static
Weston plugins, as they both need lcms2. The minimum version for lcms2
was chosen by what Debian Buster provides today and for no other reason.
This plugin intends to support the Wayland CM&HDR protocol extension and
hence sets supports_client_protocol to true. This will expose the
protocol extension to clients when it gets implemented.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is needed when the compositor produces any content internally:
- the lines in triangle fan debug
- the censoring color fill (unmet HDCP requirements)
Solid color surfaces do not need this special-casing because
weston_surface is supposed to carry color space information, which will
get used in gl_shader_config_init_for_view().
This makes sure the internally produced graphics fit in, e.g on a
monitor in HDR mode.
For now, just ensure there is an identity transformation. Actual
implementations in GL-renderer will follow later.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is needed when drawing anything internal directly to an output,
like the borders/decorations in a nested compositor setup. This makes
the assumption that the internal stuff starts in sRGB, which should be
safe. As borders are never blended with other content, this should also
be sufficient.
This patch is a reminder that that path exists, rather than a real
implementation. To be implemented when someone needs it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the blending space to monitor space color transform. It needs to
be implemented in the renderers, unless a backend sets
from_blend_to_output_by_backend = true, in which case the backend does
it and the renderer does not.
The intention is that from_blend_to_output_by_backend can be toggled
frame by frame to allow backends to react to dynamic change of output
color profile.
For now, renderers just assert that they don't need to do anything for
output color transform.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/467#note_814985
This starts building the framework required for implementing color
management.
The main new interface is struct weston_color_manager. This commit also
adds a no-op color manager implementation, which is used if no other
color manager is loaded. This no-op color manager simply provides
identity color transforms for everything, so that Weston keeps running
exactly like before.
weston_color_manager interface is incomplete and will be extended later.
Colorspace objects are not introduced in this commit. However, when
client content colorspace and output colorspace definitions are
combined, they will produce color transformations from client content to
output blending space and from output blending space to output space.
This commit introduces a placeholder struct for color transforms,
weston_color_transform. Objects of this type are expected to be heavy to
create and store, which is why they are designed to be shared as much as
possible, ideally making their instances unique. As color transform
description is intended to be generic in libweston core, renderers and
backends are expected to derive their own state for each transform
object as necessary. Creating and storing the derived state maybe be
expensive as well, more the reason to re-use these objects as much as
possible. E.g. GL-renderer might upload a 3D LUT into a texture and keep
the texture around. DRM-backend might create a KMS blob for a LUT and
keep that around.
As a color transform depends on both the surface and the output, a
transform object may need to be created for each unique pair of them.
Therefore color transforms are referenced from weston_paint_node. As
paint nodes exist for not just surface+output but surface+view+output
triplets, the code ensures that all paint nodes (having different view)
for the same surface+output have the same color transform state.
As a special case, if weston_color_transform is NULL, it means identity
transform. This short-circuits some checks and memory allocations, but
it does mean we use a separate member on weston_paint_node to know if
the color transform has been initialized or not.
Color transformations are pre-created at the weston_output
paint_node_z_order_list creation step. Currently the z order lists
contain all views globally, which means we populate color transforms we
may never need, e.g. a view is never shown on a particular output.
This problem should get fixed naturally when z order lists are
constructed "pruned" in the future: to contain only those paint nodes
that actually contribute to the output's image.
As nothing actually supports color transforms yet, both renderers and
the DRM-backend assert that they only get identity transforms. This
check has the side-effect that all surface-output pairs actually get a
weston_surface_color_transform_ref even though it points to NULL
weston_color_transform.
This design is inspired by Sebastian Wick's Weston color management
work.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A following patch will need the paint node in
gl_shader_config_init_for_view() for color transformations.
While passing the paint node through, rename the functions to be more
appropriate and get surface/view/output from the paint node.
This is a pure refactoring with no functional change.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A following patch will need the paint node in draw_view() for color
transformations.
While passing the paint node into draw_paint_node, also use the paint
node. This is a pure refactoring with no functional change.
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>
Store the pointer serial for events that provide one, so that it can be
used by tests to send requests that require it (e.g., setting the cursor
surface).
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
When setting a cursor surface, use the surface dimensions, instead of the
weston_surface buffer reference, to check if the surface has any
content. A weston_surface without any buffer reference may in fact
have a buffer which was committed in a previous pointer entry, dropped
by weston_surface and now held only internally by the renderer.
Without this fix, when a pointer enters a surface, the cursor image is
not correctly updated if we set a cursor surface with an already
committed buffer from a previous pointer entry, without recommitting the
cursor buffer for the current entry. This can be seen, for example, in
the experimental Wine Wayland driver which handles the cursor in a way
that leads to the following scenario:
Setup: cursor_surface.attach(buffer) & cursor_surface.commit()
On first wl_pointer.enter: pointer.set_cursor(cursor_surface)
compositor/renderer redraws
wl_pointer.leave
On second wl_pointer.enter: pointer.set_cursor(cursor_surface)
When handling the second pointer.set_cursor() request the current code
doesn't find a buffer attached to the cursor_surface (only the renderer
now has a reference to it), so it doesn't update the respective view for
the cursor.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
In commit d8e09afc9f ("tests: Convert ivi-shell-app-test.c to use
`weston_ini_setup`") the reference weston.ini for the ivi-shell was
removed, because it is not required by the test anymore.
The reference weston.ini still has value as an example for the ivi-shell
and how the ivi-shell-user-interface has to be configured. Retrieving
this information from the test case is not intuitive. Furthermore, the
file is still referenced by the ivi-shell/README, and the
configuration_data for generating the file was not fully removed.
Bring back the reference weston.ini for the ivi-shell and, while at it, cleanup
the configuration_data() to define only keys that are actually used in
weston.ivi.in.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Remove all the backend code to support drivers without universal planes.
From[1]:
"The code needed to support kernels where DRM does not support uiniversal
planes makes the DRM-backend a little more complicated, because it needs
to create fake planes for primary and cursor. The lifetimes of the fake
planes does not match the lifetime of "proper" planes, which is surprising."
And since the universal planes left the experimetal flag in 2014[2] it is
safe to remove the support now.
[1] https://gitlab.freedesktop.org/wayland/weston/-/issues/427
[2] https://cgit.freedesktop.org/drm/drm-tip/commit/?id=c7dbc6c9ae5c3baa3be755a228a349374d043b5b
Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Pekka Paalanen
Leandro Ribeiro
Alexandros Frantzis
Michael Tretter
Igor Matheus Andrade Torrente