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>
When we fail out because we couldn't even start a container or bring the
runner environment up, just retry the job.
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>
Previously I didn't think we needed this set up before assign_planes, but
certainly in the near future we'll want access to these bits for plane
assignment. It should be harmless to move them all now.
Signed-off-by: Derek Foreman <derek.foreman@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 allow users to specify a fully custom parametric color profile in
weston.ini for a certain output.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The protocol does not carry target primaries by enumeration, but in
weston.ini I want to be able to use a name rather than raw values.
Adding this API makes that possible.
main.c cannot look up the enumeration itself, because color-properties.h
is private. As it should be.
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>
If we have a solid region which is opaque, we don't need to go through
blending: we can simply emit a glClear, which has a pretty big benefit
on tilers in particular.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Instead of predicating the call to ensure_surface_buffer_is_ready() on
various conditions, move those into early exits from there.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Now that paint nodes handle solid buffers properly, we can use the same
codepath through gl-renderer for all solid buffers, regardless of
whether they're a single-pixel buffer from clients, or a weston_curtain,
or a temporary placeholder due to content-protection or direct-display.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Single-pixel buffers are, by definition, a single-colour fill across the
entire paint node. Use the draw_solid path for these where we can.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we're censoring output due to a content-protection mismatch, we
were setting draw_solid for the placeholder, but losing is_direct for
the original buffer.
There's no real effect with the current renderers, but best to be
consistent and make pnode->is_direct always accurate.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we're calling weston_surface_copy_content() from a solid buffer,
use the buffer's solid colour directly instead of our local copy.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The answer is that no, we do not need to be using the view's opaque
region. If the paint node is marked as fully opaque, that's because the
view itself is also opaque, and as we are dealing with surface
co-ordinates we don't need to be handling the transform here.
Signed-off-by: Daniel Stone <daniels@collabora.com>
drm_pending_state_apply_atomic is supposed to leave pending_state
untouched if called as a test-only and that test fails, as per the docs
for drm_pending_state_test. If it gets as far as doing the atomic test
and it fails, it doesn't free pending_state. However if it fails to even
compile the state for the atomic test (for example, if a particular
property is not implemented in the driver for a particular plane), it
frees pending_state. In this case, drm_output_propose_state will free
the contained drm_output_state again, typically leading to a segfault.
Treat failing to compile the state for the atomic test in the same way
as successfully running the atomic test but it failing.
Signed-off-by: Ray Smith <rsmith@brightsign.biz>
On 32-bit ARM, tv_sec is of type long long int. Cast to int64_t and
use PRId64 from inttypes.h instead of %ld to silence these format
warnings:
.../libweston/compositor.c: In function 'weston_compositor_print_scene_graph':
.../libweston/compositor.c:9297:14: warning: format '%ld' expects argument of type 'long int', but argument 3 has type '__time64_t' {aka 'long long int'} [-Wformat=]
.../libweston/compositor.c:9322:16: warning: format '%ld' expects argument of type 'long int', but argument 3 has type '__time64_t' {aka 'long long int'} [-Wformat=]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
On 32-bit ARM, tv_usec is of type long long int. Cast to int64_t and
use PRId64 from inttypes.h instead of %ld/%li to silence these format
warnings:
.../libweston/weston-log.c: In function 'weston_log_scope_timestamp':
.../libweston/weston-log.c:961:22: warning: format '%ld' expects argument of type 'long int', but argument 5 has type '__suseconds64_t' {aka 'long long int'} [-Wformat=]
.../libweston/weston-log.c: In function 'weston_log_timestamp':
.../libweston/weston-log.c:1015:27: warning: format '%li' expects argument of type 'long int', but argument 6 has type '__suseconds64_t' {aka 'long long int'} [-Wformat=]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Replace two always-true assertions:
weston_assert_true(wc, &other_shview->view->layer_link.layer);
with what seems to have been the intended check:
weston_assert_ptr_not_null(wc, other_shview->view->layer_link.layer);
This fixes a build warning:
.../lua-shell/lua-shell.c: In function 'lua_shell_env_view_move_behind_other_view':
.../lua-shell/lua-shell.c:1466:1: warning: the comparison will always evaluate as 'true' for the address of 'layer' will never be NULL [-Waddress]
In file included from .../include/libweston/desktop.h:27,
from .../lua-shell/lua-shell.h:27,
from .../lua-shell/lua-shell.c:33:
.../include/libweston/libweston.h:1112:23: note: 'layer' declared here
.../lua-shell/lua-shell.c: In function 'lua_shell_env_view_move_in_front_of_other_view':
.../lua-shell/lua-shell.c:1482:1: warning: the comparison will always evaluate as 'true' for the address of 'layer' will never be NULL [-Waddress]
.../include/libweston/libweston.h:1112:23: note: 'layer' declared here
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
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>
The error path in cmlcms_color_transform_create() uses
cmlcms_color_transform_destroy() to clean up. cmap_lut3d can be NULL in
that case, and cmsDeleteTransform() chokes on it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This introduces a new key for outputs in weston.ini, "color-profile".
For starters, implement a pre-defined sRGB profile and an automatic
profile.
Automatic color profiles are created based on the colorimetry-mode and
the eotf-mode of the output. EDID can also be taken into account, but it
is opt-in due to its potential unreliability.
This feature is documented as not fully implemented, because color-lcms
does not yet handle parametric color profiles together with ICC
profiles. Specifically, the stock sRGB profile is still an ICC profile,
and would not be able to be used together with a parametric output
profile.
Co-authored-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@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>
As it should have been. Found, when I temporarily needed to print
'static const struct weston_color_profile_params'.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Details are printed separately for logs and debugs, we don't need to
clutter the (short) description with these. The name_part is already
long enough for frontend-created automatic profiles.
Client-created parametric profiles will be indistinguishable from each
other, but we also don't log them anywhere. In debug prints, they are
identified by id numbers and printed in detail.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This error gets sent to clients or into the Weston log. Print the name
rather than the meaningless number.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The target luminance range is implied when not explicitly set, so maxCLL
and maxFALL should be checked against target luminances regardless of
whether target luminances are explicit.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
