This uses the more safer version of signal emission to avoid a potential
crash when the output is destroyed that will follow a surface/view
destruction for which it has a listener attached (to the output_destroy
signal).
Fixes: #734
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This avoids crashes due to removal of notification listeners from within
invocations of other listener callbacks in the same signal emission.
Fixes: #415
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Wayland signals (wl_signal) do not reliably handle changes to the
notification list during signal emission. Such scenarios occasionally
come up and can be difficult to investigate and debug.
This commit introduces the weston_signal_emit_mutable() function which can be
used in place of wl_signal_emit() and safely implements the following
behavior regarding notification list changes:
1. Listeners deleted during a signal emission and which have not already been
notified at the time of deletion are not notified by that emission.
2. Listeners added during signal emission are ignored by that emission.
The implementation of weston_signal_emit_mutable() is copied from the
wlr_signal_emit_safe() function of the wlroots project.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
One of the best things about a real test framework is that they handle
timeouts for you.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Simon Ser <contact@emersion.fr>
This was previously introduced with commit '.gitlab.ci: Enable debug for
libsteat and for the DRM backend' in order to figure out another CI
issue we were seeing.
Unfortunatelly, not keeping the return value after the tests ran it
would silently make the entire CI succeed when it should actually fail.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This avoids some unwarranted errors about conditional jumps or
invalid access from ASan as malloc doesn't set the memory to zero.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
According to xdg-shell spec, if the surface doesn't cover the whole
output we should center it and install a border fill covering the rest
of the output.
While we center out the surface we never got around installing the
border fill. This patch re-uses the activation of a surface to control
this bit as well, by making use of an new layer to place the
surface while not being active.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Walking the format/modifier list to try to find out if our FB is
compatible with the plane is surprisingly expensive. Since the plane's
capabilities are static over the lifetime of the KMS device, cache the
set of planes for which the FB is theoretically
format/modifier-compatible when it's created, and use that to do an
early cull of the set of acceptable planes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we first create a drm_fb from a weston_buffer, cache it and keep it
alive as long as the buffer lives. This allows us to reuse the gbm_bo
and kernel-side DRM framebuffer, rather than constantly creating and
destroying them at every repaint. The overhead of doing so (e.g. MMU
updates) can be significant on some platforms.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Currently each drm_fb takes a reference on a client buffer it wraps.
This prevents us from being able to reuse a drm_fb in multiple places
(e.g. two views of the same client buffer) simultaneously, or even back
to back.
Move the buffer reference to the plane state, as preparation for
allowing drm_fb to be cached inside the weston_buffer.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Currently we take a reference on the underlying client buffer every time
we materialise a drm_fb from a view, and release it when the drm_fb is
destroyed. This means that we need to create and destroy a drm_fb every
time we want to use it, which is pathologically unperformant on some
platforms.
To start working towards being able to cache drm_fb, only take the
reference when we apply it to a plane state.
Signed-off-by: Daniel Stone <daniels@collabora.com>
No sense walking the plane list every frame if we can't use it because
it's neither a SHM buffer nor a client buffer we can directly import as
a framebuffer.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we still have a pending idle timer when the compositor is being
destroyed, make sure to free it first.
Signed-off-by: Daniel Stone <daniels@collabora.com>
I do not know what happens if multiple jobs declare
artifacts:reports:cobertura. Maybe the last job to finish wins? Who
cares, Gitlab can only show the results from one cobertura report in the
MR diff view.
Recently, the MR diffs have the coverage annotations, but there was a
time when they seemed to be missing. I don't know why.
Let's make sure the cobertura report Gitlab will use is from the "main"
build only: 64-bit Debian with full features and gcc.
I do not move the after_script, because maybe someone could have a
reason to look at arch-specific coverage reports, so I want to leave the
HTML there in the artifacts.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
drm-smoke-test can't run at the same time as anything else which touches
DRM devices. This includes any test which would use the GL renderer or
GL/GBM on the client side, since they will open DRM devices to probe
them at init time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
As the drm-smoke test randomly reports having the connector disabled,
and with it libseat reports setMaster errors, this enables DRM backend
debug messages for the kernel, and for libseat in an attempt to
track down the issue, whenever it might happen again.
These are pretty harmless, in terms of data being generated as we only
have a single DRM test using VKMS, and the libseat debug message aren't
that verbose, so we're safe keeping them for the time being.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
EGLNativeWindowType can be a lot of different things, including a
pointer which an XID is not. Explicitly cast it through uintptr_t so we
don't throw build warnings either way.
Signed-off-by: Daniel Stone <daniels@collabora.com>
GStreamer can accept up to four planes for a buffer; gcc isn't _quite_
smart enough to figure out that only the first plane of offset/stride
will be accessed and so throws a warning that the params are too small.
Fix that by making them arrays.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Simple client to test the dma-buf feedback implementation. This does not
replace the need to implement a dma-buf feedback test that can be run in
the CI. But as we still don't know exactly how to do this, this client
can be helpful to run tests manually.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
In commit "libweston: add initial dma-buf feedback implementation" we've
added initial support to dma-buf feedback, but it was not using the
feedback from DRM-backend to add useful per-surface feedback.
In this patch we add this. The scanout tranche of the per-surface
feedback is based on the union of formats/modifiers of the primary and
overlay planes available. These are intersected with the
formats/modifiers supported by the renderer device.
Also, it's important to mention that the scene can change a lot and we
can't predict much. So this patch also adds hysteresis to the dma-buf
feedback. We wait a few seconds to be sure that we reached stability
before adding or removing the scanout tranche from dma-buf feedback and
resending them. This help us to avoid spamming clients and leading to
unnecessary buffer reallocations on their end.
Here's an example of what we want to avoid:
1. We detect that a view was not placed in a plane only because its
format is not supported by the plane, so we add the scanout tranche
to the feedback and send the events.
2. A few milliseconds after, the view gets occluded. So now the view
can't be placed in a plane anymore. We need to remove the scanout
tranche and resend the feedback with formats/modifiers optimal for
the renderer device. The client will then reallocate its buffers.
3. A few milliseconds after, the view that was causing the occlusion
gets minimized. So we got back to the first situation, in which the
format of the view is not compatible with the plane. Then we need to
add a scanout tranche and resend the feedback...
This patch is based on previous work of Scott Anderson (@ascent).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Add enum try_view_on_plane_failure_reasons to help us to keep track of
the reason why promoting view to a plane failed. We also add a variable
to struct weston_paint_node so that we can update this information in
each output repaint.
This will be used in the next commits, in which we add proper surface
dma-buf feedback support.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This adds the initial dma-buf feedback implementation, following the
changes in the dma-buf protocol extension.
The initial dma-buf feedback implementation gives support to send
default feedback and per-surface feedback. For now the per-surface
feedback support is very basic and is still not implemented in the
DRM-backend, what basically means that KMS plane's formats/modifiers are
not being exposed to clients. In the next commits of this series we add
the DRM-backend implementation.
This patch is based on previous work of Scott Anderson (@ascent).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This just documents why we can be sure that
renderer->get_supported_formats() is set in bind_linux_dmabuf().
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
It simply returns the number of format/modifier pairs in the array. This
will be useful for the next commits, in which we add support for dma-buf
feedback.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Add function to query the DRM device given an EGLDisplay. It is the
device being used by the compositor to perform composition.
This will be useful in the next commits of this series, where we add
support for dma-buf feedback.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Bump the wayland-protocol dependency version in order to include dma-buf
feedback, whose support in Weston is added in the next commits.
Also, as we need the newer EGL extension EGL_EXT_device_drm_render_node
to add the support for dma-buf feedback, bump the Mesa dependency
version as well.
It also includes some minor changes in order to keep build-deps.sh more
consistent.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Constraining the buffer size of an EGLConfig to 32 means that
the sum of red, green, blue, and alpha channels must equal 32.
This constraint prevented weston-simple-egl from picking an
RGBX pixel format when an opaque surface was asked for, since
the typical RGBX pixel formats have buffer sizes of 30, 24,
and 16.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Now Debian 11 (Bullseye) has been released, shift our CI builds to using
that instead of the older Buster.
Due to dependency-chain changes, we have to install a lot more packages
explicitly and retain more at runtime. This is exacerbated by pkg-config
now requiring the entire chain to be installed, not just the immediate
dependencies.
Our documentation toolchain also gets bumped to a higher version to deal
with Doxygen changes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Older kernels cannot be built and booted with GCC 10+, as included in
Debian bullseye, due to unfortunate stack-canary issues:
https://lore.kernel.org/lkml/20200314164451.346497-1-slyfox@gentoo.org/T/
Upgrade to the last-released kernel, 5.14, to fix this.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Errors happening to devices being added or removed shouldn't fail
silently so exit if any of that happens.
Sprinkle some debug logs for other cases as well.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Starting with commit 'desktop-shell: Embed keyboard focus handle code
when activating' we are iterating over all the seats when removing a
weston_desktop_surface to be able to invalidate the activate surface.
Upon compositor tear down the shell destroy might invalidate seats
before removal of the weston_desktop_surface making the shell_seat
itself invalid. This wasn't apparent at that time because we're not
handling at that the removal of surfaces from layers.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This adds "icc_profile" key support in [output] sections for backends
headless, x11, wayland, and drm, and also for remoted and pipewire
outputs FWIW. On the other hand, RDP-backend does not use output
sections from weston.ini, and fbdev-backend does not deserve anything
new (it wouldn't support color management anyway due to no GL-renderer).
This allows one to configure an ICC v2 or v4 file to be used as an
output profile. However, color-lcms does not actually use output
profiles yet, so trying this will fail until support is implemented.
The parent_winsys_profile argument is reserved for using the color
profile from a parent window system where applicable, if nothing else is
set in weston.ini. None of the nested backends provide an output color
profile yet. It is more of a reminder of a missing feature than a
serious implementation.
Note: cms-static Weston plugin uses the exact same weston.ini key for
loading VCGT from ICC profiles. If "color-management" option is set to
false, this new use of "icc_profile" is disabled and the old behavior
with cms-static is kept.
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>
Move the code into a new function that either succeeds in setting all
the color transformations or does not change anything. This will be
useful when implementing output color profiles changes while the output
is enabled.
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>
It will cause on following situation:
* Enable weston-simple-im
* It's also reproducible with IBus or Fcitx5
* Connect a mouse or a touch panel
* Don't connect keyboad
* Launch weston-editor and touch the text area
It doesn't reproduce with weston-keyboard because it doesn't use
grab_keyboard of input-method-context-v1.
Signed-off-by: Takuro Ashie <ashie@clear-code.com>
The "sans" and "mono" aliases for "sans-serif" and "monospace" are
deprecated[1]. Let's standardize on the non-deprecated versions, which were
already in use in some places.
[1]: be453bd159/fonts.conf.in (L33-67)
Signed-off-by: Alyssa Ross <hi@alyssa.is>
When trying to get Weston to run on a new system I was building up bit
by bit, I encountered a problem: when I started weston-terminal, it
would close a split second later. This turned out to be because
weston-terminal defaults to trying to spawn /bin/bash, which my
busybox-based system didn't have.
I can configure the terminal to use a shell I do have, of course, but I
think /bin/sh is a much friendlier default, because it's more likely to
exist (POSIX requires it), and will save people just trying to get
started with Weston from the confusing experience I had. I think it's
better overall that somebody who specifically wants /bin/bash has to
configure that (if they even have to — depending on how they're running
Weston, $SHELL might already be /bin/bash) than somebody who just wants
to see the terminal working debug why it won't launch at all.
I realise there might be a (small) backward compatibility concern here
as well, but I hope I've made the case for a friendlier default.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
The doc website is currently hidden in the Wayland homepage. Add
an explicit link in the README.
While at it, rename the section about documentation. "Weston" is
already in the repository name and the top oif the README, so no
need to repeat here.
Signed-off-by: Simon Ser <contact@emersion.fr>
No functional change. Moved color processing
functions into shared files which can be used
between different tests.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
The seat_cap listener was to register a signal for keyboard_focus, which
we no longer use. Remove it entirely to avoid dead code.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Derek Foreman <derek.foreman@collabora.com>
As kiosk-shell can't cope with multiple seat add a warning and avoid
creating any new seats. With it, this guards against potentially
receiving an invalid seat.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Marius Vlad
Alexandros Frantzis
Daniel Stone
Simon Ser
Leandro Ribeiro
Pekka Paalanen
Scott Anderson
Manuel Stoeckl
Takuro Ashie
Alyssa Ross
Vitaly Prosyak