Based on KMS "Colorspace" connector property, populate the mask of
supported colorimetry modes on a head.
EDID should be checked too, but it is currently ignored.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
Refactor existing code into a helper, so when I introduce more bit mask
enums, I don't need to copy the whole function.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Until now, all the curves would be represented with 3x1D LUT's. Now we
support LINPOW and POWLIN curves (arbitrary names that we've picked).
We can use these curves to represent LittleCMS curves type 1, 4 and
their inverses -1, -4. The reason why we want that is because we gain
precision using the parametric curves (compared to the LUT's);
Surprisingly we had to increase the tolerance of the sRGB->adobeRGB MAT
test. Our analysis is that the inverse EOTF power-law curve with
exponent 1.0 / 2.2 amplifies errors more than the LUT, specially for
input (optical) values closer to zero.
That makes sense, because this curve is more sensible to input values
closer to zero (i.e. little input variation results in lots of output
variation). And this model makes sense, as humans are more capable of
perceiving changes of light intensity in the dark.
But the downside of all that is that for input values closer to zero, a
little bit of noise increases significantly the error.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Just like with color profiles, generate an ID for color transformations
as well. This is not needed by protocol or anything, it is just for
debugging purposes. A small ID is easier for humans than a long pointer
value.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is preparation for the CM&HDR protocol implementation. It requires
us to give a unique id to each color-profile, so let's do that.
In this commit we introduce a generic id generator to libweston, and
its first user: the color-profile.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Stop assuming that NULL represents the stock sRGB color profile. From
now on, query the stock sRGB color profile from the color manager.
This should be internal to libweston (core and the color plugins), and
users of the libweston public API should not be affected by this. They
are still allowed to set an output color profile to the stock sRGB using
NULL.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
It prints the existent color transformations for new subscribers. Also
prints any creation/destruction of color transformations.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Check whether HDR_OUTPUT_METADATA property exists on a KMS connector. If
yes, pretend that EDID claims support for all EOTF modes and update the
head supported EOTFs mask accordingly. If not, then only SDR is
possible.
Parsing EDID to take monitor capabilities into account is left for
later.
HDR mode cannot be set without HDR_OUTPUT_METADATA.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the switch to turn HDR mode on.
The values in the enumeration come straight from CTA-861-G standard.
Monitors advertise support for some of the HDR modes in their EDID, and
I am not aware of any other way to detect if a HDR mode actually works
or not. Different monitors may support different and multiple modes.
Different modes may look different. Therefore the high-level choice of
how to drive a HDR video sink is left for the Weston frontend to decide.
All the details like what HDR metadata to use are left for the color
manager.
This commit adds the libweston API for backends to advertise support and
for frontends to choose a mode. Backend and frontend implementations
follow in other commits.
The frontend API does not limit the EOTF mode to the supported ones to
allow experimentation and overriding EDID.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add API to set an output's color profile. This new function can also be
called while the output is enabled. This allows changing the output
color profile even at runtime if desired.
color-noop has no way of creating weston_color_profile objects, so it
just asserts that no color profile is set.
color-lcms does not yet implement taking the output color profile into
account, so for now it just fails everything if a profile is set.
weston_surface_color_transform_fini() was previously used only prior to
freeing the struct, but now it is used also to just clear the struct,
hence it needs to reset the fields.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This function will be useful for Weston to load output ICC profiles from
weston.ini.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
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>
Pekka Paalanen