Initially, `_XWAYLAND_ALLOW_COMMITS` was introduced in commit 7ace831ca
to avoid drawing the window content before it's ready to be shown.
But a repaint might also be triggered by the client damages before the
XWM has finished drawing its window decorations and drop shadows, which
previously was not too much of an issue since the XWM could still
finish updating the X11 window after the buffer was submitted.
However, with the addition of multiple window buffers in Xwayland [1]
which are aimed at preventing the X11 clients from updating the buffer
after it's been committed, this is no longer possible.
As a result, the use of multiple window buffers in Xwayland can cause
ugly repainting effects of the decorations if the buffer is submitted
before the XWM has finished painting its decorations.
Use the X11 property `_XWAYLAND_ALLOW_COMMITS` can be used to avoid
this, by controlling when Xwayland should commit changes to the Wayland
surface.
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/316
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This is necessary for the test harness to be able to execute the compositor
multiple times in the same process. As we never unload opened modules, the
first compositor iteration will leave them all loaded and following compositor
iterations will then have them already loaded.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is necessary for the test harness to be able to execute the compositor
multiple times in the same process. As we never unload opened modules, the
first compositor iteration will leave them all loaded and following compositor
iterations will then have them already loaded.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This introduces a new convention of checking through the compositor destroy
listener if the plugin is already initialized. If the plugin is already
initialized, then the plugin entry function succeeds as a no-op. This makes it
safe to load the same plugin multiple times in a running compositor.
Currently module loading functions return failure if a plugin is already
loaded, but that will change in the future. Therefore we need this other method
of ensuring we do not double-initialize a plugin which would lead to list
corruptions the very least.
All plugins are converted to use the new helper, except:
- those that do not have a destroy listener already, and
- hmi-controller which does the same open-coded as the common code pattern
did not fit there.
Plugins should always have a compositor destroy listener registered since they
very least allocate a struct to hold their data. Hence omissions are
highlighted in code.
Backends do not need this because weston_compositor_load_backend() already
protects against double-init. GL-renderer does not export a standard module
init function so cannot be initialized the usual way and therefore is not
vulnerable to double-init.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This was forgetting to remove the compositor destroy listener, which would lead
to use-after-free on compositor tear-down especially on cms-colord init failure
paths. Found by inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This was forgetting to remove the compositor destroy listener if init failed,
which would lead to use-after-free on compositor tear-down. Found by
inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This was forgetting to remove the compositor destroy listener if init failed,
which would lead to use-after-free on compositor tear-down. Found by
inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
While get_presentation() will only ever be called once (making the caching of
the return value moot), it is good to stop using the static variable as it
would cause surprising problems if anyone adds more tests here and runs it
under the new test harness.
It was leaked before and continues to be so.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Using static data will mess things up when the test harness no longer fork()'s
each sub-test. Hence it needs to be converted to "normal" data.
Unfortunately here the cached value was actually used, so keeping that
behaviour is a handful. Yes, it was all leaked also before.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Just one test call this only once, so the cached value will never be useful.
Stop using static data, it sets a bad example. If more tests were added, things
would start failing when forking is removed from the test harness.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
I cannot see any reason why this should be static data. But if it is static
data, it will prevent re-entering wet_main() to run tests with this plugin, so
replace it with "normal" data.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This caching is actually never hit. I tested by making the early return abort()
instead and all works just fine.
Remove the caching. The static variable will cause problems when we stop
fork()'ing for each test case.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
As we avoid importing the buffer in the GPU, when attaching the buffer
we'll not have a valid image to retrieve it from, and as such we'll
avoid touching and setting the surface state shader.
This adds also 'direct_display' to the surface state and with it, sets the
surface state 'direct_display' member whenever the imported buffer will
have the direct-display member set.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Adds a new callback 'can_scanout_dmabuf' in weston_backend, which
can be set by the back-end do determine if the buffer supplied can be
imported directly by KMS.
This patch adds a wrapper over it, 'weston_compositor_dmabuf_can_scanout'
which is called before importing the dmabuf in the GPU if the
direct_display dmabuf is being set. If that's true and the check
failed, we refuse to create a wl_buffer.
This patch avoids importing in the GPU.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Weston extension to assure clients that the dmabuf buffer will be
forwarded directly to the display controller.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This comment was added in 230f3b1bf8 with the
intent that if we had an information table about pixel formats (which we do
have today), we could implement more sanity checks like ensuring that width
pixels fit into stride.
Daniel Vetter said on #dri-devel IRC recently:
< danvet> since userspace shouldn't look at stride for buffers with
modifiers, only pass it around unchanged
I asked for clarification. It was expected that userspace would not do any kind
of sanity checks as modifiers could change everything.
Let's remove the misleading code comment so that people don't get the idea of
adding more well-intended but ill-advised sanity checks. If more checks are
added, they must take the modifier into account, which the existing checks do
not do.
After 5 years, it is far too late to remove our existing sanity checks, but we
can attempt to not cause any more damage that would restrict what people can do
in the kernel.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Increase the buf size such it can accomodate sufficiently large local
buffers. Spotted whilst looking for something else.
../compositor/main.c:157:22: warning: ‘%s’ directive output may be
truncated writing up to 511 bytes into a region of size 128
[-Wformat-truncation=]
157 | snprintf(buf, len, "%s[%s.%03li]", datestr,
| ^~ ~~~~~~~
../compositor/main.c:157:21: note: directive argument in the range
[-9223372036854775, 9223372036854775]
157 | snprintf(buf, len, "%s[%s.%03li]", datestr,
| ^~~~~~~~~~~~~~
../compositor/main.c:157:2: note: ‘snprintf’ output between 7 and 659
bytes into a destination of size 128
157 | snprintf(buf, len, "%s[%s.%03li]", datestr,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
158 | timestr, (tv.tv_usec / 1000));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
It makes much more sense to be there. It adds some additional drm_debug()
statements to provide reason for failing to place the view in the HW
plane. Makes the reason for failing more accurate.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Avoids the need to retrieve the DRM framebuffer in each function and
re-uses the one got before constructing the zpos candidate list.
Takes another reference for the scanout as to live the state, like
there's one for the overlay bit.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As we already have a potential plane available to use, pass it
over the _prepare_overlay_view instead of trying to find one
from the backend plane list.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
In this manner we will allow views to reach the overlay (or underlays)
even if the damage tracking will detect that the new view will
occlude the view underneath it.
Renames occluded_region to planes_region, and uses occluded_region
to represent the region where we add each view's visible-and-opaque region.
Sprinkle some comments about each region.
Re-uses the view's clipped region to determine visible-and-opaque region
which is accumulated (for both renderer and HW planes cases) into
occluded_region. The current view's clipped_region is then checked against
occluded_region.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
We can determine if the pixel format used by the clients buffer is
scan-out capable much sooner, so do it when constructing the zpos
candidate list. It also removes the checks in their respective
prepare_ functions.
Avoids the situation where we'd need to retrieve the DRM framebuffer each time
when checking the pixel format.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
function
The idea is to place pixel the format checks in a common part and until
then, to make it available as a function so we can re-use easily.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
In order to better optimize view assignment to HW planes, we construct
an intermediary zpos candidate list which is used aggregate all suitable
planes for handling scan-out capable client buffers.
We go over it twice: once to construct it and once to pick-and-choose a
suitable plane based its highest zpos position.
In order to maintain the view order correctly we track current zpos
value being applied to the plane state and use it when trying to place
a view into a plane.
Pass the computed zpos value to be applied to the plane state.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
This is based on the assumption that overlays are in between cursor and
primary plane and it is required to be able to assign views to planes,
even if the driver doesn't not expose such property.
As we hard-code them as immutable the commit part would not need any
further modifications.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Functional no change, as nobody makes use of it. Only apply the zpos
value if the zpos property is mutable (that is, zpos_max and zpos_min
are not the same).
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Due to an error in driving GitLab, this commit erroneously contained the
entirety of !267 (zpos support in the KMS backend) squashed into one
single commit, pushed into master.
In order to keep the history clean, this is being reverted; a rebased
version of !267 with the clear individual commits which were already
present will be applied in its place.
This reverts commit 95e3b0deae.
The remoting plugin currently has a set_gbm_format() hook, which accepts
GBM_FORMAT_* tokens from the host to set as a supported format.
GBM_FORMAT_* values are strictly aliased with DRM_FORMAT_*.
In order to avoid an extra unnecessary dependency from the remoting
plugin on GBM, switch to using the formats from libdrm instead.
This fixes a compile error seen when the remoting plugin is enabled:
../remoting/remoting-plugin.c:39:10: fatal error: gbm.h: No such file or directory
39 | #include <gbm.h>
| ^~~~~~~
compilation terminated.
The error was caused by not having any dependency at all on GBM from
the remoting backend, which is fixed here by adding a new dependency on
the libdrm headers for drm_fourcc.h.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Use exec to make sure the direct child process of weston-launch is
weston. This makes sure that signal delivery (SIGINT/SIGTERM) is
properly forwarded to weston.
Fixes ff3230952a ("weston-launch: Run weston in the user login shell")
Signed-off-by: Stefan Agner <stefan@agner.ch>
pending subscription
It limits to scope name to an exact match.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This fixes the situation where the same logger scope is passed multiple
times and the timestamp is being sent before the log mesasge.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Jeffy Chen
Olivier Fourdan
Pekka Paalanen
Marius Vlad
Eero Tamminen
Nicholas Niro
Drew DeVault
Daniel Stone
Marius Vlad
Stefan Agner