The headless backend does not display to anything, so it doesn't care
what the colorimetry mode is. To allow testing compositor internal
behavior, claim to support all colorimetry modes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This output section key is used to program the KMS connector property
"Colorspace" when used with the DRM-backend.
This is an essential part in defining the color encoding used in the
video signal, and may allow wide color gamut even on SDR.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
It would be painful to mock a struct wet_compositor in the tests, so
pass that one boolean as an explicit argument instead.
This makes it easier to extend the testing of the function.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Based on what is configured in weston_output, check and set the
colorimetry mode into KMS connector property "Colorspace".
This changes how video sinks interpret the pixels, and should allow
driving e.g. WCG monitors in BT.2020 mode.
This does not alter the pixel values themselves. That is the color
manager responsibility, and ultimately the responsibility of the
frontend and the end user to match the monitor driving mode with the
output color profile they chose.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
Helper to assert that a value does not have any bit set outside of the
mask. To be used with "all bits mask" of enum types that enumerate bits.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Currently EOTF mode is not validated against the supported mask, to
allow easier experimenting without supplying a modified EDID through the
kernel.
The validation should be added before color management becomes
non-experimental.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This will allow me to use this header in libweston core to build a
single translation table between core enums, string names, and wdrm
enums.
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>
Turns out these structures do not need to be in the public header, so
move them into a private header.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
No need to use both renderer for the tests, PIXMAN one is enough.
For the kiosk-shell test which was recently added, but also for the
older paint-node test.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
If png_create_info_struct() fails, we should pass NULL to
png_destroy_read_struct(), and not the address of the info we just
failed to create.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the next commits we'll add support to extract the ICC information
from the images and use the CM&HDR protocol extension to present them
with the ICC data.
Currently the decorations, background and the image content are
presented on the same surface. As we want to apply the ICC only on the
image content, move it to a subsurface.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Cosmetic change. Instead of accessing image->frame_widget on the widget
handlers, use the parameter widget.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the next commits we'll add another widget to the code, so rename this
one to frame_widget.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This patch is for our CM&HDR protocol extension test.
According to the protocol, the compositor may take the time it needs
before sending 'ready' or 'failed' for a certain image description that
the client creates through the CM&HDR protocol extension.
In our CM&HDR tests, we are assuming that the image description would
be ready immediately. Do not assume that. Instead, let's wait until
the compositor sends one of the events ('failed' or 'ready').
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This patch is for our CM&HDR protocol extension implementation.
When a client requests to create an image description, it can only start
using that after receiving the 'ready' event. The compositor may take
the time it needs to create the backing color profile for such image
description. But nothing guarantees that clients will do the right
thing.
This fixes some issues for not well behaved clients and also documents
how we handle image description that are not ready.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This patch is for our CM&HDR protocol extension implementation.
When we gracefully fail to create an image description, we send the
'failed' event and the client can only destroy such image description.
But nothing guarantees that clients will do the right thing.
This fixes some issues for not well behaved clients and also documents
how we handle image description whose creation gracefully failed
internally.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There's a comment with a TODO that would be super simple to implement,
but we preferred to wait at the moment. But there are discussions on the
upstream CM&HDR protocol MR that would change that. This patch documents
that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
It doesn't make sense to stack the plane before it's useful - so only
put it in the compositor's plane list on output_enable. The opposite of
weston_output_enable is weston_compositor_remove_output, so release the
plane there.
This stops a crash when closing one of multiple windows for a nested
backend results in the output being freed while the plane is still on the
compositor's plane list.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Previously we assigned any paint node to the primary_plane of the output
it was on and marked it dirty.
This doesn't make sense if we're releasing the primary_plane.
Let's just delete the paint nodes and force a view list rebuild, which
will recreate them appropriately.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This should produce the best results on average for all kinds of apps on
any kind of display.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The ICC profiles created for tests here are supposed to produce the same
results regardless of whether they are of the matrix-shaper or cLUT
form, and whether the compositor uses a colorimetric or perceptual
rendering intent. This is silly, but it fits our tests very well since
we mostly want to ensure correct computations in matrix and cLUT code
rather than meaningful results from different rendering intents.
When trying to switch the compositor from colorimetric to perceptual
rendering intent as required by the color-management protocol extension,
all and only the cLUT based tests failed (color-icc-output test).
The reason is that ICCv4 defines the perceptual PCS having a specific
non-zero black point. It requires ICC profiles to convert device black
to the PCS black and vice versa. However, matrix-shaper type ICC
profiles have no way to provide a perceptual transformation to/from PCS
separate from the colorimetric transformation. Hence, LittleCMS exempts
ICCv4 matrix-shaper profiles from the ICCv4 perceptual PCS definition.
Black point compensation (BPC) is always added by LittleCMS with the
perceptual rendering intent. If an ICC profile claims to be ICC version
4, the perceptual transformation in it is assumed to adhere to the
percptual PCS black point, which is non-zero. Hence, DToB0 and BToD0
tags need to respect that so that BPC works correctly.
Before this patch, DToB0 and BToD0 transformations did not use the
correct PCS black point, so when BPC got added, the color space
conversion went wrong. This patch replicates the BPC algorithm that
LittleCMS uses in order to respect the perceptual PCS definition. This
will then cancel out with the BPC added by LittleCMS, producing the
expected color space conversion.
The problem arises only with cLUT ICC profiles because matrix-shaper
profiles are exempt: the black points between source (always
matrix-shaper sRGB profile for now) and destination color spaces match,
and no BPC is added by LittleCMS.
There is no way to ask LittleCMS to add its BPC on our will, so we need
to copy that code from LittleCMS 2.16.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The primaries and the white point are the fundamental definition of the
color spaces in these tests. Instead of hard-coding mat2XYZ, use
LittleCMS to derive the result from the fundamental definition.
This removes derived hard-coded constants, which is a benefit in itself.
How these constants were originally produced was not mentioned in
0c5860fafb but I was able to reproduce
them with python3:
import colour
import numpy as np
x = colour.RGB_COLOURSPACES['sRGB']
w_d50 = np.array([0.34567, 0.35850])
print(x.chromatically_adapt(w_d50, 'D50', 'Bradford'))
It's identical to 3-4 decimals of the hardcoded values, and also for
Adobe RGB. I printed the LittleCMS generated values as well, and they
are the same as with python up to roughly 4 decimals.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is pure refactoring.
Ease readability by reducing code duplication between pre and post curve
powlin handling.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is pure refactoring.
Ease readability by reducing code duplication between pre and post curve
linpow handling.
While at it, define symbols for the counts. This patch converts only
linpow. Powlin are converted in follow-up.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is pure refactoring.
Ease readability by reducing code duplication between pre and post curve
LUT handling.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Build failed on the latest glibc (I think?), which caused this weird error:
/usr/include/bits/fcntl2.h:50:11: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT or O_TMPFILE in second argument needs 3 arguments
In these three calls, open() was being called with 'r' flag, whose hex value is
0x72, and happens to set the O_CREAT flag (0x40) which was causing this error.
The correct flag to pass is O_RDONLY.
This issue exists since the creation of that file, I’m surprised it was working
previously.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
gst_parse_launch can return non-NULL even though an error is set. This
indicates "a recoverable parsing error and you can try to play the
pipeline", however given that we don't (and likely can't) make any
attempt to correct the situation, we should treat this as fatal and not
try to carry on.
Signed-off-by: Ray Smith <rsmith@brightsign.biz>
We're currently calling ppoll() before calling xcb_wait_for_event(), which
may be due to initially trying to make this non-blocking.
However, xcb_wait_for_event() reads all events available - even if there
are more than one.
There are a handful of X properties we're sent that we don't explicitly
ask for, and if these end up in the same read, we could theoretically
end up in a poll() with nothing coming in.
Drop the extra ppoll() and just let xcb_wait_for_event() do the blocking
for us.
I'm hoping this fixes the occasional timeout in the xwayland test, but
it's a reasonable code simplification even if it doesn't.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This prevents a potential crash where users of
weston_layer_entry_insert/layer_entry_remove() would see when moving
views into a NULL layer (effectively unmapping the surface/view).
Users that have migrated to the weston_view_move_to_layer() are immune
to this issue because that takes care of paint node destruction.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When reading back for the remote backends we need to convert the extents
of the damage (which is in global coordinates) to output coordinates
to read back the correct region.
We were doing this in a bespoke fashion by adding the output coordinates.
Instead, use weston_matrix_transform_rect() to transform the extents by
the output transform - which includes the scale factor.
This fixes output scale on RDP with the gl renderer.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Without this fix, we have randomly been getting CI failures due to
LeakSanitizer itself crashing after all the tests in a program have
succeeded. This has been happening randomly for a long time, but
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1486
made it very reliably repeatable in the job x86_64-debian-full-build
(and no other job) in the test-subsurface-shot program.
--- Fixture 2 (GL) ok: passed 4, skipped 0, failed 0, total 4
Tracer caught signal 11: addr=0x1b8 pc=0x7f6b3ba640f0 sp=0x7f6b2cc77d10
==489==LeakSanitizer has encountered a fatal error.
I was also able to get a core file after twiddling, but there it ended
up with lsan aborting itself rather than a segfault.
We got some clues that use_tls=0 might work around this, from
https://github.com/google/sanitizers/issues/1342https://github.com/google/sanitizers/issues/1409
and some other projects that have cargo-culted the same workaround.
Using that cause more false leaks to appear, so they need to be
suppressed. I suppose we are not interested in catching leaks in glib
using code, so I opted to suppress g_malloc0 altogether. Pinpointing it
better might have required much more slower stack tracing.
wl_shm_buffer_begin_access() uses TLS, so no wonder it gets flagged.
ld-*.so is simply uninteresting to us, and it got flagged too.
Since this might have been fixed already in LeakSanitizer upstream, who
knows, leave some notes to revisit this when we upgrade that in CI.
This fix seems to make the branch of
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1486
in my quick testing.
Suggested-by: Derek Foreman <derek.foreman@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
On commit "color: add support to parametric curves in
weston_color_curve" we've added support for some parametric curves in
Weston. This helped us to be more precise in some cases in which we'd
have to fallback to LUT's otherwise.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@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>
In the next commit we'll add support for more color curves. So move
lut_3x1d to an union.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Given a certain curveset, get_parametric_curveset_params() returns true
if the curveset contains parametric curves. Also, it returns the
parameters of the curveset (for each curve) and if the input should be
clamped or not.
This is not a generic function, it will specifically work for some well
behaved curveset. E.g. we return false if there are more than 3 curves
(one per color channel).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Currently in translate_curve_element() we always translate the curve
into a LUT. But in the future we'll be able to translate the curves to
parametric ones.
So move the current code to a new function
translate_curve_element_LUT(), so that in translate_curve_element() we
are able to call one of the two functions (_LUT() or _parametric()).
No behavior changes, just preparation for the upcoming patches.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Not a behavior change, but this allow us to decide what function pointer
to use within this function (instead of forcing callers to decide that).
In the following commits this will be helpful. We'll add more curves
besides 3x1D LUT's and, depending on the curve, the function pointer
signature may differ.
Also, we now pass the xform directly to the function, and it can select
the curves depending if it is being called for a pre or a post curve.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
When we don't have cmsGetToneCurveSegment() at disposal, we are not able
to inspect the LittleCMS color curves and convert them to Weston's
internal representation of color curves. In such case, we need to
fallback to a more generic solution (using LUT's).
For now we always fallback to the LUT's, but in the next commits we'll
add support to inspect the curves and convert them to the internal
representations that we'll add.
This will allow us to tweak the tolerance in the color-icc-output tests.
But if we continue running these tests for systems without
cmsGetToneCurveSegment() at disposal, they may fail.
We already have a LittleCMS version in the CI that has
cmsGetToneCurveSegment(). So skip color-icc-output when we don't have
this function.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Pekka Paalanen