This was discussed in wayland-protocols MR 273, and clarified in wayland
MR 379 - presentation feedback applies to content updates, not buffers.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This ensures (an unlikely) cases where get_label might be called and the
callback itself would makes use committted_private to retrieve callback
data. Just make sure to set it prior.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Originally the test-asserts were abort()'ing. Then they were changed to
record the failure but not abort() anymore. These loops were missed,
accidentally turning them into endless loops on Wayland connection
failure, e.g. a protocol error.
When then loops become endless, they will repeatedly print the assertion
failure message. When run as part of the test suite via Meson, Meson
will collect all printouts in memory. Therefore the meson process will
use memory rapidly without bounds.
Break all these loops.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
With the future bump to Trixie we have a few more leaks outside of the
Weston test suite. Add them to leak suppresion file.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
To accommodate some future CI bump to Trixie (doxygen/breathe issue)
move out the anonymous enum out of weston_output object.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Implement media white point scaling according to ICC.1:2022 (profile
v4.4), section 6.3.2.2 "Translation between media-relative colorimetric
data and ICC-absolute colorimetric data".
This is a lot of code for something that, under the current
circumstances, is a no-change. However, realizing that chromatic
adaptation and media white point scaling are two separate adjustments
was a revelation to me. I want to document in code how they work, even
if the net result is no-op.
The PCS white point is taken from ICC, it does not matter what non-zero
point it is, the result will be the same.
I did skip a bit the media white point scaling. One should first scale
from in to PCS, and then from PCS to out. The code is mathematically
equivalent. If some new operation needs to be done in between, this step
than be split in two, just like I split the chromatic adaptation step in
two in this patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
According to ICC, chromatic adaptation applies also to ICC-absolute
colorimetric rendering intent.
ICC-absolute and media-relative colorimetric rendering intents are
indeed identical as long as medium white point equals adapted white
point.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the correct name for what is implemented.
The term "white point adaptation" cannot be found in ICC.1:2022 (v4.4)
nor at https://cie.co.at/e-ilv .
Personally I am confused whether it would mean chromatic adaptation or
media white point scaling.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
With the addition of the weston_output_set_ready() call, the shell fade
animation is now started during the very first repaint. The first repaint
doesn't have an accurate frame_time for the previous repaint, as none has
occurred yet.
Since we set the time base for an animation based on the output's frame
time the second time the animation is run, we end up setting the shell fade
start time to 0, and the first real repaint advances the timer to the real
time, generating a warning and truncating the animation.
Instead of tracking the number of animation frames, let's just continue to
reset the time base until we finally get a non-zero time.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
A destroyed paint node must be rebuilt at great cost the next time the
view is displayed on an output.
Keep the paint node around and just remove it from the z order list instead
of destroying it outright.
fixes#1072
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
As weston_compositor_build_view_list() marks all the outputs needing a
paint node rebuild of the re-order list, embed the paint node status
update to ALL_DRITY into straight into weston_output_build_z_order_list().
This way we'll latch it on the view list rebuild.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This de-couples the compositor view build list from the paint node
ordered list to allow a more finer grain over what lists we need to
rebuild upon repaints.
As a consequence to that this avoids a trip over from the compositor
when paint nodes are destroyed and no longer re-created upon rebuilding
the view list.
Fixes: #1070
Fixes: abfe874a ("core: Don't rebuild view list on surface-local changes")
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
And implicitly remove the need to build autoconf and libx11. Removed wget
and xutils-dev as those are not needed anymore.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The following config allows to mirror the LVDS output to VNC:
|[output]
|name=LVDS-1
|transform=rotate-270
|
|[output]
|name=vnc
|mirror-of=LVDS-1
However, the current code only takes the scale into account, not the
relative transformation. In case of rotate 90 or 270 the width and height
have to be swapped. Add it.
Closes: https://gitlab.freedesktop.org/wayland/weston/-/issues/1076
Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
This was brought up in issue 1063. The assertion in
weston_presentation_feedback_present_list() will trigger randomly during
repeated suspend/resume testing, presumably while a client is animating
and asking for presentation feedback.
drm_output_start_repaint_loop() has a path where drmWaitVBlank() is able
to pull a good timestamp for the last vblank. This results in a call to
weston_output_finish_frame() with a good timestamp and
WP_PRESENTATION_FEEDBACK_INVALID in the flags.
Previously it was assumed that in such case the presentation feedback
list cannot have any entries. This assumption is false. It is possible
that while the output is in idle state, a client will post an update to
a surface and ask for presentation feedback on it. This should trigger
drm_output_start_repaint_loop() with a non-empty feedback list.
It is unclear why this problem was not seen in the wild much more often.
Start-repaint-loop does not present anything by definition, it only acts
to synchronize the output repaint loop with the (hardware) scanout
cycle. Therefore no feedback must be sent there. As
WP_PRESENTATION_FEEDBACK_INVALID flag indicates no feedback must be
sent, use it to avoid calling
weston_presentation_feedback_present_list().
References: https://gitlab.freedesktop.org/wayland/weston/-/issues/1063
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This needs to extend the VkMemoryRequirements2 struct, not
VkImageMemoryRequirementsInfo2.
Fixes: ad0f4cf9 ("vulkan-renderer: make dmabuf import dedicated allocation optional")
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
If the Wayland connection died, this code path ended up in an endless
loop, because test-asserts do not abort. Break out to fix this. The
test-assert records the failure, so not need to do more.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Deprecate the screenshooter recording mode, with the intention of
removing it in libweston 16. Using the PipeWire backend (or similar) is
a far better and more flexible way of capturing output content.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The DRM backend has had a VA-API recorder for a while, which pushes the
frames from every redraw into libva for compositor-side recording.
Implementing this manually in the compositor, and configuring it, is
kind of pain. We now have the PipeWire backend which can do
screencasting in a much more flexible way without having to push
everything into the compositor itself, and without having to hardcode
support for one particular encoder framework.
Deprecate this module with the intention of removing it in the Weston 16
cycle, along with screenshare (for similar reasons).
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add a debug binding and mode to highlight (green tint) what has
been rendered through vulkan-renderer composition. This is useful
to visually identify/debug clients which have been offloaded to
DRM planes, since those won't go through the renderer composition
process and therefore won't be highlighted the same way.
Since this is the first debug mode in vulkan-renderer, add some
initial infrastructure to handle debug bindings.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
The VkSpecializationMapEntry use was incorrect here, it requires the
struct offset to be in the second entry.
Fixes: 8f56d03d ("libweston: Vulkan renderer")
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
This is basically a revert of 6f94022e ("ivi-shell/layout: Create a
temporary background curtain") to remove the blank/blank
curtain in ivi-shell and use the weston_output_set_ready to notify the
compositor that it is start issueing repaints.
Introduces a new callback in ivi-layout which controllers can call on
their own.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This reverts commit 0ff5ac0f7b.
Now that we have a way to prevent repaints of empty scene graphs from
the shells, remove the curtains and just have our first paint be
proper content.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We've added a curtain to the shells so at startup we have something to
render, but this causes a flicker if someone is trying to have a seamless
transition from boot to weston.
Add a ready flag that allows the shell to indicate repaints are safe, so
we can remove the curtains and have no wasted frames at startup.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Similarly to simple-egl, teach simple-shm to also do that if pressing
F11. Allows testing stuff much easier -- without installing key-bindings
in the shell.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This already existed for surface, so it is trivial to add.
This will let the upcoming plane state reuse code notice a format change.
This is handy because a client might respond to dmabuf feedback by changing
formats, with the expectation that doing so would land content on a plane.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This was in the late update because attaching buffers is something only
the renderer cares about.
However, the upcoming drm plane state re-use patches need to know if the
buffer changed before assign_planes, so we need this in the early update.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The assert added in 78657c5ff3 will cause
problems when we try to reuse cached drm plane layouts in the future -
instead of asserting on an exact gbm fb, assert that the the fb type
corresponds has the cursor type instead.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Although Vulkan's renderbuffers are dmabufs, the difference between a
client dmabuf and a backend-allocated dmabuf is a very meaningful one.
Add a separate buffer type for BUFFER_DMABUF_BACKEND instead of
overloading BUFFER_DMABUF for this.
This tangentially allows the Vulkan renderer to do direct scanout of
client buffers in mixed mode.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The DRM documentation states:
> Unless explicitly specified (via CRTC property or otherwise), the active
> area of a CRTC will be black by default. This means portions of the active
> area which are not covered by a plane will be black, and alpha blending of
> any planes with the CRTC background will blend with black at the lowest zpos.
See https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-abstraction
This means the view for the primary plane does not need to cover the
whole output and black areas of the scene-graph can be left out.
Doing so has various benefits - most importantly it:
1. allows us to use the plane-only path in more situations and with one
less plane, reducing memory bandwidth usage.
2. opens the path to offload arbitrary background colors in the future.
Iterate over the all visible paint nodes, remove solid-opaque-black
views so they are not considered for plane assignment and aggregate a
region that is later used to assign the primary plane.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
So far scene-graph building and plane assignment happened within a single
loop. In the future we want to be able to optimize the scene-graph
before assigning, thus split up the loop into two steps.
No behavioral changes intended.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
This changeset adds three variants of the U.S. Dvorak layout to the
table that is used to map a keyboard ID in the RDP backend to an Xkb
configuration. This makes it possible to have these variants
propagated seamlessly from an RDP client into the Wayland compositor.
As the backend-rdp module requires at least version 2.3.0 of the
FreeRDP library to build, the symbols for these variants is already
present in include/freerdp/locale/keyboard.h, included by rdp.h here,
and in libfreerdp/locale/xkb_layout_ids.c which translate the selected
layout in Xkb into the keyboard ID sent over the wire for the RDP
protocol.
Signed-off-by: Roland Kaufmann <rlndkfmn+freerdp@gmail.com>
We've been clobbering non-solid buffers with solid buffer attachment in
situations where we override the real buffer with a placeholder.
If the reason (punch hole, censor) that led to the placeholder is no
longer in effect, and new buffer is attached, we won't render what we should.
Instead, let's not attach anything for the paint node draw_solid case, and
allow gl_buffer_state be NULL when the real buffer is solid. gl_buffer_state
can then always be the correct state for the real buffer, even if we don't
use it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Currently it uses some values from the existing sconf, instead let's make
it calculate everything on its own
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Refactor textured draw setup into a separate function, preparing for a
future where we set up solid draws from init_for_paint_node as well.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Turns out gl_shader_config_set_input_textures is what adds the filter
parameters to the sconf, so we must set the filters before calling it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that we have a glClear() region optimization for opaque solid surfaces,
we should make sure we test transparent solid surfaces as well.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Instead of doing duplicated calculations. Apart from being faster and
less code, it should help ensuring correctness of the given regions.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
is_fully_opaque notably applies to opaque single-pixel-buffer views
without opaque region. Using it should be purely an optimization.
The check for alpha in turn may fix bugs in certain conditions.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Let's just make them show up in the perfetto traces when they actually
happen, so it's a little easier to see how much benefit we derive from
trying to defer them.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Previously, inverse_evaluate_lut1d was called 3 * len^3 times. Now it is
called only 3 * len times with the help of pre-computed arrays for red
and green channels. Blue channel does not need an array, because there
were no redundant computations. This is a significant win.
Also, allocate a temporary array rgb_in, so cmsDoTransform() can be
called in batches of len triplets. This seemed to be not that big win. I
tried running cmsDoTransform() over len^2 triplets, but that did not
seem to improve performance.
The test I used creates two 3D LUTs, hence two times for a single run.
My representative timing test results per one 3D LUT:
- before: 16 ms and 19 ms
- after: 7 ms and 10 ms
The measurements were done with this patch:
static bool
xform_to_shaper_plus_3dlut(struct weston_color_transform *xform_base,
uint32_t len_shaper, float *shaper,
uint32_t len_lut3d, float *lut3d)
{
struct cmlcms_color_transform *xform = to_cmlcms_xform(xform_base);
struct weston_compositor *compositor = xform_base->cm->compositor;
bool ret;
+ struct timespec begin, end;
+ unsigned i;
- ret = build_shaper(xform->lcms_ctx, xform->cmap_3dlut,
+ clock_gettime(CLOCK_MONOTONIC, &begin);
+ for (i = 0; i < 100; i++)
+ ret = build_shaper(xform->lcms_ctx, xform->cmap_3dlut,
len_shaper, shaper);
if (!ret)
return false;
- ret = build_3d_lut(compositor, xform->cmap_3dlut,
+ for (i = 0; i < 100; i++)
+ ret = build_3d_lut(compositor, xform->cmap_3dlut,
len_shaper, shaper, len_lut3d, lut3d);
if (!ret)
return false;
+ clock_gettime(CLOCK_MONOTONIC, &end);
+ fprintf(stderr, "%s: %" PRId64 " ms\n", __func__, timespec_sub_to_msec(&end, &begin));
return true;
}
Using this command:
$ ./tests/test-color-icc-output -f 8 opaque_pixel_conversion
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This removes the API impedance mismatch between
weston_color_curve_sample() and weston_color_curve_to_3x1D_LUT() that
was temporarily introduced in the previous commit. That mismatch is now
limited to gl_color_curve_lut_3x1d().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Future development will need to evaluate pipelines with curves and
matrices. Such pipelines naturally operate on vec3, as matrices cannot
be operated one channel at a time. Make weston_color_curve_sample()
operate on arrays of vec3.
Its currently only caller, weston_color_curve_to_3x1D_LUT(), is modified
to employ a temporary array for the API impedance mismatch. This
workaround will be removed later as weston_color_curve_to_3x1D_LUT()
itself will be converted to operate on vec3 arrays.
weston_v3f_array_to_planar() documentation was generated with AI.
weston_color_curve_sample() is restructured a little bit, attempting to
make it simpler to read.
color-operations.h gets the #includes needed to make it self-standing.
Assisted-by: Github Copilot (Claude Sonnet 3.5)
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We can handle the mirroring for negative input without conditional this
way. Maybe it's faster, maybe it's not, but I like this style better.
In color-operations we need only one call to the elementary function
rather than two. This helps a lot with code clarity, when we get a vec3
at a time to handle in the future, doing three trivial calls instead of
six with an if-else hassle.
fragment.glsl sheds one layer of function wrapping, which is nice.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
