For views which cover the entire output, we always attempt to place them
on the primary plane, to avoid a situation where we place a fullscreen
view into an overlay plane and then have to disable the primary plane,
which doesn't always work.
Move this check earlier, so we don't consider overlay planes to be
candidates for fullscreen views. This check should be changed in future
to only filter for opaque views, but that's for another time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We shouldn't get down into trying to place a view on a cursor plane if
these checks are not met, so change them to asserts rather than early
returns.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we introduced support for variable zpos, we did so by filtering the
list of acceptable planes and then creating a separate zpos-ordered
list. Now that the planes are already zpos-sorted in the backend list,
and we have more early filtering, we can replace this with a single
plane-list walk.
Signed-off-by: Daniel Stone <daniels@collabora.com>
For better or worse, cursor planes can only be used by uploaded SHM
buffers right now, so ignore them when we're calculating the acceptable
plane mask for client dmabufs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we're in renderer-only mode, we can only use the renderer and the
cursor plane. Don't even try to import client buffers as it makes no
sense.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we have a SHM buffer, it can only go into a cursor plane - and only
then if it's of the right format.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Each output is hardcoded to the use of a single 'special' (primary or
cursor) plane; make sure we don't try to steal them from other outputs
which might not be happy to discover that we've taken it off them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
GBM is how we import all our client content into DRM FBs, so don't try
anything other than renderer-only without it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
It's possible to write this with a few less twisty special cases. Tested
manually with a randomly-distributed input tree as well as manually
trying to hit special cases around first/last entries.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This ensures that users that previously set the option explicitly will also have
a chance to notice the deprecation.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
weston-launch will be removed in a future release as this feature has
been offloaded to libseat and seatd-launch. Print an early deprecation
warning to give existing users time to migrate.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Transforming the scanout damage by the zoom will result in rectangles
outside of the display, and some with negative co-ordinates. This makes
at least some drivers unhappy (tested on vmware), and the page flip fails,
and weston hangs indefinitely.
Clip the damage to the output so we don't fall down.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Rename the build option to "deprecated-backend-fbdev" so that a
previously configured build dir doesn't retain the old setting.
This is consistent with the existing "deprecated-wl-shell" option.
Make the option default to "false".
Print a warning when fbdev is force-enabled.
Signed-off-by: Simon Ser <contact@emersion.fr>
References: https://gitlab.freedesktop.org/wayland/weston/-/issues/581
The invariant is clearly documented in code comments, but the code
failed to ensure it in all cases. Fix it.
There is one very specific protocol sequence triggered by a development
version of the Wine Wayland driver when Chrome (win64 app) is switched
from window to fullscreen and then back by pressing F11 key. The switch
back triggered
weston: ../libweston/color.c:217: weston_paint_node_ensure_color_transform: Assertion 'it->surf_xform_valid == false' failed
For some reason, that specific protocol sequence causes
weston_compositor_build_view_list() to create a transient second view
for a sub-surface. In the Chrome traces, I have seen that happen twice
per run. The first time it works, the old view gets immediately
destroyed. The second time (during un-fullscreening) a new transient
view is create and then it fails the invariant check.
The fix is in weston_paint_node_create() which is supposed to ensure the
invariant. However, it went through the (new) view's paint node list,
which will not contain paint nodes from other views. In hindsight this
is an obvious bug, but perhaps all views having exactly one associated
surface each somehow confused the author. Since the invariant is about
surface+output, go through the surface's paint node list instead. That
list contains all the relevant paint nodes by definition.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/568
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Commit 0e4f097d broke opaque regions, and since then weston will waste
time rendering occluded areas.
I think this is because we're taking the intersection of the opaque
and scissor regions even when the scissor region isn't enabled.
An easy test is to turn on triangle fan debugging with the gl renderer,
then run weston-simple-damage and move another opaque application such as
weston-terminal over it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Leak found running drm-smoke-test with ASan.
Do not forget to free the launcher before returning when we can't open
the launcher fd. Also, just set 'out = launcher' after all error paths,
otherwise we give the caller a stale pointer.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
weston_touch_destroy(), which is called from weston_seat_release(),
asserts that all its touch devices have been destroyed. The Wayland
backend currently destroys the touch devices ... immediately after
calling weston_seat_release().
Invert the ordering so that touch devices are destroyed first and we
don't trip over the assert.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When EGL initialization fails (failure to create a GLES3 or GLES2
context) we will end up calling gbm_device_destroy() twice, once
in init_egl() and once in the drm_backend_create() error path.
Given that we should also take care of properly destroying the gbm
device when we don't have any inputs for instance, mark the gbm device
as NULL to avoid calling gbm_device_destroy() once more when destroying
the DRM-backend.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Replaces potential corruption signal emit call sites with the more safer
weston_signal_emit_mutable().
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
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>
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>
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>
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>
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>
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>
Daniel Stone
Kenny Levinsen
Derek Foreman
Simon Ser
Pekka Paalanen
Leandro Ribeiro
Marius Vlad
Alexandros Frantzis
Scott Anderson