So far we have had two ways of identifying a weston_surface: by its
memory address "%p", and by its get_label function. The memory address
is not human-friendly and can get recycled. get_label() is not unique,
and in some cases it is client-controllable.
Oh, we also have the protocol object ID, but that does not exist for
internally created weston_surfaces.
We also have weston_surface::s_id, damage_track_id and flow_id. These
are used by some Perfetto instrumentation. s_id comes from a
compositor-wide counter rather than per-client counter, the others are
probably not what I'm looking for.
None of these are really nice for trace and debug prints for identifying
surfaces for human reading. Therefore, let's add one more ID, and with
it, a nice name for each surface.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds the framework to track clients with custom data. The first use
is to associate an ID with each client. The ID is much better suited for
debug printing than a pointer value.
The string representation is stored so that it can be overridden if
desired for compositor forked clients like Xwayland or shell helpers.
Change to a struct in the public header forces a major version bump for
this development cycle.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is a basic implementation. First the input parametric profile's
transfer function is decoded, and a HDR-aware luminance mapping into a
[0, 1] relative SDR luminance expected by the ICC workflow is done.
Then, a shaper+matrix ICC profile is crafted with the primaries, white
point and black point of the input profile. That is connected with the
output ICC profile similar to init_icc_to_icc_chain(). LittleCMS handles
the rendering intents.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is a basic implementation. The input ICC profile is connected to a
shaper+matrix profile that uses the output primaries, white point, and
black point. This way LittleCMS applies the rendering intent. Then, we
manually add HDR-aware luminance mapping and the output electrical
encoding when necessary.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
To see what is outside of the ICC-to-ICC pipeline, when falling back to
3D LUT for example. This will be particularly useful with
parametric<->icc color transformations.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Set up the color transformer even when steps_valid.
There will be cases where the color transformation needs to be applied
on the CPU: solid color surfaces, renderer debug drawings, and
DRM-backend 3D LUT when it cannot realize the steps for some reason.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When parametric<->ICC color transformations are created in the future,
they need more than the icc_chain. Add the needed elements.
This path is used for the 3D LUT fallback when the steps in struct
weston_color_transform cannot be used.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When parametric<->ICC color transformations are implemented, a single
cmsHTRANSFORM will not be enough for evaluating a color transformation.
At least one more curve and a matrix will be needed. This introduces the
structure to encapsulate them all. For now, we just wrap the existing
cmsHTRANSFORM.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Check that we never store an identity matrix as an arbitrary matrix.
This can make processing of weston_color_mapping more efficient.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When we have the ext-linear transfer function, normalize that into the
identity curve. Then it's easier to avoid adding unnecessary identity
elements when translating a weston_color_curve to something else.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Texture storage formats and parameters validity checks are done using
glGet*() functions which can be pretty slow depending on the OpenGL
implementation. Wrap these checks around a define disabled by default
in order to get the best OpenGL renderer performance in release
builds.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This helps to see if the driver returned garbage that triggers an
assertion failure, or if the assertion failure in
weston_output_finish_frame() is more subtle.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If we might tear, we cannot claim we don't tear.
If we read the software clock, we don't use measurements from the KMS
hardware.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Remove the explicit newline in the log message. Since the log may be wrapped by
the viewer, having the newline in there is not helpful.
While at it, rewrap the string to have shorter lines in the source code.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Check that the view and region completely cover the whole output.
If the view is (partly) semi-transparent, the background region should
cover the area below it - after the changes in the previous commits.
This allows us to remove the now redundant check in the plane selection.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
In the following commits we want to allow semi-transparent views to go
to the primary plane in more cases, e.g when two (or more) instances of
weston-simple-egl are visible on top of a black background.
In that scenario both/all instances would qualify, resulting in the
first candidate to be picked, accidentally making us use underlay
planes. While the visual result would still be correct wherever
supported by the HW (e.g. on the AMD system I mainly test on), it may
break if only overlay planes are supported. Generally it's an unexpected
and unintended change of the plane selection algorithm.
Thus let's be conservative and only consider the background region for
the last visible pnode (the one with the lowes zpos).
This leaves room for further optimizations in the future.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
The background region only contains visible parts of the region, excluding
any regions obscured by pnodes on top of it. If such (partly) opaque pnodes
have been assigned to overlay planes, we should consider them when checking
whether a view can go to the primary/scanout plane.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
To make use of recent optimizations for the is_fully_opaque
calculation, not only relying on the opaque region any more.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
When we switch to the deferred state, we want to complete all outstanding
repaints first - even ones started from the idle handler immediately
after we called weston_backend_set_deferred().
Fixes#1090
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
When we end up with invalid state, we'll be rebuilding the entire state from
scratch. This new rebuilt state would conflict with any outstanding flips,
so we need to wait until all flips are complete to begin the rebuild.
After we set the rebuilt state, we now have to be careful not to allow any
other outputs to attempt flips until the rebuilt state's flip completes,
or we could provoke an EBUSY from the drm device.
Add a recovery state machine to the drm backend to synchronize all of this.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Backends can end up in indeterminate/invalid state and be unable to
process updates.
Add a way for the backend to tell the core to stop scheduling repaints,
and a way for the backend to schedule all the repaints that should have
taken place during the invalid state period.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The paint node is_fully_opaque and is_fully_blended properties are overriden
when the paint node is censored or used to clear a hole for an underlay plane,
in which case the paint node is forced to be a solid color.
Those properties need to be recomputed when the paint node solid state changes,
that is:
- when the view becomes uncensored
- before assigning planes; if the paint node was overriden late in the repaint
loop to clear a hole for an underlay plane, those properties need to be reset
early in the next repaint loop to properly compute the visibility of
underneath views.
Signed-off-by: Arnaud Vrac <avrac@freebox.fr>
We seem to initialize the uniform with -1 so check against as the test
branch will actually try to use the supplied matrix (although it is
zero in this case).
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This seems to cause some misuse of buffer handling especially for cases
where the views are being promoted into HW planes. Vulkan clients seem
to crash at start-up while EGL clients seem to avoid being promoted to a
HW plane after changing window state (fullscreen to non-fullscreen).
Revert the now the change to better understand what is going on.
This reverts commit 119ce40714.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Some minor clarifications that the Lua script can searched in the
current working directory or passed in as an absoluate path.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
CVD correction is composed by a linear transformation, so we should be
able to collapse it into a single matrix multiplication:
Y = M * X
Where Y is the result, X is the original color, and M is the CVD
correction matrix.
As we need to perform CVD correction for every pixel, this can be
beneficial for limited hardware.
In this patch we do that, updating the libweston core code and also the
GL-renderer and its fragment shader.
Suggested-by: Christopher Healy <healych@amazon.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
CVD correction have the following format. These are linear
transformations in which M is a 3x3 matrix and X is a RGB vector.
F(X) = M * X
It is well known that CVD simulation/correction is done using straight
alpha values. So when we have alpha premultiplied values, we compute
straight alpha values first, apply the correction and premultiply by
alpha again. But this is not necessary, as we can see mathematically:
a * F(X) = a * (M * X) = M * (a * X) = F(a * X)
So do not convert premultiplied alpha values to straight alpha values
before applying CVD correction. This saves a few operations per pixel.
Note that the same does not apply to color inversion:
F(X) = 1 - X
a * F(X) = a - a * X
F(a * X) = 1 - a * X
=>
a * F(X) != F(a * X)
Suggested-by: Christopher Healy <healych@amazon.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Commit 008884f28 ("compositor: Move dirty buffer handling to paint node
early update") makes the dirty paint node bit being
cleared in the update early function which makes t too late to check in
the paint node update late where we used to accumulate painted frames.
Just move it before the early update to make we still have a way to
print painted frames counter.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
GCC 14.2 UBSan complained:
../../git/weston/tests/ivi-layout-test-plugin.c:73:15: runtime error:
load of address 0x7fbfd8d70ec0 with insufficient space for an object of
type 'const struct runner_test'
By printing the addresses, I concluded that the mentioned address is the
second element in the plugin_test_section. I guess UBSan believes that
only the first element exists. Why not, what's to tell what data
actually is inside the section or where it actually ends.
Strangely though, we use the exact same section trick in
weston-test-runner.c to iterate through all tests, and that one is
apparently fine. One difference is that weston-test-runner is built as a
static_library() while ivi-layout-test-plugin.c is a shared_library().
Anyway, ivi-layout-test-plugin is unlikely to see any development, so
let's just fix the problem in an ugly way, and get rid of the section
trickery. If someone were to add a new RUNNER_TEST() instance and forget
to add the magic into the index, the compiler would greet them with a
defined-but-not-used error.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
In function ‘drm_fb_maybe_import’,
inlined from ‘drm_fb_addfb’ at ../../git/weston/libweston/backend-drm/fb.c:236:8:
../../git/weston/libweston/backend-drm/fb.c:210:31: error: ‘num_planes’ may be used uninitialized [-Werror=maybe-uninitialized]
210 | for (plane = 0; plane < num_planes; plane++) {
Direct-display is mutually exclusive with having GBM BO, because the
point of direct-display is to not import to GBM. We can use this to make
the logic more provable to the compiler, and be more obvious about the
expectation to the human reader.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
