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>
At first I wanted to wrap
float tf_params[MAX_PARAMS_TF]
into a struct, so that it would become type-safe to pass into functions,
and it could be copied with a simple assignment. Then I noticed that for
tf_params to be operable, it must always be accompanied by struct
weston_color_tf_info. Hence, struct weston_color_tf was born.
The need for #define MAX_PARAMS_TF got eliminated.
Because struct weston_color_tf is a member of struct
weston_color_profile_params, now both need to not contain implicit
padding.
This patch makes the internal enumerated TF structures follow the
current protocol requests: all color channels use the same curve.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This was never used, and I happened to write a slightly different
version of it in color-lcms.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
And also for connector changes. This would allow tracking hot-plug
events from the udev/kernel and figure out that connector properties
changed.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
A infinitesimal short-flip in HDMI HDP in-out (hot-plug event) would
cause a discrepancy between kernel's connector's state and Weston
connector state resulting in kernel and Weston disagreeing on the final
connector state.
This has the undesired effect where the output would never turn on when
this short burst of HDP events come through.
To avoid that, just set the device invalid_state as true to go through a
modeset. Also, schedule a repaint when that happens to go through a
repaint.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This way we can differentiate when we get a HOTPLUG event that gave us a
CONNECTOR ID to work with.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This splits drm_backend_update_connectors into
drm_backend_update_connector and a post destroy phase/function.
There's no functional change, but this allows to pass
drm_backend_update_connector() on its own as we'll need that.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Add support for using writeback connectors as source. Those potentially
support more than one format, thus allow selecting those as well.
While on it, add a verbose flag for useful debug output.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Writeback connectors often support multiple formats, fully independent
of the input framebuffer. Wire up support for querying formats and send
them to clients.
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>
The writeback connector UAPI does not mention modifiers explicitly,
however implicitly we assume and use a linear modifier when using
dumb buffers.
Adding that to the format thus makes the assumption more obvious and
allows us to use the weston_drm_format_array as intended.
For example we can now use weston_drm_format_array_count_pairs() to
log the number of supported formats - previously it always returned 0.
See
https://www.kernel.org/doc/html/v6.16/gpu/drm-kms.html#writeback-connectors
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Create a linux_dmabuf_memory subclass so that it holds the associated
gbm_bo and it can be properly destroyed with the dmabuf object.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
This is not required and creates a refcount imbalance,
causing a memory leak at drm-backend teardown.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
