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>
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>
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 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>
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>
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>
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>
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>
Output color effects are applied to the whole output scenegraph. It
depends on color-management being disabled, as the color effects are
applied in sRGB content.
For now we added only a few accessibility options: color inversion,
deuteranopia, protanopia and tritanopia CVD correction.
Note that surfaces presented on outputs that contains a color effect
can't be used for direct scanout (i.e. bypass composition and offloading
to KMS overlay planes). The color effect is applied in our GL-renderer.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
When we have a mirror, it will be at the same x,y position as the output
it's mirroring. On hot unplug, the current logic results in the mirroring
output being moved to the left by the width of its target output. The
mirror will then be destroyed, and the views can be left dangling outside
of usable space when a hot plug restores the outputs.
Subtly change the reflow logic to only reflow outputs to the right of the
removed output by testing co-ordinates, instead of assuming that every
output in the list is to the right of the previous.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that FAILURE_REASONS_FORCE_RENDERER isn't set for all not-scanout
capable failures, add some other reasons to the test in
dma_feedback_maybe_update.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
