Recent improvements to llvmpipe made it possible to test dmabuf import
and offloading on vkms. Use our new client-buffer helper and the
presentation protocol to implement tests for simple offloading
scenarios.
Right now this is limited to the vkms default config, only providing us
with one primary and one cursor plane. In the future we can extend the
test to include more advanced scenarios.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Add a minimal implementation to allow client to use xdg_toplevel_set_fullscreen().
Note that desktest_shell does not yet properly handle various changes of the surface
state once mapped. Thus we don't handle such cases here either and just
assert on the expected behavior where appropriate.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
This test goes through all the errors one can do in weston.ini
color-profile section, and ensures they give the proper error logging.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This tests the [output] section key 'color-profile', which is meant for
setting up parametric color profiles. It tests the special names, and
fetching values from EDID. There are also tests for all accepted keys in
a [color-profile] section.
These tests are all positive. Error messages are tested in another
patch.
The test client helper changes are needed for loading the EDID file.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is for parsing multiple numbers from one weston.ini key, which
means I cannot use weston_config_section_get_double(). Also going to use
float type, which has less range than double.
Ironically, the tests fill likely fail on locales that do not use
period as the radix character.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The average tolerance was very very close on my AMD machine, but not
enough; the maximum tolerance certainly needed to be increased.
Observed on an AMD Radeon 780M with radeonsi from an October 2025 Mesa
build.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This will be useful for parsing config file entries that have several
items on key, like x,y coordinates or a list of flags. Code reading
custom color profiles from weston.ini will use this.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Which is not supported with Pixman, thus test the GL and VK renderers.
This ensures the code-path for directly forwarding client-allocated
dmabufs to the writeback connector works as expected.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Using the newly introduced create_buffer(), to which the buffer type is
passed on in order to allow taking writeback screenshots with dmabufs.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
1. Bump the kernel version to the drm-misc-next-2025-09-04 tag, fixing
various issues required for vkms testing.
2. Use /sys/bus/faux/devices/vkms/drm/ instead of /sys/devices/platform/vkms/drm/
for the card basename.
3. Bump Mesa to the commit needed for vkms+lavapipe. This also needs another
leak workaround, so the code got a small cleanup.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
The writeback output capture source may allow clients to select from
multiple possible formats. Update the protocol and its users
accordingly, and add formats_done event, making the implementation
easier and following common protocol practice.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Follow-up of "color: introduce output color effects". This adds a few
sanity tests for color effects.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This adds a ton of weston assert macros that were missing, as well as
tests for all of that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Currently weston-test-assert.h has a better naming style than
weston-assert.h: more concise and standardized.
So let's copy the same style to weston-assert.h
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Fixes the following mem leak:
=================================================================
==191==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7f6b843f6610 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7f6b8302f499 in output_created_listener ../tests/weston-test.c:145
#2 0x7f6b83032dcd in wet_module_init ../tests/weston-test.c:857
#3 0x7f6b842b8425 in wet_load_module ../frontend/main.c:989
#4 0x7f6b842b89eb in load_modules ../frontend/main.c:1069
#5 0x7f6b842d2711 in wet_main ../frontend/main.c:4865
#6 0x562862e934d6 in execute_compositor ../tests/weston-test-fixture-compositor.c:431
#7 0x562862e9756b in weston_test_harness_execute_as_client ../tests/weston-test-runner.c:570
#8 0x562862e81e1d in fixture_setup ../tests/drm-writeback-screenshot-test.c:48
#9 0x562862e81e9e in fixture_setup_run_ ../tests/drm-writeback-screenshot-test.c:50
#10 0x562862e97bb6 in main ../tests/weston-test-runner.c:726
#11 0x7f6b83d33ca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Fixes the following memory leak:
=================================================================
==191==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7f18bfa83610 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7f18bf890191 in zalloc ../include/libweston/zalloc.h:38
#2 0x7f18bf89184c in weston_log_ctx_add_log_scope ../libweston/weston-log.c:631
#3 0x7f18bf891c2c in weston_compositor_add_log_scope ../libweston/weston-log.c:696
#4 0x7f18be524ef6 in wet_module_init ../tests/weston-test.c:864
#5 0x7f18bf945425 in wet_load_module ../frontend/main.c:989
#6 0x7f18bf9459eb in load_modules ../frontend/main.c:1069
#7 0x7f18bf95f711 in wet_main ../frontend/main.c:4865
#8 0x557b36c114d6 in execute_compositor ../tests/weston-test-fixture-compositor.c:431
#9 0x557b36c1556b in weston_test_harness_execute_as_client ../tests/weston-test-runner.c:570
#10 0x557b36bffe1d in fixture_setup ../tests/drm-writeback-screenshot-test.c:48
#11 0x557b36bffe9e in fixture_setup_run_ ../tests/drm-writeback-screenshot-test.c:50
#12 0x557b36c15bb6 in main ../tests/weston-test-runner.c:726
#13 0x7f18bf3c0ca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7f18bfa83610 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7f18be521499 in output_created_listener ../tests/weston-test.c:145
#2 0x7f18be524dcd in wet_module_init ../tests/weston-test.c:857
#3 0x7f18bf945425 in wet_load_module ../frontend/main.c:989
#4 0x7f18bf9459eb in load_modules ../frontend/main.c:1069
#5 0x7f18bf95f711 in wet_main ../frontend/main.c:4865
#6 0x557b36c114d6 in execute_compositor ../tests/weston-test-fixture-compositor.c:431
#7 0x557b36c1556b in weston_test_harness_execute_as_client ../tests/weston-test-runner.c:570
#8 0x557b36bffe1d in fixture_setup ../tests/drm-writeback-screenshot-test.c:48
#9 0x557b36bffe9e in fixture_setup_run_ ../tests/drm-writeback-screenshot-test.c:50
#10 0x557b36c15bb6 in main ../tests/weston-test-runner.c:726
#11 0x7f18bf3c0ca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 33 byte(s) in 1 object(s) allocated from:
#0 0x7f18bfa7dd60 in strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:578
#1 0x7f18bf8918ed in weston_log_ctx_add_log_scope ../libweston/weston-log.c:639
#2 0x7f18bf891c2c in weston_compositor_add_log_scope ../libweston/weston-log.c:696
#3 0x7f18be524ef6 in wet_module_init ../tests/weston-test.c:864
#4 0x7f18bf945425 in wet_load_module ../frontend/main.c:989
#5 0x7f18bf9459eb in load_modules ../frontend/main.c:1069
#6 0x7f18bf95f711 in wet_main ../frontend/main.c:4865
#7 0x557b36c114d6 in execute_compositor ../tests/weston-test-fixture-compositor.c:431
#8 0x557b36c1556b in weston_test_harness_execute_as_client ../tests/weston-test-runner.c:570
#9 0x557b36bffe1d in fixture_setup ../tests/drm-writeback-screenshot-test.c:48
#10 0x557b36bffe9e in fixture_setup_run_ ../tests/drm-writeback-screenshot-test.c:50
#11 0x557b36c15bb6 in main ../tests/weston-test-runner.c:726
#12 0x7f18bf3c0ca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Fixes the following UAF:
==191==ERROR: AddressSanitizer: heap-use-after-free on address 0x518000000360 at pc 0x7f1ee142f5df bp 0x7ffe60aaf010 sp 0x7ffe60aaf008
READ of size 8 at 0x518000000360 thread T0
#0 0x7f1ee142f5de in output_destroyed_listener ../tests/weston-test.c:166
#1 0x7f1ee25f08eb in wl_signal_emit_mutable ../src/wayland-server.c:2401
#2 0x7f1ee274c7f8 in weston_compositor_remove_output ../libweston/compositor.c:7877
#3 0x7f1ee274fa92 in weston_output_release ../libweston/compositor.c:8641
#4 0x7f1ee146e5f8 in drm_output_destroy ../libweston/backend-drm/drm.c:2626
#5 0x7f1ee27552df in weston_compositor_shutdown ../libweston/compositor.c:9941
#6 0x7f1ee2756a89 in weston_compositor_destroy ../libweston/compositor.c:10369
#7 0x7f1ee286bed8 in wet_main ../frontend/main.c:4934
#8 0x56113c4244d6 in execute_compositor ../tests/weston-test-fixture-compositor.c:431
#9 0x56113c42856b in weston_test_harness_execute_as_client ../tests/weston-test-runner.c:570
#10 0x56113c412e1d in fixture_setup ../tests/drm-writeback-screenshot-test.c:48
#11 0x56113c412e9e in fixture_setup_run_ ../tests/drm-writeback-screenshot-test.c:50
#12 0x56113c428bb6 in main ../tests/weston-test-runner.c:726
#13 0x7f1ee22ccca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#14 0x7f1ee22ccd64 in __libc_start_main_impl ../csu/libc-start.c:360
#15 0x56113c412860 in _start (/home/mvlad/vkms/weston/b/tests/test-drm-writeback-screenshot+0xe860) (BuildId: 9f9e2ed12b9317dd859498374500f2406c32e5d3)
0x518000000360 is located 736 bytes inside of 792-byte region [0x518000000080,0x518000000398)
freed by thread T0 here:
#0 0x7f1ee298e8f8 in free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0x7f1ee1433002 in wet_module_init ../tests/weston-test.c:882
#2 0x7f1ee2851425 in wet_load_module ../frontend/main.c:989
#3 0x7f1ee28519eb in load_modules ../frontend/main.c:1069
#4 0x7f1ee286b711 in wet_main ../frontend/main.c:4865
#5 0x56113c4244d6 in execute_compositor ../tests/weston-test-fixture-compositor.c:431
#6 0x56113c42856b in weston_test_harness_execute_as_client ../tests/weston-test-runner.c:570
#7 0x56113c412e1d in fixture_setup ../tests/drm-writeback-screenshot-test.c:48
#8 0x56113c412e9e in fixture_setup_run_ ../tests/drm-writeback-screenshot-test.c:50
#9 0x56113c428bb6 in main ../tests/weston-test-runner.c:726
#10 0x7f1ee22ccca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
previously allocated by thread T0 here:
#0 0x7f1ee298f610 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7f1ee142edc5 in zalloc ../include/libweston/zalloc.h:38
#2 0x7f1ee1432cba in wet_module_init ../tests/weston-test.c:840
#3 0x7f1ee2851425 in wet_load_module ../frontend/main.c:989
#4 0x7f1ee28519eb in load_modules ../frontend/main.c:1069
#5 0x7f1ee286b711 in wet_main ../frontend/main.c:4865
#6 0x56113c4244d6 in execute_compositor ../tests/weston-test-fixture-compositor.c:431
#7 0x56113c42856b in weston_test_harness_execute_as_client ../tests/weston-test-runner.c:570
#8 0x56113c412e1d in fixture_setup ../tests/drm-writeback-screenshot-test.c:48
#9 0x56113c412e9e in fixture_setup_run_ ../tests/drm-writeback-screenshot-test.c:50
#10 0x56113c428bb6 in main ../tests/weston-test-runner.c:726
#11 0x7f1ee22ccca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
For fixing the following UAF.
==191==ERROR: AddressSanitizer: heap-use-after-free on address 0x518000000168 at pc 0x7f7aac77493e bp 0x7ffdd9dddc00 sp 0x7ffdd9dddbf8
READ of size 8 at 0x518000000168 thread T0
#0 0x7f7aac77493d in udev_input_destroy ../libweston/libinput-seat.c:388
#1 0x7f7aac73e632 in drm_shutdown ../libweston/backend-drm/drm.c:3623
#2 0x7f7aad9208b8 in weston_compositor_shutdown_backends ../libweston/compositor.c:10337
#3 0x7f7aad920a7d in weston_compositor_destroy ../libweston/compositor.c:10367
#4 0x7f7aada35ed8 in wet_main ../frontend/main.c:4934
#5 0x561e808014d6 in execute_compositor ../tests/weston-test-fixture-compositor.c:431
#6 0x561e8080556b in weston_test_harness_execute_as_client ../tests/weston-test-runner.c:570
#7 0x561e807efe1d in fixture_setup ../tests/drm-writeback-screenshot-test.c:48
#8 0x561e807efe9e in fixture_setup_run_ ../tests/drm-writeback-screenshot-test.c:50
#9 0x561e80805bb6 in main ../tests/weston-test-runner.c:726
#10 0x7f7aad496ca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#11 0x7f7aad496d64 in __libc_start_main_impl ../csu/libc-start.c:360
#12 0x561e807ef860 in _start (/home/mvlad/vkms/weston/b/tests/test-drm-writeback-screenshot+0xe860) (BuildId: 9f9e2ed12b9317dd859498374500f2406c32e5d3)
0x518000000168 is located 232 bytes inside of 792-byte region [0x518000000080,0x518000000398)
freed by thread T0 here:
#0 0x7f7aadb588f8 in free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0x7f7aac3f2f9d in wet_module_init ../tests/weston-test.c:878
#2 0x7f7aada1b425 in wet_load_module ../frontend/main.c:989
#3 0x7f7aada1b9eb in load_modules ../frontend/main.c:1069
#4 0x7f7aada35711 in wet_main ../frontend/main.c:4865
#5 0x561e808014d6 in execute_compositor ../tests/weston-test-fixture-compositor.c:431
#6 0x561e8080556b in weston_test_harness_execute_as_client ../tests/weston-test-runner.c:570
#7 0x561e807efe1d in fixture_setup ../tests/drm-writeback-screenshot-test.c:48
#8 0x561e807efe9e in fixture_setup_run_ ../tests/drm-writeback-screenshot-test.c:50
#9 0x561e80805bb6 in main ../tests/weston-test-runner.c:726
#10 0x7f7aad496ca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
previously allocated by thread T0 here:
#0 0x7f7aadb59610 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7f7aac3eedc5 in zalloc ../include/libweston/zalloc.h:38
#2 0x7f7aac3f2c55 in wet_module_init ../tests/weston-test.c:836
#3 0x7f7aada1b425 in wet_load_module ../frontend/main.c:989
#4 0x7f7aada1b9eb in load_modules ../frontend/main.c:1069
#5 0x7f7aada35711 in wet_main ../frontend/main.c:4865
#6 0x561e808014d6 in execute_compositor ../tests/weston-test-fixture-compositor.c:431
#7 0x561e8080556b in weston_test_harness_execute_as_client ../tests/weston-test-runner.c:570
#8 0x561e807efe1d in fixture_setup ../tests/drm-writeback-screenshot-test.c:48
#9 0x561e807efe9e in fixture_setup_run_ ../tests/drm-writeback-screenshot-test.c:50
#10 0x561e80805bb6 in main ../tests/weston-test-runner.c:726
#11 0x7f7aad496ca7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
This would be caused by not being able to compile keymaps.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
On certain setups - notably virtual machines - the output name can
be already taken (by e.g. virtio).
Given that we only use a single output for the test, do what other
tests do and don't assume any name.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Now that new formats are supported by the Vulkan renderer, update
this list to match our driver in CI for a more reasonable coverage.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Use the shared helper in order to avoid duplication. This will also
ensure that any format added to the test will also be usable by other
tests and clients.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
As required by the spec when accessing dmabufs from the CPU, see
https://docs.kernel.org/driver-api/dma-buf.html
While effectively a no-op on amd64, this fixes test failures on various
aarch64 devices, including:
- rk3588 (Panfrost, Rock5)
- rk3399 (Panfrost, PineBook Pro)
- Broadcom BCM2712 (V3D, RPi5)
- Qualcomm SDM845 (freedreno, OnePlus6)
Fixes: 303d88448 (tests: client-buffer: Add dmabuf support)
Signed-off-by: Robert Mader <robert.mader@collabora.com>
This function is required for producing color transformations from
parametric image descriptions.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Now that we are testing the more robust average error tolerance pretty
tightly, we can relax the tolerances on the maximum error which is more
flaky between GL drivers and hardware.
This makes sRGB->adobeRGB MAT test pass on radeonsi Polaris 11.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Maximum error is fragile: radeonsi on Polaris 11 has one error spike
that would force the the tolerances for everything to be much higher
than desired, and it masks changes to usual error levels.
Add a new condition to opaque_pixel_conversion: average two-norm error
statistic. The average is not as susceptible to outliers as maximum is.
We still keep the maximum error tolerance as well, to detect gross
outliers that might not sway the average enough to cause a test failure.
The new average error tolerances have been collected from the worst case
among the following + 0.01:
- GL renderer: Mesa Intel(R) HD Graphics 4600 (HSW GT2)
- GL renderer: AMD Radeon RX 550 Series (radeonsi, polaris11, ACO,
DRM 3.61, 6.12.35+deb13-amd64)
- GL renderer: llvmpipe (LLVM 19.1.7, 256 bits)
(There is no need to separately print matrix vs. clut, it is already in
the fixture name.)
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The concise table style was nice, but is getting more unwieldy as more
fields will be added. The new style won't fall apart.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When the same buffer is reused for both the first and second screenshot,
this can result in a deadlock. Avoid the issue by using a new buffer for
the second screenshot.
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
lua-shell is a new meta-shell for Weston. It does nothing in and of
itself, but is defined to be user-scriptable and configurable. A
supplied Lua script will be interpreted and executed by Weston, allowing
full control over window management in response to events.
This includes a shell.lua example script which behaves as a tiling WM.
Co-authored-by: Michael Tretter <m.tretter@pengutronix.de>
Co-authored-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
I don't know when this was improved, I just noticed that we can reduce
the tolerance here.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The sRGB expected display behavior uses the pure power-law with exponent
2.2, not the two-piece sRGB transfer function.
cmsCreate_sRGBProfileTHR() used the two-piece TF, now we use the proper
display TF.
This is particularly meaningful when implicit sRGB content is converted
to HDR formats, in order to maintain the stimuli reproduction near zero.
cmlcms_send_image_desc_info() is already sending this, it doesn't need
fixing.
Changing the curve also changes the error tolerances. The change is
theoretically a no-op, but the curve and its inverse and temporary
rounding add error. The new curve is more prone to error, so it is not
surprising we need to raise the tolerance. The color transformation does
end up as power-2.2 analytical form and I do not think it is ever
lowered to a LUT in alpha-blending test, so there is no obvious fix
improving the accuracy. The worst case point in alpha-blending still
occurs at the very same point as before.
The test reference images are updated for the same reason, they would
fail otherwise.
Both alpha-blending and color-icc-output contain the same sRGB-optical
sub-test, hence the same error tolerance.
It is surprising to have to increase the ICC roundtrip error tolerance
in color-icc-output test, given that the curves are passed as parametric
to LittleCMS, and adobeRGB case works with the old tolerance even. I did
not investigate further.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Refactoring data about a thing into one place to simplify code.
Also this function is never expected to fail, so no need for the boolean
return.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Collect all information of an item into a table entry in one place. Will
be easier to add new items this way.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The sRGB display uses a power-2.2 transfer characteristic. These enum
values refer to the two-piece sRGB transfer function instead, so they
should not be named "EOTF".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Adjust the no-GL jobs to also do no-Vulkan and only create a couple more
to cover disabling the individual renderers.
Copy the hack for obscure LLVM leak reports so that tests can pass in CI
with lavapipe for a Vulkan driver.
Disable vulkan-renderer build on debian lts for now as unsupported.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Containining the pre-compiler conditionals inside tiny functions makes
the code easier to read.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These cases were never meant to exist, but because the harness assumes
all tests must run on all fixtures, we have to return something.
This is a temporary measure to improve readability. Eventually this test
program should be split:
- shm RGB + YUV
- dmabuf RGB without force-yuv-fallback
- dmabuf YUV with and without force-yuv-fallback
or
- shm RGB + YUV
- dmabuf RGB + YUV without force-yuv-fallback
- dmabuf YUV with force-yuv-fallback
or
- shm + dmabuf; RGB + YUV without force-yuv-fallback
- dmabuf YUV with force-yuv-fallback
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
