Update a comment explaining what we may do in the future when
cmsSmoothToneCurve() fails.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
If we're shutting down, moving surfaces to a different output will not
be profitable. Just clear out the output mask entirely and return early.
This specifically avoids the following issue seen with the Wayland
backend when shutting down:
- outputs destroyed
- colour manager destroyed
- seats destroyed
- pointer destroyed
- sprite view destroyed
- find new output for the sprite view
- update colour profile for the sprite view
- neither the view nor the compositor has any outputs left
- try to use the stock sRGB transfer
- oops, no colour manager
Signed-off-by: Daniel Stone <daniels@collabora.com>
Since "color: do not use color steps for non-optimized pipelines",
WESTON_COLOR_MAPPING_TYPE_3D_LUT became unused. So drop it from our
code.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
For non-optimized pipelines, stop using the color steps (pre curve,
color mapping and post curve). Instead, make use of the
xform->to_shaper_plus_3dlut() vfunc.
In this patch we add a bool to signalize that the steps are valid (for
optimized pipelines) or not. If not (non-optimized ones), the vfunc must
be used.
This brings flexibility for the renderer/backend implementing the xform.
For now we only implement xform's in the GL-renderer, and this has no
behavior changes. It should be relevant when we implement the xform in
our DRM-backend, see commit "color: add to_shaper_plus_3dlut() vfunc to
struct weston_color_transform".
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This function allow us to get a shaper (3x1D LUT) + 3D LUT that is
equivalent to a certain xform.
With that, we allow backend/renderer that are not capable of handling
the color steps of the xform to fallback to something else.
E.g. when we introduce the code to offload color xform to KMS using the
DRM-backend, we'll depend on the driver/hardware implementing the color
steps. With this patch, DRM-backend should be able to fallback to a
shaper (3x1D LUT) + 3DLUT, color operations that should be commonly
supported by drivers/hardwares.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Up to now, when we were able to optimize a color pipeline, we'd delete
xform->cmap_3dlut. In such cases, we'd have a pre curve, color mapping
and post curve that Weston recognizes and implements in the shaders. So
there was no need to use xform->cmap_3dlut.
But at some point we'll try to offload such color transformations to our
DRM-backend, and we are not in control of what color operations the
hardware/driver are capable of. In such case, we may want to use the
fallback LCMS xform (xform->cmap_3dlut) and decompose it into a shaper
(3x1D LUT) + 3D LUT, as such operations should be commonly supported
by hardwares/drivers.
This shows that using the optimized pipeline or not should be a
renderer/backend decision. So do not delete xform->cmap_3dlut even when
we optimize the pipeline.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Change this function signature to look similar to
gl_color_curve_lut_3x1d(), as they do similar things.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We are filling a struct gl_renderer_color_mapping in this function,
so rename to better reflect that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Now that color mapping matrix in GL-renderer supports an offset, allow
merging and translating matrix stages with offsets.
color-icc-output test is already hitting these new paths with the
sRGB->sRGB CLUT fixture (number 6), hence new tests are not needed.
Previously, after optimization the pipeline still contained 3
consecutive matrix stages. Now, those three are combined into one.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
So we can test them on CI. For completeness and because they
are commonly used by SW decoders.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
This consolidates the parameter unpacking for the two types of
parametric curves. The goal is code that reads better.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Using more structured types allows removing one of color_pre_curve() and
color_post_curve() completely, reducing code duplication.
Ideally I would have wanted to use a single type for a curve, having
both lut and par in it, but I am not sure the unused half would still be
eliminated during compilation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reduce pasta, reads better.
Shame that the string manipulation is so cumbersome. All strings are
hardcoded literals though, so the assert is good enough.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add asserts the same as what the color mapping 3D LUT uses, for
consistency since both implement a LUT with the same principles.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The frequency of checking remaing the same, but we can use an already
needed switch statement and do not need one just for the asserts. This
makes gl_shader_config_set_color_transform() nice and short.
The MAPPING_MATRIX assert was useless, the variable is set right above.
Asserting the mapping type is valid happens already in
gl_shader_load_config_mapping().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The new function parameters acts as shorthands, making the moved code a
little more concise. It also gains an assert for an invalid mapping
type, which previously would have been awkward to code.
gl_shader_load_config() becomes easier to read.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is both more consistent with other embedded unions, and it allows
to pull the union out into its own named type in the following patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This will help reducing the duplicate open-coding of pre- and
post-curves in the following commits. This is also a step towards
eliminating the duplication between struct gl_shader_config and
gl_renderer_color_transform.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Replace a plain array with a type-safe documented structure.
This will get more wide use later.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Rather than using a two-dimensional array, provide names to the fields.
The fields are primarily used by their names, but we also need the data
as a flat array of floats, so use unions to achieve that: two different
views into the same data.
This makes the code more self-explanatory. In color-operations.c it
removes a handful of temporaries. Comparison in color-properties.c is
simplified. ARRAY_COPY() turns into an assignment.
MAX_PARAMS_PARAM_CURVE is eliminated. Instead of having to maintain a
copy in fragment.glsl, the definition there is automated.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This helps me with VScode when clangd doesn't claim this header to be
full of unknown stuff.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When weston tries to update drm head info, if the connector is disconnected, it cannot get the connector's property.
If get connector's property failed, drm_connector_assign_connector_info returns -1 and head->connector->conn, head->connector->props_drm remain to be nullptr, but they are used in update_head_from_connector, so the crash occurs.
So just return ret when drm_connector_assign_connector_info returns -1, and head->connector, head->connector will not be used later.
Signed-off-by: xufeng wang <550002860@gehealthcare.com>
Some external API's (e.g. DRM/KMS) are not capable of dealing with
enumerated color curves. In such cases, we may need to create LUT's that
correspond to such curves and give them to such API's
So add function weston_color_curve_to_3x1D_LUT() to craft 3x1D LUT from
a color curve.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
When we create a parametric color profile (we still do not fully
support, but plan to), a struct weston_color_tf_info is created.
So add a new function weston_color_curve_from_tf_info() to create a
color curve given a transfer function.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Since "color-lcms: recognize LCMS curves that matches transfer
functions", a few function names became slightly outdated. Rename them.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
LittleCMS curves contain curves that are parametric. They may be
well-known curves, and we are not checking that. If that's the case,
we should create enumerated color curves, instead of parametric.
This can be helpful for renderers and/or backends that want to implement
the curve, as they may have access to an API that accept enumerated
curves.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Not all color curves comes from parameters. For instance, with the
CM&HDR protocol users can set color curves from tf_info.
So let's add a new curve type to accommodate that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This just makes the code more readable and should help us to avoid
mistakes in the future. No behavior changes.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Follow-up of "color: define max number of params for parametric curves
and tf's". Let's do the same for LittleCMS parametric curves.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Up to now we were using 10 as the max number of params for color curves
and transfer functions. But this came from LittleCMS, whose parametric
curves may contain up to 10 params.
But out color curves and tf's are not tied to LittleCMS, so let's define
constants to help avoid confusion.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
weston_global_destroy_save() can directly destroy a global if the
compositor state is WESTON_COMPOSITOR_OFFSCREEN.
Make sure we don't try to set_user_data after this has happened.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
First of all, we make it work for NaN CIE xy values.
We also improve the error message a bit. It was only printing that the
color gamut was invalid, but it didn't explain why. This adds the
explanation (out of valid range).
And finally, we make the code a bit shorter.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The internal API to create parametric color profiles should be available
not only to libweston, but also to frontend. WL_EXPORT was missing from
the functions, so add that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Assert that the search param structure is well-formed, so that there
won't be cache misses due inconsistent fields.
Anything called from inside cmlcms_color_transform_get() can skip
asserting these.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is a nice clean-up.
The parameter-based color profile is actually fully formed. The problem
of using it is dealt in the next patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Split the create function into two parts, allocation and finalization.
All ICC-specific code is moved into callers, so that the parameter-based
profile creation can start using alloc/register too.
cmlcms_color_profile 120 bytes, so it's unlikely we could ever deal with
that allocation failing - don't even try.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
While no-op does not support these, other color managers might. Change
the wording so that the user does not think that Weston does not support
these at all.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
drm_output_propose_state() is called during from drm_assign_planes(). At this
point, the output is enabled, but it may be disabled in the current state, that
is copied.
So explicitly enable the output by setting dpms to WESTON_DPMS_ON.
The same thing is already done in drm_output_repaint() but that's to late for
drm_output_propose_state(). Move that to the fallback path when planes are
disabled. It's no longer needed in general and changing the state between the
atomic test and commit is not a good idea anyways.
Without this, the atomic commit may fail, even though the corresponding test was
successful.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Slight oversight of counting page flips from within the atomic commit
handler when we don't really have an output. Do that after *after*
checking for a valid output.
Fixes: cda8de1089, ("backend-drm: Count and display KMS page flips")
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When the 1st frame of the X11 backend is rendered by the GL renderer,
an invalid call to glBindTexture() with a target of 0 is emitted. This
is because the border status of the window renderbuffers are flagged
dirty while the border status of the output state is not. This commit
ensures that the output state and the renderbuffers border status are
dirty by default. It also enforces the creation of output border
textures even though no valid data have (yet) been passed, in which
case the textures are filled with transparent pixels.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This makes multiply_matrix_stages() handle offset vectors correctly, but
they will not apprear here yet, because
is_matrix_stage_with_zero_offset() forbids merging such matrices.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This converts weston_matrix and weston_vector to use linalg-types
internally. All direct accesses to members had to be converted
everywhere, mostly in the simplest form possible which leaves some
trivially reducable code around.
The intention is that we can now gradually migrate away from
weston_matrix in the future.
Look like one trailing space got accidentally annihilated in
compositor.c.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
