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>
4 years ago
|
|
|
/*
|
|
|
|
* Copyright 2021 Collabora, Ltd.
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
|
|
|
#include <libweston/libweston.h>
|
|
|
|
|
|
|
|
#include "color.h"
|
|
|
|
#include "shared/helpers.h"
|
|
|
|
|
|
|
|
struct weston_color_manager_noop {
|
|
|
|
struct weston_color_manager base;
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct weston_color_manager_noop *
|
|
|
|
get_cmnoop(struct weston_color_manager *cm_base)
|
|
|
|
{
|
|
|
|
return container_of(cm_base, struct weston_color_manager_noop, base);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
cmnoop_destroy_color_transform(struct weston_color_transform *xform)
|
|
|
|
{
|
|
|
|
/* Never called, as never creates an actual color transform. */
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
cmnoop_get_surface_color_transform(struct weston_color_manager *cm_base,
|
|
|
|
struct weston_surface *surface,
|
|
|
|
struct weston_output *output,
|
|
|
|
struct weston_surface_color_transform *surf_xform)
|
|
|
|
{
|
|
|
|
/* TODO: Assert surface has no colorspace set */
|
|
|
|
/* TODO: Assert output has no colorspace set */
|
|
|
|
|
|
|
|
/* Identity transform */
|
|
|
|
surf_xform->transform = NULL;
|
|
|
|
surf_xform->identity_pipeline = true;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
cmnoop_get_output_color_transform(struct weston_color_manager *cm_base,
|
|
|
|
struct weston_output *output,
|
|
|
|
struct weston_color_transform **xform_out)
|
|
|
|
{
|
|
|
|
/* TODO: Assert output has no colorspace set */
|
|
|
|
|
|
|
|
/* Identity transform */
|
|
|
|
*xform_out = NULL;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
cmnoop_get_sRGB_to_output_color_transform(struct weston_color_manager *cm_base,
|
|
|
|
struct weston_output *output,
|
|
|
|
struct weston_color_transform **xform_out)
|
|
|
|
{
|
|
|
|
/* TODO: Assert output has no colorspace set */
|
|
|
|
|
|
|
|
/* Identity transform */
|
|
|
|
*xform_out = NULL;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
cmnoop_get_sRGB_to_blend_color_transform(struct weston_color_manager *cm_base,
|
|
|
|
struct weston_output *output,
|
|
|
|
struct weston_color_transform **xform_out)
|
|
|
|
{
|
|
|
|
/* TODO: Assert output has no colorspace set */
|
|
|
|
|
|
|
|
/* Identity transform */
|
|
|
|
*xform_out = NULL;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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>
4 years ago
|
|
|
static bool
|
|
|
|
cmnoop_init(struct weston_color_manager *cm_base)
|
|
|
|
{
|
|
|
|
/* No renderer requirements to check. */
|
|
|
|
/* Nothing to initialize. */
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
cmnoop_destroy(struct weston_color_manager *cm_base)
|
|
|
|
{
|
|
|
|
struct weston_color_manager_noop *cmnoop = get_cmnoop(cm_base);
|
|
|
|
|
|
|
|
free(cmnoop);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct weston_color_manager *
|
|
|
|
weston_color_manager_noop_create(struct weston_compositor *compositor)
|
|
|
|
{
|
|
|
|
struct weston_color_manager_noop *cm;
|
|
|
|
|
|
|
|
cm = zalloc(sizeof *cm);
|
|
|
|
if (!cm)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
cm->base.name = "no-op";
|
|
|
|
cm->base.compositor = compositor;
|
|
|
|
cm->base.supports_client_protocol = false;
|
|
|
|
cm->base.init = cmnoop_init;
|
|
|
|
cm->base.destroy = cmnoop_destroy;
|
|
|
|
cm->base.destroy_color_transform = cmnoop_destroy_color_transform;
|
|
|
|
cm->base.get_surface_color_transform =
|
|
|
|
cmnoop_get_surface_color_transform;
|
|
|
|
cm->base.get_output_color_transform = cmnoop_get_output_color_transform;
|
|
|
|
cm->base.get_sRGB_to_output_color_transform =
|
|
|
|
cmnoop_get_sRGB_to_output_color_transform;
|
|
|
|
cm->base.get_sRGB_to_blend_color_transform =
|
|
|
|
cmnoop_get_sRGB_to_blend_color_transform;
|
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>
4 years ago
|
|
|
|
|
|
|
return &cm->base;
|
|
|
|
}
|