Commit Graph

16 Commits

Author SHA1 Message Date
Leandro Ribeiro
6da5b8a5a5 color-noop: avoid assert hit in cmnoop_destroy()
When we are destroying the color manager, the components referencing
color profiles should have already been destroyed. We have an assert
in cmnoop_destroy() to make sure that the stock profile has refcount
equal to 1.

But we currently have an issue in Weston. While shutting down with
client surfaces alive, we may leak them. So we try to destroy
the color manager with surfaces still alive, and they may be
referencing color profiles.

We already have a workaround for this in our LittleCMS color plugin,
but we've missed that in color-noop. This fixes that, so now we don't
hit the assert anymore.

As we are already dealing with asserts in color-noop, I took the
liberty to replace the last usage of assert with our own wrapper
in this file.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2024-02-22 11:38:22 +00:00
Leandro Ribeiro
188a3ebd5e libweston: expose color management support
In this patch we enable the color-management protocol support, as long
as the color-manager plugin in use supports it.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2024-02-14 11:15:35 -03:00
Leandro Ribeiro
5706d7e5d2 color: add support to the color-management protocol
In this MR we add support to the majority of the interfaces from the
color-management protocol.

That means that we are able to advertise output's images descriptions to
clients, preferred surface images descriptions, and so on. We also
support clients that wants to create ICC-based images descriptions and
set such descriptions for surfaces.

We still don't support the interface to allow clients to create
image descriptions from parameters, but that should be addressed
in the near future.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2024-02-14 11:15:35 -03:00
Leandro Ribeiro
cab1992b81 color: do not use NULL as stock sRGB color profile
Stop assuming that NULL represents the stock sRGB color profile. From
now on, query the stock sRGB color profile from the color manager.

This should be internal to libweston (core and the color plugins), and
users of the libweston public API should not be affected by this. They
are still allowed to set an output color profile to the stock sRGB using
NULL.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2023-10-30 11:47:35 +00:00
Leandro Ribeiro
977c41a65c color: add get_stock_sRGB_color_profile() to color manager
In the next commit we'll stop using NULL as the stock sRGB color
profile, so add a function to the color manager to allow libweston core
to have access to the stock sRGB profile.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2023-10-30 11:47:35 +00:00
Leandro Ribeiro
154ce42b8c color-noop: add stock color profile
In the next commit we introduce a function to get the stock sRGB color
profile from the color-manager, so mock a stock color profile in the
color-noop.

It has no valid content, but should make callers happy. This is safe to
do because the color profile is opaque, and only color-noop itself
should have access to its content.

color-lcms already has a stock sRGB color profile, so we don't have
to do anything there.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2023-10-30 11:47:35 +00:00
Leandro Ribeiro
33ed93561e color-noop: make use of xalloc helpers
Use xzalloc instead of zalloc, etc.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2023-10-30 11:47:35 +00:00
Pekka Paalanen
cea53a90d4 libweston: add HDR metadata to weston_output
This adds hdr_meta field in weston_output_color_outcome. This field is
intended to be set by color manager modules, and read by backends which
will send the information to the video sink in SMPTE ST 2084 mode a.k.a
Perceptual Quantizer HDR system.

Such metadata is essential in ST 2084 mode for the video sink to produce
a good picture.

The validation of the data and the group split is based on the HDR
Static Metata Type 1 definition in CTA-861-G specification.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2022-05-27 10:30:35 +00:00
Pekka Paalanen
dfba19abde color: simplify color manager API with weston_output_color_outcome
I am going to need to add yet another output property to be set by a
color manager: HDR Static Metadata Type 1. With the old color manager
API design, I would have needed to add the fourth function pointer to be
called always in the same group as the previous three. This seemed more
convoluted than it needs to be.

Therefore collapse the three existing function pointers in the API into
just one that is resposible for setting up all three things.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2022-05-06 09:33:35 +00:00
Pekka Paalanen
46c0383c14 color-noop: supports only SDR EOTF mode
The no-op color manager will not support any other EOTF mode than SDR.
Other modes would require it to set up color transformations.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2022-05-02 12:19:24 +00:00
Pekka Paalanen
9a9e6ced1b libweston: add weston_output::color_profile
Add API to set an output's color profile. This new function can also be
called while the output is enabled. This allows changing the output
color profile even at runtime if desired.

color-noop has no way of creating weston_color_profile objects, so it
just asserts that no color profile is set.

color-lcms does not yet implement taking the output color profile into
account, so for now it just fails everything if a profile is set.

weston_surface_color_transform_fini() was previously used only prior to
freeing the struct, but now it is used also to just clear the struct,
hence it needs to reset the fields.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-11-23 09:23:05 +00:00
Pekka Paalanen
aa6346f274 color: introduce weston_color_profile
Roughly speaking, a color profile describes the color space of content
or an output. Under the hood, the description includes one or more ways
to map colors between the profile space and some standard profile
connecting space (PCS).

This object is not called a color space. A color space has a unique
definition, while a color profile may contain multiple different
mappings depending on render intent. Some of these mappings may be
subjective, with an artistic touch.

