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>
Make sure the given values are finite, positive, and non-zero where
appropriate.
Because these validations are not mandated in the color-management
protocol, they are not immediate failures. They will fail the final
image description creation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Statements phrased positive are easier to understand than phrased
negative. Use "must" instead of "should".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The old code checked x for low limit and y for high limit, rather than
checking both for both limits. Fix this.
Check all value pairs rather than the first one four times. Don't stop
at the first error, record them all.
While at it, we might as well print exactly what value was the problem.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If any output uses a YUV format, instead of trying to composite into a
png, write the raw data into .yuv files for each output.
These files don't contain any metadata yet, thus one may want to convert
them into y4m files with e.g. a command like the this:
ffmpeg -s 1024x768 -r 1 -pix_fmt yuv420p -i ~/wayland-screenshot-output-0-2025-08-01_15-58-24.yuv -c:v copy screenshot.y4m
Note that this may only work for certain pixel formats, such as
DRM_FORMAT_YUV4[20|22|44], and not for e.g. DRM_FORMAT_P010.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Instead of relying on the compositor to allocate dmabufs for the
writeback connector and copying the results to the client-provided
shm-buffer, support allocating dmabufs in the client. The compositor
will pass them through to the writeback connector, effectively doing
the equivalent to "passthrough"/"plane-offloading"/"zero-copy".
Based on a patch by Chien Phung Van <chien.phungvan@vn.bosch.com>
Signed-off-by: Robert Mader <robert.mader@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>
In the next commit we will need syncing for reading. Thus adapt the sync
helper accordingly. We are not using the helper for performance-critical
tasks yet, thus there's currently no strong reason to allow users to
differentiate between the cases.
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>
If the client requests to take a screenshot using the writeback source
with a DMA buffer, Weston will get the framebuffer from that dmabuf
object and attach it to the writeback connector.
Original commit by Chien Phung Van.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Co-authored-by: Chien Phung Van <chien.phungvan@vn.bosch.com>
This is not strictly always necessary depending on the implementation,
so the extension requirement can be made optional.
Also improve its usage by first checking whether the dedicated
allocation is preferred/required by the driver, before importing
with dedicated allocation.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
So the buffer has the WESTON_BUFFER_SOLID type, which will make
additional optimizations easier going forward.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
This is identical to MAXIMIZE side where we change the state to
MAXIMIZE, and implicitly go through a state surface check.
For XWAYLAND type of windows (non weston_desktop_surface)
that surface state check will be needed. This is a temporary work-around
to avoid Weston crashing as some X11 Window types will hit this path.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
windows in the XWAYLAND state are popups and other such things that aren't
managed by libweston-desktop, so we crash if we query their position
with weston_desktop_api.
Query the position for these XWAYLAND windows based on their weston_view
and window geometry.
This should result in synthetic configure notify events no longer crashing.
Fixes#831Fixes#1019
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In a multi-screen setup, removing the first screen triggers `handle_output_move`.
If `weston_view_set_position` is called on an output that has an active popup,
it causes a weston crash due to the view has a parent.
Signed-off-by: liang zhou <liang.zhou@gehealthcare.com>
A change in the connector state require a possible full modest depending on the
hardware.
The connector wasn't set to unconnect if the head was detached while the output
is still enabled. Fix this by always checking the disable_head_link list during
drm_output_apply_state_atomic().
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
DRM_MODE_ATOMIC_TEST_ONLY shouldn't remove the head from the
drm_output::disable_head list else the head is lost for the actual modeset
action.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
The shell_set_view_fullscreen function was dereferencing
shsurf->fullscreen_output without checking if it was NULL first. This
could lead to a crash when a fullscreen surface had no associated
output during display hotplug.
Fix issue: https://gitlab.freedesktop.org/wayland/weston/-/issues/1028
Signed-off-by: liang zhou <liang.zhou@gehealthcare.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 new formats_done event has to be at the end, triggering warnings
like the following otherwise:
warning: since version not increasing
Fixes: 00902a592 (output-capture: Allow multiple formats and add formats_done event)
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Comparing floating-point values for identity is fragile. Comparaing with
a small tolerance allows for matches that differ only due to numerical
precision of computations.
The tolerance is taken from
weston_color_tf_info_from_parametric_curve().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
It is nice to see the numbers of a parametric color profile when created
from CTA or EDID or just to cross-check with weston.ini.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
