Add support for the fifo protocol, which allows an application to submit
a content update that can only be applied after the previous content
update has been active for a display refresh.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In the future more than one test group will want to use presentation
feedback, so let's pull the basics into weston-test-client-helper
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We open code this in several tests. Move a single implementation to
weston-test-client-helper instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Latch is the moment when the compositor considers updates for an upcoming
redraw. Nothing that takes place after an output latches for repaint can
change what will be repainted.
This needs a more explicit treatment now that upcoming transactional
protocols require things to happen immediately after the latch (ie:
when it's too late to change the upcoming render).
Add an explicit latch point, a signal to tap for testing, and some asserts
to make sure nothing can violate the inevitability of the current render
state.
Note that currently latch is tied to repaint such that we only claim to
have latched when a repaint will happen. In a future commit this will lead
to forcing the repaint loop to fire without damage when the fifo protocol
needs something to happen after a latch. This could be an area for
future improvement.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Originally the test-asserts were abort()'ing. Then they were changed to
record the failure but not abort() anymore. These loops were missed,
accidentally turning them into endless loops on Wayland connection
failure, e.g. a protocol error.
When then loops become endless, they will repeatedly print the assertion
failure message. When run as part of the test suite via Meson, Meson
will collect all printouts in memory. Therefore the meson process will
use memory rapidly without bounds.
Break all these loops.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If the Wayland connection died, this code path ended up in an endless
loop, because test-asserts do not abort. Break out to fix this. The
test-assert records the failure, so not need to do more.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We've added a curtain to the shells so at startup we have something to
render, but this causes a flicker if someone is trying to have a seamless
transition from boot to weston.
Add a ready flag that allows the shell to indicate repaints are safe, so
we can remove the curtains and have no wasted frames at startup.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The DRM documentation states:
> Unless explicitly specified (via CRTC property or otherwise), the active
> area of a CRTC will be black by default. This means portions of the active
> area which are not covered by a plane will be black, and alpha blending of
> any planes with the CRTC background will blend with black at the lowest zpos.
See https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-abstraction
This means the view for the primary plane does not need to cover the
whole output and black areas of the scene-graph can be left out.
Doing so has various benefits - most importantly it:
1. allows us to use the plane-only path in more situations and with one
less plane, reducing memory bandwidth usage.
2. opens the path to offload arbitrary background colors in the future.
Iterate over the all visible paint nodes, remove solid-opaque-black
views so they are not considered for plane assignment and aggregate a
region that is later used to assign the primary plane.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Now that we have a glClear() region optimization for opaque solid surfaces,
we should make sure we test transparent solid surfaces as well.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that we're validating that buffer size must be an integer multiple of
scale, add some tests to make sure it's happening.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
When we're going through assign_planes and repaint, give the backend an
opportunity to see what's changed during this repaint.
Signed-off-by: Daniel Stone <daniels@collabora.com>
At the moment this is only replacing two clear calls with one. However,
when client_buffer starts using properly-bracketed CPU access, this will
become much more tedious. Introduce a helper now to make it easier.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We always have the name of a reference image to compare to; comparison
is kind of impossible without one.
Signed-off-by: Daniel Stone <daniels@collabora.com>
It's pretty trivial to make verify_screen_content() and
capture_screenshot_from_output() support decorations, so we can reuse
those in output-decorations tests rather than open-coding.
Signed-off-by: Daniel Stone <daniels@collabora.com>
get_middle_row() is a pure CPU accessor which only needs to operate on a
pixman_image_t. Pass this directly instead of struct buffer.
Signed-off-by: Daniel Stone <daniels@collabora.com>
A very marginal benefit, but why not. Any tests using screen capture are
now using a refresh rate of 0 (redraw immediately on capture request),
whilst others are using HIGHEST_OUTPUT_REFRESH.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Some client use subsurfaces with fully transparent single-pixel buffers
for various reasons, such as making it easier to order trees of
subsurfaces. As they are invisible we can simply ignore them in the
scene graph.
This allows us to use direct-scanout/plane-only in more circumstances,
as ensured in the test.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
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>
