On some aarch64 platforms with GCC13 we're seeing:
../../../weston-14-new/libweston/backend-drm/fb.c:152:15: warning: 'bo_fd' may be used uninitialized [-Wmaybe-uninitialized]
152 | ret = drmPrimeFDToHandle(fb->fd, bo_fd, &handle);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../weston-14-new/libweston/backend-drm/fb.c: In function 'drm_fb_addfb':
../../../weston-14-new/libweston/backend-drm/fb.c:117:13: note: 'bo_fd' was declared here
117 | int bo_fd;
Just initialize it to avoid trigger the warning.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Recent versions of libwayland support absolute paths in display names,
and in that case do not require XDG_RUNTIME_DIR to be set. It's
therefore overly strict for Weston to exit due to XDG_RUNTIME_DIR being
unset when it would work perfectly fine without it. The messages
displayed for incorrectly set XDG_RUNTIME_DIR are useful though, so keep
them around, but only display them if wl_display_add_socket() fails
i.e. the lack of XDG_RUNTIME_DIR has actually caused a problem.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
It looks like FALSE is only used in a few files in Weston, whereas false is much
more commonly used. Presumably FALSE comes from some library not included in
the headless backend (at least in my case).
FAILED: [code=1] libweston/backend-headless/headless-backend.so.p/headless.c.o
gcc -Ilibweston/backend-headless/headless-backend.so.p -Ilibweston/backend-headless -I../../home/qyliss/src/weston/libweston/backend-headless -I. -I../../home/qyliss/src/weston -Iinclude -I../../home/qyliss/src/weston/include -Ilibweston -I../../home/qyliss/src/weston/libweston -Iprotocol -I/nix/store/mvhj7fm6bkmz6ismdp8vcmwn34w94b8n-libglvnd-1.7.0-dev/include -I/nix/store/v7jn3cy1wjaf9pm60ix9y6dfma0bj4a3-wayland-1.24.0-dev/include -I/nix/store/xi04j07bl6bbckky5n8a1k06spxxfg9i-pixman-0.46.4/include/pixman-1 -I/nix/store/xvzhnfwxvl480qpjxm83wwhd287b3lgm-libxkbcommon-1.11.0-dev/include -I/nix/store/22qgb8p593613861117ay4gzmf9b7rns-libdrm-2.4.125-dev/include -I/nix/store/22qgb8p593613861117ay4gzmf9b7rns-libdrm-2.4.125-dev/include/libdrm -I/nix/store/zl58kqaf677skihj840rf05svsmrhmmc-cairo-1.18.4-dev/include/cairo -I/nix/store/6sscd9xxffhjrci2xbw9yv8inc2rc0ry-freetype-2.13.3-dev/include/freetype2 -I/nix/store/6sscd9xxffhjrci2xbw9yv8inc2rc0ry-freetype-2.13.3-dev/include -I/nix/store/z88mxig65mxgyn1yxsz92m4w1rn51aci-libpng-apng-1.6.50-dev/include/libpng16 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -std=gnu11 -O0 -g -Wmissing-prototypes -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -Wundef -fvisibility=hidden -Wmissing-prototypes -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -Wundef -fvisibility=hidden -fPIC -MD -MQ libweston/backend-headless/headless-backend.so.p/headless.c.o -MF libweston/backend-headless/headless-backend.so.p/headless.c.o.d -o libweston/backend-headless/headless-backend.so.p/headless.c.o -c ../../home/qyliss/src/weston/libweston/backend-headless/headless.c
../../home/qyliss/src/weston/libweston/backend-headless/headless.c: In function ‘config_init_to_defaults’:
../../home/qyliss/src/weston/libweston/backend-headless/headless.c:788:29: error: ‘FALSE’ undeclared (first use in this function)
788 | config->fake_seat = FALSE;
| ^~~~~
../../home/qyliss/src/weston/libweston/backend-headless/headless.c:788:29: note: each undeclared identifier is reported only once for each function it appears in
Fixes: 0126a5b4 ("backend-headless: Add an option to enable a fake seat")
Signed-off-by: Alyssa Ross <hi@alyssa.is>
The helpful error message with the hint to set -Dbackend-vnc=false was
unreachable, because libpam would either be found, or the default, less
helpful error message for a missing library would be shown.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
When running headless, weston will not expose a wl_seat.
This was removed with commit a1046adc ("compositor-headless: do not
create a seat").
However, some applications, namely GTK3 based, will log a warning when
there is no wl_seat:
| gdk_seat_get_keyboard assertion GDK_IS_SEAT(seat) failed
While this is arguably a bug in GTK3 which should not complain with a
legit setup, that breaks the CI of those projects when using Weston,
while most of the other Wayland compositors will create a fake seat when
running headless, making weston the odd ball there.
This changes adds a new option "--fake-seat" that will instruct weston
to create a seat when running headless. The default remains not to
create a seat though, so backward compatibility is preserved.
This partially reverts commit a1046adc66.
See-also: https://gitlab.freedesktop.org/ofourdan/xwayland-run/-/issues/12
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Add support for the fifo protocol, which allows an application to submit
a content update that can only be applied after the previous content
update has been active for a display refresh.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that we have surface-state application streamlined, it's fairly easy to
add a framework for deferring content updates.
This will be used soon for fifo and commit timing. For now, the
weston_surface_state_ready() call that makes any of this do something
will always return true.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
If a surface isn't visible, there's no point in performing a repaint when
its state changes. However, we don't know if a surface is visible until
we perform the scene graph updates at repaint.
Use our new visibility tracking API to check whether we need to perform
a repaint, or if we can just skip it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Keep track of whether a view has any unoccluded pixels on an output,
use this information to add a weston_surface_visibility_mask() function
that we'll use later.
Since the visibility information is calculated at repaint, and invalidated
by some (but not all) state updates, we'll keep track of when the previous
repaint's status is still valid by watching surface status bits.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Seems like it makes sense to have it there, and this cleans up a bunch of
paths where we return status bits so a caller can do this.
We can also drop the explicit setting of view_list_needs_rebuild, as it's
going to happen automatically when applying subsurface order.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In the future more than one test group will want to use presentation
feedback, so let's pull the basics into weston-test-client-helper
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We open code this in several tests. Move a single implementation to
weston-test-client-helper instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Latch is the moment when the compositor considers updates for an upcoming
redraw. Nothing that takes place after an output latches for repaint can
change what will be repainted.
This needs a more explicit treatment now that upcoming transactional
protocols require things to happen immediately after the latch (ie:
when it's too late to change the upcoming render).
Add an explicit latch point, a signal to tap for testing, and some asserts
to make sure nothing can violate the inevitability of the current render
state.
Note that currently latch is tied to repaint such that we only claim to
have latched when a repaint will happen. In a future commit this will lead
to forcing the repaint loop to fire without damage when the fifo protocol
needs something to happen after a latch. This could be an area for
future improvement.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We're going to be adding protocols (commit-timing, fifo, syncobj) that
allow deferred surface content updates.
It makes sense to start the perfetto flow ids from the surface state so
we can track a flow from creation (ie:commit) to presentation.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
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>