When a source color profile and a destination color profile are combined
under a specific render intent, they produce a color transformation.
Color transformations are already preresented by weston_color_transform.

This patch adds the basic API for color profile objects. Everything
worthwhile of these objects is implemented in the color managers:
color-noop never creates these, and in color-lcms they are basically a
container for cmsHPROFILE, the Little CMS object for color profiles.
Color profile objects will not be interpreted outside of the color
managers, unlike color transformations.

For a start, the color manager API has one function to create color
profiles: from ICC profile data. More creation functions for other
sources will be added later.

The API has errmsg return parameter for error messages. These are not
simply weston_log()'d, because CM&HDR protocol will allow clients to
trigger errors and the protocol handles that gracefully. Therefore
instead of flooding the compositor logs, the error messages will
probably need to be relayed back to clients.

Color-lcms is expected to create a cmsHPROFILE for all kinds of color
profiles, not just for those created from ICC profile data. Hence,
color-lcms will fingerprint color profiles by the MD5 hash which Little
CMS computes for us. The fingerprint is used for de-duplication: instead
of creating copies, reference existing color profiles.

This code is very much based on Sebastian Wick's earlier work on Weston
color management, but structured and named differently.

Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-11-23 09:23:05 +00:00
Pekka Paalanen
8fb23ed110 color: add from sRGB to blending color transformation
This is needed when the compositor produces any content internally:
- the lines in triangle fan debug
- the censoring color fill (unmet HDCP requirements)

Solid color surfaces do not need this special-casing because
weston_surface is supposed to carry color space information, which will
get used in gl_shader_config_init_for_view().

This makes sure the internally produced graphics fit in, e.g on a
monitor in HDR mode.

For now, just ensure there is an identity transformation. Actual
implementations in GL-renderer will follow later.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 12:53:41 +00:00
Pekka Paalanen
cda3951a9a color: add from sRGB to output color transformation
This is needed when drawing anything internal directly to an output,
like the borders/decorations in a nested compositor setup. This makes
the assumption that the internal stuff starts in sRGB, which should be
safe. As borders are never blended with other content, this should also
be sufficient.

This patch is a reminder that that path exists, rather than a real
implementation. To be implemented when someone needs it.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 12:53:41 +00:00
Pekka Paalanen
1d2eee208c color: add output color transform API
This is the blending space to monitor space color transform. It needs to
be implemented in the renderers, unless a backend sets
from_blend_to_output_by_backend = true, in which case the backend does
it and the renderer does not.

The intention is that from_blend_to_output_by_backend can be toggled
frame by frame to allow backends to react to dynamic change of output
color profile.

For now, renderers just assert that they don't need to do anything for
output color transform.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 12:53:41 +00:00
Pekka Paalanen
90a5ffa097 libweston: introduce CMS component architecture
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/467#note_814985

This starts building the framework required for implementing color
management.

The main new interface is struct weston_color_manager. This commit also
adds a no-op color manager implementation, which is used if no other
color manager is loaded. This no-op color manager simply provides
identity color transforms for everything, so that Weston keeps running
exactly like before.

weston_color_manager interface is incomplete and will be extended later.

Colorspace objects are not introduced in this commit. However, when
client content colorspace and output colorspace definitions are
combined, they will produce color transformations from client content to
output blending space and from output blending space to output space.

This commit introduces a placeholder struct for color transforms,
weston_color_transform. Objects of this type are expected to be heavy to
create and store, which is why they are designed to be shared as much as
possible, ideally making their instances unique. As color transform
description is intended to be generic in libweston core, renderers and
backends are expected to derive their own state for each transform
object as necessary. Creating and storing the derived state maybe be
expensive as well, more the reason to re-use these objects as much as
possible. E.g. GL-renderer might upload a 3D LUT into a texture and keep
the texture around. DRM-backend might create a KMS blob for a LUT and
keep that around.

As a color transform depends on both the surface and the output, a
transform object may need to be created for each unique pair of them.
Therefore color transforms are referenced from weston_paint_node. As
paint nodes exist for not just surface+output but surface+view+output
triplets, the code ensures that all paint nodes (having different view)
for the same surface+output have the same color transform state.

As a special case, if weston_color_transform is NULL, it means identity
transform. This short-circuits some checks and memory allocations, but
it does mean we use a separate member on weston_paint_node to know if
the color transform has been initialized or not.

Color transformations are pre-created at the weston_output
paint_node_z_order_list creation step. Currently the z order lists
contain all views globally, which means we populate color transforms we
may never need, e.g. a view is never shown on a particular output.
This problem should get fixed naturally when z order lists are
constructed "pruned" in the future: to contain only those paint nodes
that actually contribute to the output's image.

As nothing actually supports color transforms yet, both renderers and
the DRM-backend assert that they only get identity transforms. This
check has the side-effect that all surface-output pairs actually get a
weston_surface_color_transform_ref even though it points to NULL
weston_color_transform.

This design is inspired by Sebastian Wick's Weston color management
work.

Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 12:53:41 +00:00