When resizing the terminal, the row/columns would end up potentially too tall
and/or wide, meaning the widget would grow each time the window was configured
with a size.
Fix this by making sure the calculated rows and columns don't loose too much
precision, and if they do, shrink instead of grow, as that is expected by the
xdg_toplevel configure event.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Assume axis alignment using node's valid_transform boolean instead of
relying on the transform flags of the weston_view struct. This is more
reliable since matrix flags could erroneously hang around after a
series of transforms. Additionally, nodes with standard output
transforms like translations, flips and rotations by 90° can now take
the fast axis aligned path.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Add signal handler for SIGINT to enable graceful exit and
release allocated memory. This resolves the memory leak
observed with Valgrind:
LEAK SUMMARY:
definitely lost: 2,520 bytes in 2 blocks
indirectly lost: 16,820 bytes in 11 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 0 bytes in 0 blocks
suppressed: 0 bytes in 0 blocks
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/872
Signed-off-by: Chirag Khurana <quic_ckhurana@quicinc.com>
This changes the callback frame list insertion after paint node late
update takes place in order for to the visibily region to be modified.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When we lift planes entirely out of the scene graph, paint node visibility
calculations become "per plane". This means that when we lift something
onto a paint node, anything beneath it will be redrawn in response to
client side damage even if the lower surfaces are occluded.
Instead, keep the scene graph together and make the paint node visible
regions be their visibility within the global scene graph.
This has the side effect of plane motion causing redraws, to update
regions they've been obscuring. My assumption is that moving planes
is less frequent than damage being posted beneath an overlay, and
that we'll be more efficient for normal use cases this way.
An optimization is in place to prevent redraws when moving transparent
planes, as they haven't been occluding updates.
In addition to theoretically removing some wasteful rendering time, this
also simplifies damage accumulation.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
When a client is killed we don't get a clean dismissal of pop-ups in
construction order. This can lead to a weston_desktop_surface being
destroyed before its child popup is destroyed.
The weston_surface is still alive, so the surface destroy listener can't
save us.
Track grabbed seats in parent surfaces and explicitly break any grabs
that depend on them when the surfaces are destroyed.
Fixes#870
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Effective from Linux 6.3 onward, this creates the memfd without execute
permissions and prevents that setting from ever being changed. A
run-time fallback is made to not using MFD_NOEXEC_SEAL when
weston compiled on Linux >= 6.3 is run on Linux < 6.3.
Signed-off-by: Sami Uddin <sami.uddin@astc-design.com>
We've forgotten to set this up in some backends, so let's just do it in
weston_compositor_init_renderer().
The headless backend used to fail out if linux_dmabuf_setup() failed, but
had no reason to do so, so just remove that to make the code common.
Suggested by cwabbott on irc.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Essentially ensures that wet_output_set_eotf_mode() and
wet_output_set_colorimetry_mode() work as intended.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
Marius Vlad