weston/libweston/color.h

643 lines
20 KiB
C
Raw Permalink Normal View History

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-02-25 13:03:28 +03:00
/*
* Copyright 2021 Collabora, Ltd.
* Copyright 2021 Advanced Micro Devices, Inc.
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-02-25 13:03:28 +03:00
*
* Permission is hereby granted, free of charge, to any person obtaining
* a copy of this software and associated documentation files (the
* "Software"), to deal in the Software without restriction, including
* without limitation the rights to use, copy, modify, merge, publish,
* distribute, sublicense, and/or sell copies of the Software, and to
* permit persons to whom the Software is furnished to do so, subject to
* the following conditions:
*
* The above copyright notice and this permission notice (including the
* next paragraph) shall be included in all copies or substantial
* portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
#ifndef WESTON_COLOR_H
#define WESTON_COLOR_H
#include <stdbool.h>
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-05-28 14:46:14 +03:00
#include <stdint.h>
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-02-25 13:03:28 +03:00
#include <libweston/libweston.h>
libweston: add colorimetry_mode API This API is mostly for use by the DRM-backend. Colorimetry mode is is the KMS connector property "Colorspace" which defines the video signal encoding colorimetry. A video sink indicates the supported modes in EDID or DisplayID. This patch adds the libweston API that allows backends to indicate the supported modes for the frontends, and frontends to set the mode to be used by backends. Colorimetry mode does not directly affect color management inside Weston, it is only metadata for the video sink. It is the frontend's responsibility to set up an output color profile that agrees with the colorimetry mode. (That API has not been implemented yet.) eotf_mode will be the same. There is only one reason to make this a libweston core API instead of a backend-drm API: when wayland-backend gains color-management protocol support, meaning it can forward WCG and HDR content correctly to a host compositor, the supported colorimetry modes can be determined from the host compositor's supported color-management features, allowing the guest Weston to pick some other output image description than the host compositor's preferred image description. This likely allows only a few other choices from standard colorspaces, so it's possible this isn't sufficient for that use case. Either way, it is easy to just copy the eotf_mode API design, and since colorimetry_mode and eotf_mode go together, let both have the same API design. It is possible to convert this to backend-drm API later. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2023-09-01 14:50:20 +03:00
#include "backend-drm/drm-kms-enums.h"
enum weston_hdr_metadata_type1_groups {
/** weston_hdr_metadata_type1::primary is set */
WESTON_HDR_METADATA_TYPE1_GROUP_PRIMARIES = 0x01,
/** weston_hdr_metadata_type1::white is set */
WESTON_HDR_METADATA_TYPE1_GROUP_WHITE = 0x02,
/** weston_hdr_metadata_type1::maxDML is set */
WESTON_HDR_METADATA_TYPE1_GROUP_MAXDML = 0x04,
/** weston_hdr_metadata_type1::minDML is set */
WESTON_HDR_METADATA_TYPE1_GROUP_MINDML = 0x08,
/** weston_hdr_metadata_type1::maxCLL is set */
WESTON_HDR_METADATA_TYPE1_GROUP_MAXCLL = 0x10,
/** weston_hdr_metadata_type1::maxFALL is set */
WESTON_HDR_METADATA_TYPE1_GROUP_MAXFALL = 0x20,
/** all valid bits */
WESTON_HDR_METADATA_TYPE1_GROUP_ALL_MASK = 0x3f
};
/** HDR static metadata type 1
*
* The fields are defined by CTA-861-G except here they use float encoding.
*
* In Weston used only with HDR display modes.
*/
struct weston_hdr_metadata_type1 {
/** Which fields are valid
*
* A bitmask of values from enum weston_hdr_metadata_type1_groups.
*/
uint32_t group_mask;
/* EOTF is tracked externally with enum weston_eotf_mode */
/** Chromaticities of the primaries, in any order */
struct weston_CIExy primary[3];
/** White point chromaticity */
struct weston_CIExy white;
/** Maximum display mastering luminance, 1 - 65535 cd/m² */
float maxDML;
/** Minimum display mastering luminance, 0.0001 - 6.5535 cd/m² */
float minDML;
/** Maximum content light level, 1 - 65535 cd/m² */
float maxCLL;
/** Maximum frame-average light level, 1 - 65535 cd/m² */
float maxFALL;
};
/** Output properties derived from its color characteristics and profile
*
* These are constructed by a color manager.
*
* A weston_output_color_outcome owns (a reference to) everything it contains.
*
* \ingroup output
* \internal
*/
struct weston_output_color_outcome {
/** sRGB to output color space transformation */
struct weston_color_transform *from_sRGB_to_output;
/** sRGB to blending color space transformation */
struct weston_color_transform *from_sRGB_to_blend;
/** Blending to output color space transformation */
struct weston_color_transform *from_blend_to_output;
/** HDR Static Metadata Type 1 for WESTON_EOTF_MODE_ST2084 */
struct weston_hdr_metadata_type1 hdr_meta;
};
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-05-28 14:46:14 +03:00
/**
* Represents a color profile description (an ICC color profile)
*
* Sub-classed by the color manager that created this.
*/
struct weston_color_profile {
struct weston_color_manager *cm;
int ref_count;
char *description;
/* Unique id to be used by the CM&HDR protocol extension. */
uint32_t id;
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-05-28 14:46:14 +03:00
};
/** Parameters that define a parametric color profile */
struct weston_color_profile_params {
/* Primary color volume; always set. */
struct weston_color_gamut primaries;
/* Primary color volume by enumeration; optional, may be NULL. */
const struct weston_color_primaries_info *primaries_info;
/* Encoding transfer characteristic by enumeration; always set. */
const struct weston_color_tf_info *tf_info;
/* Transfer characteristic's parameters; depends on tf_info. */
float tf_params[10];
/* Target color volume; always set. */
struct weston_color_gamut target_primaries;
/* Luminance parameters cd/m²; negative when not set */
float min_luminance, max_luminance;
float maxCLL;
float maxFALL;
};
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-02-25 13:03:28 +03:00
/** Type or formula for a curve */
enum weston_color_curve_type {
/** Identity function, no-op */
WESTON_COLOR_CURVE_TYPE_IDENTITY = 0,
/** Three-channel, one-dimensional look-up table */
WESTON_COLOR_CURVE_TYPE_LUT_3x1D,
/** Transfer function named LINPOW
*
* y = (a * x + b) ^ g | x >= d
* y = c * x | 0 <= x < d
*
* We gave it the name LINPOW because the first operation with the input
* x is a linear one, and then the result is raised to g.
*
* As all parametric curves, this one should be represented using struct
* weston_color_curve_parametric. For each color channel RGB we may have
* different params, see weston_color_curve_parametric::params.
*
* For LINPOW, the params g, a, b, c, and d are respectively
* params[channel][0], ... , params[channel][4].
*
* The input for all color channels may be clamped to [0.0, 1.0]. In
* such case, weston_color_curve_parametric::clamped_input is true.
* If the input is not clamped and LINPOW needs to evaluate a negative
* input value, it uses mirroring (i.e. -f(-x)).
*/
WESTON_COLOR_CURVE_TYPE_LINPOW,
/** Transfer function named POWLIN
*
* y = (a * (x ^ g)) + b | x >= d
* y = c * x | 0 <= x < d
*
* We gave it the name POWLIN because the first operation with the input
* x is an exponential one, and then the result is multiplied by a.
*
* As all parametric curves, this one should be represented using struct
* weston_color_curve_parametric. For each color channel RGB we may have
* different params, see weston_color_curve_parametric::params.
*
* For POWLIN, the params g, a, b, c, and d are respectively
* params[channel][0], ... , params[channel][4].
*
* The input for all color channels may be clamped to [0.0, 1.0]. In
* such case, weston_color_curve_parametric::clamped_input is true.
* If the input is not clamped and POWLIN needs to evaluate a negative
* input value, it uses mirroring (i.e. -f(-x)).
*/
WESTON_COLOR_CURVE_TYPE_POWLIN,
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-02-25 13:03:28 +03:00
};
/** LUT_3x1D parameters */
struct weston_color_curve_lut_3x1d {
/**
* Approximate a color curve with three 1D LUTs
*
* A 1D LUT is a mapping from [0.0, 1.0] to arbitrary values. The first
* element in the LUT corresponds to input value 0.0, and the last
* element corresponds to input value 1.0. The step from one element
* to the next in input space is 1.0 / (len - 1). When input value is
* between two elements, linear interpolation should be used.
*
* This function fills in the given array with the LUT values.
*
* \param xform This color transformation object.
* \param len The number of elements in each 1D LUT.
* \param values Array of 3 x len elements. First R channel
* LUT, immediately followed by G channel LUT, and then B channel LUT.
*/
void
(*fill_in)(struct weston_color_transform *xform,
float *values, unsigned len);
/** Optimal 1D LUT length for storage vs. precision */
unsigned optimal_len;
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-02-25 13:03:28 +03:00
};
/** Parametric color curve parameters */
struct weston_color_curve_parametric {
/* For each color channel we may have different curves. For each of
* them, we can have up to 10 params, depending on the curve type. The
* channels are in RGB order. */
float params[3][10];
/* The input of the curve should be clamped from 0.0 to 1.0? */
bool clamped_input;
};
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-02-25 13:03:28 +03:00
/**
* A scalar function for color encoding and decoding
*
* This object can represent a one-dimensional function that is applied
* independently to each of the color channels. Depending on the type and
* parameterization of the curve, all color channels may use the
* same function or each may have separate parameters.
*
* This is usually used for EOTF or EOTF^-1 and to optimize a 3D LUT size
* without sacrificing precision, both in one step.
*/
struct weston_color_curve {
/** Which member of 'u' defines the curve. */
enum weston_color_curve_type type;
/** Parameters for the curve. */
union {
/* identity: no parameters */
struct weston_color_curve_lut_3x1d lut_3x1d;
struct weston_color_curve_parametric parametric;
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-02-25 13:03:28 +03:00
} u;
};
/** Type or formula for a color mapping */
enum weston_color_mapping_type {
/** Identity function, no-op */
WESTON_COLOR_MAPPING_TYPE_IDENTITY = 0,
/** 3D-dimensional look-up table */
WESTON_COLOR_MAPPING_TYPE_3D_LUT,
/** matrix */
WESTON_COLOR_MAPPING_TYPE_MATRIX,
};
/**
* A three-dimensional look-up table
*
* A 3D LUT is a three-dimensional array where each element is an RGB triplet.
* A 3D LUT is usually an approximation of some arbitrary color mapping
* function that cannot be represented in any simpler form. The array contains
* samples from the approximated function, and values between samples are
* estimated by interpolation. The array is accessed with three indices, one
* for each input dimension (color channel).
*
* Color channel values in the range [0.0, 1.0] are mapped linearly to
* 3D LUT indices such that 0.0 maps exactly to the first element and 1.0 maps
* exactly to the last element in each dimension.
*
* This object represents a 3D LUT and offers an interface for realizing it
* as a data array with a custom size.
*/
struct weston_color_mapping_3dlut {
/**
* Create a 3D LUT data array
*
* \param xform This color transformation object.
* \param values Memory to hold the resulting data array.
* \param len The number of elements in each dimension.
*
* The array \c values must be at least 3 * len * len * len elements
* in size.
*
* Given the red index ri, green index gi and blue index bi, the
* corresponding array element index
*
* i = 3 * (len * len * bi + len * gi + ri) + c
*
* where
*
* c = 0 for red output value,
* c = 1 for green output value, and
* c = 2 for blue output value
*/
void
(*fill_in)(struct weston_color_transform *xform,
float *values, unsigned len);
/** Optimal 3D LUT size along each dimension */
unsigned optimal_len;
};
/**
* A 3x3 matrix and data is arranged as column major
*/
struct weston_color_mapping_matrix {
float matrix[9];
};
/**
* Color mapping function
*
* This object can represent a 3D LUT to do a color space conversion
*
*/
struct weston_color_mapping {
/** Which member of 'u' defines the color mapping type */
enum weston_color_mapping_type type;
/** Parameters for the color mapping function */
union {
/* identity: no parameters */
struct weston_color_mapping_3dlut lut3d;
struct weston_color_mapping_matrix mat;
} u;
};
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-02-25 13:03:28 +03:00
/**
* Describes a color transformation formula
*
* Guaranteed unique, de-duplicated.
*
* Sub-classed by the color manager that created this.
*
* For a renderer to support WESTON_CAP_COLOR_OPS it must implement everything
* that this structure can represent.
*/
struct weston_color_transform {
struct weston_color_manager *cm;
int ref_count;
uint32_t id; /* For debug */
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-02-25 13:03:28 +03:00
/* for renderer or backend to attach their own cached objects */
struct wl_signal destroy_signal;
/* Color transform is the series of steps: */
/** Step 1: color model change */
/* YCbCr→RGB conversion, but that is done elsewhere */
/** Step 2: color curve before color mapping */
struct weston_color_curve pre_curve;
/** Step 3: color mapping */
struct weston_color_mapping mapping;
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-02-25 13:03:28 +03:00
/** Step 4: color curve after color mapping */
struct weston_color_curve post_curve;
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-02-25 13:03:28 +03:00
};
/**
* How content color needs to be transformed
*
* This object is specific to the color properties of the weston_surface and
* weston_output it was created for. It is automatically destroyed if any
* relevant color properties change.
*
* Fundamentally this contains the color transformation from content color
* space to an output's blending color space. This is stored in field
* 'transform' with NULL value corresponding to identity transformation.
*
* For graphics pipeline optimization purposes, the field 'identity_pipeline'
* indicates whether the combination of 'transform' here and the output's
* blending color space to monitor color space transformation total to
* identity transformation. This helps detecting cases where renderer bypass
* (direct scanout) is possible.
*/
struct weston_surface_color_transform {
/** Transformation from source to blending space */
struct weston_color_transform *transform;
/** True, if source colorspace is identical to monitor color space */
bool identity_pipeline;
};
struct cm_image_desc_info;
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-02-25 13:03:28 +03:00
struct weston_color_manager {
/** Identifies this CMS component */
const char *name;
/** This compositor instance */
struct weston_compositor *compositor;
/** Supports the Wayland CM&HDR protocol extension? */
bool supports_client_protocol;
/**
* Supported color features from Wayland CM&HDR protocol extension.
*
* If v (v being enum weston_color_feature v) is a supported color
* feature, the bit v of this will be set to 1.
*/
uint32_t supported_color_features;
/**
* Supported rendering intents from Wayland CM&HDR protocol extension.
*
* If v (v being enum weston_render_intent v) is a supported rendering
* intent, the bit v of this will be set to 1.
*/
uint32_t supported_rendering_intents;
/**
* Supported primaries named from Wayland CM&HDR protocol extension.
*
* If v (v being enum weston_color_primaries v) is a supported
* primaries named, the bit v of this will be set to 1.
*/
uint32_t supported_primaries_named;
/**
* Supported tf named from Wayland CM&HDR protocol extension.
*
* If v (v being enum weston_transfer_function v) is a supported
* tf named, the bit v of this will be set to 1.
*/
uint32_t supported_tf_named;
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-02-25 13:03:28 +03:00
/** Initialize color manager */
bool
(*init)(struct weston_color_manager *cm);
/** Destroy color manager */
void
(*destroy)(struct weston_color_manager *cm);
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-05-28 14:46:14 +03:00
/** Destroy a color profile after refcount fell to zero */
void
(*destroy_color_profile)(struct weston_color_profile *cprof);
/** Gets a new reference to the stock sRGB color profile
*
* \param cm The color manager.
* \return A new reference to the stock sRGB profile, never returns NULL.
*/
struct weston_color_profile *
(*ref_stock_sRGB_color_profile)(struct weston_color_manager *cm);
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-05-28 14:46:14 +03:00
/** Create a color profile from ICC data
*
* \param cm The color manager.
* \param icc_data Pointer to the ICC binary data.
* \param icc_len Length of the ICC data in bytes.
* \param name_part A string to be used in describing the profile.
* \param cprof_out On success, the created object is returned here.
* On failure, untouched.
* \param errmsg On success, untouched. On failure, a pointer to a
* string describing the error is stored here. The string must be
* free()'d.
* \return True on success, false on failure.
*
* This may return a new reference to an existing color profile if
* that profile is identical to the one that would be created, apart
* from name_part.
*/
bool
(*get_color_profile_from_icc)(struct weston_color_manager *cm,
const void *icc_data,
size_t icc_len,
const char *name_part,
struct weston_color_profile **cprof_out,
char **errmsg);
/** Create a color profile from parameters
*
* \param cm The color manager.
* \param params The struct weston_color_profile_params with the params.
* \param name_part A string to be used in describing the profile.
* \param cprof_out On success, the created object is returned here.
* On failure, untouched.
* \param errmsg On success, untouched. On failure, a pointer to a
* string describing the error is stored here. The string must be
* free()'d.
* \return True on success, false on failure.
*
* This may return a new reference to an existing color profile if
* that profile is identical to the one that would be created, apart
* from name_part.
*/
bool
(*get_color_profile_from_params)(struct weston_color_manager *cm,
const struct weston_color_profile_params *params,
const char *name_part,
struct weston_color_profile **cprof_out,
char **errmsg);
/** Send image description to clients.
*
* \param cm_image_desc_info The image description info object
* \param cprof_base The color profile that backs the image description
* \return True on success, false on failure
*
* This should be used only by the CM&HDR protocol extension
* implementation.
*
* The color manager implementing this function should use the helpers
* from color-management.c (weston_cm_send_primaries(), etc) to send the
* information to clients.
*/
bool
(*send_image_desc_info)(struct cm_image_desc_info *cm_image_desc_info,
struct weston_color_profile *cprof_base);
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-02-25 13:03:28 +03:00
/** Destroy a color transform after refcount fell to zero */
void
(*destroy_color_transform)(struct weston_color_transform *xform);
/** Get surface to output's blending space transformation
*
* \param cm The color manager.
* \param surface The surface for the source color space.
* \param output The output for the destination blending color space.
* \param surf_xform For storing the color transformation and
* additional information.
*
* The callee is responsible for increasing the reference count on the
* weston_color_transform it stores into surf_xform.
*/
bool
(*get_surface_color_transform)(struct weston_color_manager *cm,
struct weston_surface *surface,
struct weston_output *output,
struct weston_surface_color_transform *surf_xform);
/** Compute derived color properties for an output
*
* \param cm The color manager.
* \param output The output.
* \return A new color_outcome object on success, NULL on failure.
*
* The callee (color manager) must inspect the weston_output (color
* profile, EOTF mode, etc.) and create a fully populated
* weston_output_color_outcome object.
*/
struct weston_output_color_outcome *
(*create_output_color_outcome)(struct weston_color_manager *cm,
struct weston_output *output);
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-02-25 13:03:28 +03:00
};
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-05-28 14:46:14 +03:00
void
weston_color_profile_init(struct weston_color_profile *cprof,
struct weston_color_manager *cm);
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-02-25 13:03:28 +03:00
struct weston_color_transform *
weston_color_transform_ref(struct weston_color_transform *xform);
void
weston_color_transform_unref(struct weston_color_transform *xform);
void
weston_color_transform_init(struct weston_color_transform *xform,
struct weston_color_manager *cm);
char *
weston_color_transform_string(const struct weston_color_transform *xform);
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-02-25 13:03:28 +03:00
void
weston_surface_color_transform_copy(struct weston_surface_color_transform *dst,
const struct weston_surface_color_transform *src);
void
weston_surface_color_transform_fini(struct weston_surface_color_transform *surf_xform);
struct weston_paint_node;
void
weston_paint_node_ensure_color_transform(struct weston_paint_node *pnode);
struct weston_color_manager *
weston_color_manager_noop_create(struct weston_compositor *compositor);
/* DSO module entrypoint */
struct weston_color_manager *
weston_color_manager_create(struct weston_compositor *compositor);
const char *
weston_eotf_mode_to_str(enum weston_eotf_mode e);
char *
weston_eotf_mask_to_str(uint32_t eotf_mask);
libweston: add colorimetry_mode API This API is mostly for use by the DRM-backend. Colorimetry mode is is the KMS connector property "Colorspace" which defines the video signal encoding colorimetry. A video sink indicates the supported modes in EDID or DisplayID. This patch adds the libweston API that allows backends to indicate the supported modes for the frontends, and frontends to set the mode to be used by backends. Colorimetry mode does not directly affect color management inside Weston, it is only metadata for the video sink. It is the frontend's responsibility to set up an output color profile that agrees with the colorimetry mode. (That API has not been implemented yet.) eotf_mode will be the same. There is only one reason to make this a libweston core API instead of a backend-drm API: when wayland-backend gains color-management protocol support, meaning it can forward WCG and HDR content correctly to a host compositor, the supported colorimetry modes can be determined from the host compositor's supported color-management features, allowing the guest Weston to pick some other output image description than the host compositor's preferred image description. This likely allows only a few other choices from standard colorspaces, so it's possible this isn't sufficient for that use case. Either way, it is easy to just copy the eotf_mode API design, and since colorimetry_mode and eotf_mode go together, let both have the same API design. It is possible to convert this to backend-drm API later. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2023-09-01 14:50:20 +03:00
struct weston_colorimetry_mode_info {
/** Primary key: the colorimetry mode */
enum weston_colorimetry_mode mode;
/** Its name as a string for logging. */
const char *name;
/** wdrm equivalent, or WDRM_COLORSPACE__COUNT if none */
enum wdrm_colorspace wdrm;
};
const struct weston_colorimetry_mode_info *
weston_colorimetry_mode_info_get(enum weston_colorimetry_mode c);
const struct weston_colorimetry_mode_info *
weston_colorimetry_mode_info_get_by_wdrm(enum wdrm_colorspace cs);
libweston: add colorimetry_mode API This API is mostly for use by the DRM-backend. Colorimetry mode is is the KMS connector property "Colorspace" which defines the video signal encoding colorimetry. A video sink indicates the supported modes in EDID or DisplayID. This patch adds the libweston API that allows backends to indicate the supported modes for the frontends, and frontends to set the mode to be used by backends. Colorimetry mode does not directly affect color management inside Weston, it is only metadata for the video sink. It is the frontend's responsibility to set up an output color profile that agrees with the colorimetry mode. (That API has not been implemented yet.) eotf_mode will be the same. There is only one reason to make this a libweston core API instead of a backend-drm API: when wayland-backend gains color-management protocol support, meaning it can forward WCG and HDR content correctly to a host compositor, the supported colorimetry modes can be determined from the host compositor's supported color-management features, allowing the guest Weston to pick some other output image description than the host compositor's preferred image description. This likely allows only a few other choices from standard colorspaces, so it's possible this isn't sufficient for that use case. Either way, it is easy to just copy the eotf_mode API design, and since colorimetry_mode and eotf_mode go together, let both have the same API design. It is possible to convert this to backend-drm API later. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2023-09-01 14:50:20 +03:00
const char *
weston_colorimetry_mode_to_str(enum weston_colorimetry_mode c);
char *
weston_colorimetry_mask_to_str(uint32_t colorimetry_mask);
void
weston_output_color_outcome_destroy(struct weston_output_color_outcome **pco);
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-02-25 13:03:28 +03:00
#endif /* WESTON_COLOR_H */