This fixes the following weston_view leak at compositor shutdown:
#0 0x7f4250247987 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f424fd37aa3 in zalloc ../include/libweston/zalloc.h:38
#2 0x7f424fd3a05f in weston_view_create ../libweston/compositor.c:386
#3 0x7f423be7be6a in weston_desktop_surface_create_desktop_view ../libweston-desktop/surface.c:364
#4 0x7f423be7c0a8 in weston_desktop_surface_create_view ../libweston-desktop/surface.c:404
#5 0x7f423beae91d in desktop_surface_added ../desktop-shell/shell.c:2273
#6 0x7f423be77db1 in weston_desktop_api_surface_added ../libweston-desktop/libweston-desktop.c:138
#7 0x7f423be80c73 in weston_desktop_xdg_toplevel_ensure_added ../libweston-desktop/xdg-shell.c:362
#8 0x7f423be8207a in weston_desktop_xdg_toplevel_committed ../libweston-desktop/xdg-shell.c:697
#9 0x7f423be84d45 in weston_desktop_xdg_surface_committed ../libweston-desktop/xdg-shell.c:1374
#10 0x7f423be7b382 in weston_desktop_surface_surface_committed ../libweston-desktop/surface.c:174
#11 0x7f424fd378a6 in wl_signal_emit /home/mvlad/install-amd64/include/wayland-server-core.h:481
#12 0x7f424fd510e2 in weston_surface_commit_state ../libweston/compositor.c:4062
#13 0x7f424fd51161 in weston_surface_commit ../libweston/compositor.c:4068
#14 0x7f424fd516ef in surface_commit ../libweston/compositor.c:4146
#15 0x7f424fb597e9 (/usr/lib/x86_64-linux-gnu/libffi.so.8+0x77e9)
With commit 'libweston, desktop-shell: Add a wrapper for weston_surface
reference' we've removed an explicit weston_view_destroy() call due to a
UAF which would've happen if we had close animations enabled, upon
terminating a client. In that patch I've incorrectly wrote this happened
when animations are off, but in fact it happened when they're on, see the
following trace:
READ of size 8 at 0x616000026498 thread T0
#0 0x7f757fba8797 in weston_signal_emit_mutable ../shared/signal.c:52
#1 0x7f757fb4bba1 in weston_view_destroy ../libweston/compositor.c:2269
#2 0x7f756bca89c0 in desktop_shell_destroy_surface ../desktop-shell/shell.c:275
#3 0x7f756bcb379e in fade_out_done_idle_cb ../desktop-shell/shell.c:2228
#4 0x7f757faec1da in wl_event_loop_dispatch_idle ../src/event-loop.c:969
#5 0x7f757faec31d in wl_event_loop_dispatch ../src/event-loop.c:1032
#6 0x7f757faea114 in wl_display_run ../src/wayland-server.c:1408
#7 0x7f757ff777ba in wet_main ../compositor/main.c:3589
#8 0x55f765c8d17d in main ../compositor/executable.c:33
#9 0x7f757fd997fc in __libc_start_main ../csu/libc-start.c:332
#10 0x55f765c8d099 in _start (/home/mvlad/install-amd64/bin/weston+0x1099)
0x616000026498 is located 24 bytes inside of 608-byte region [0x616000026480,0x6160000266e0)
freed by thread T0 here:
#0 0x7f758004c4d7 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
#1 0x7f757fb4bdc8 in weston_view_destroy ../libweston/compositor.c:2295
#2 0x7f757fb4c14d in weston_surface_unref ../libweston/compositor.c:2334
#3 0x7f756bca898b in desktop_shell_destroy_surface ../desktop-shell/shell.c:273
#4 0x7f756bcb379e in fade_out_done_idle_cb ../desktop-shell/shell.c:2228
#5 0x7f757faec1da in wl_event_loop_dispatch_idle ../src/event-loop.c:969
This patch re-introduces it to avoid leaking the view upon compositor
shutdown, but it does it in tandem with weston_desktop_surface_unlink_view(),
(which was added in a later patch) and before weston_surface_unref() call.
This way we should be safe to terminate/close clients with additional views
created by libweston-desktop (pop-ups), but also in other different situations.
Verified it in the following circumstances:
- terminating a client with close animation on
- terminating a client with close animations off
- shutting down the compositor with clients running, with and
without close animations
- terminating top-level clients with additional pop-ups with both with
and without close animations
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit ab42159bf3)
This documents the fact that other views are handled implictly by
libweston-desktop, and we shouldn't attempt to destroy indiscriminately
views that aren't created by desktop-shell.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 299f87f073)
This patch fixes the following trace:
#0 0x7f07d1bcecfa in weston_desktop_surface_get_surface ../libweston-desktop/surface.c:585
#1 0x7f07d1bfc9b8 in move_grab_motion ../desktop-shell/shell.c:1499
#2 0x7f07e539f841 in notify_motion ../libweston/input.c:1794
#3 0x7f07e1e8ace4 in handle_pointer_motion ../libweston/libinput-device.c:132
#4 0x7f07e1e8cad5 in evdev_device_process_event ../libweston/libinput-device.c:535
#5 0x7f07e1e89311 in udev_input_process_event ../libweston/libinput-seat.c:208
#6 0x7f07e1e8932f in process_event ../libweston/libinput-seat.c:218
#7 0x7f07e1e8935f in process_events ../libweston/libinput-seat.c:228
#8 0x7f07e1e8940a in udev_input_dispatch ../libweston/libinput-seat.c:239
#9 0x7f07e1e89437 in libinput_source_dispatch ../libweston/libinput-seat.c:249
#10 0x7f07e53122b1 in wl_event_loop_dispatch ../src/event-loop.c:1027
#11 0x7f07e5310114 in wl_display_run ../src/wayland-server.c:1408
#12 0x7f07e579c7ba in wet_main ../compositor/main.c:3589
#13 0x555611d6b17d in main ../compositor/executable.c:33
#14 0x7f07e55be7fc in __libc_start_main ../csu/libc-start.c:332
#15 0x555611d6b099 in _start (/home/mvlad/install-amd64/bin/weston+0x1099)
A highly unlikely, but still valid operation, is to close/destroy the
window while still having it grabbed and moved around, basically having
an in-flight destruction of grabbed moving window. Another situation
would be that the client terminates abruptly (crashing for instance),
while being dragged which might take down the compositor.
This could happen for both touch/pointer grab operations and could cause
a NULL pointer access while accessing desktop_surface when being used
to retrieve the underlying weston_surface.
With this patch we check for a valid desktop_surface and return early
if that's not the case.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit d03f01377a)
Moving weston_desktop_surface_unlink_view() to
desktop_shell_destroy_surface() makes sure we don't leak the underlying
weston_desktop_view when tearing/shutting down the compositor.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit c41cdcabb4)
No functional change. Makes it obvious that we also call
weston_layer_fini().
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit be5b6f9cdc)
Creates a distinct view, separated from the one created by
libweston-desktop, in order to avoid a potential ownership fight with
libweston-desktop upon destroying the view. Upon weston_desktop_surface
destruction, libweston-desktop inflicts damage on the view it creates,
so we need the view to be alive at that time.
This wasn't such an issue before because we had different destruction paths but
with commit 'desktop-shell: Do not leave views in layers upon shell
destruction' all of the destruction paths now land in the same spot
+ handle compositor tear down.
Note as we still use the same weston_surface we'll keep the previous
construct where we were taking a reference to keep it alive.
The original view is destroyed when releasing the ownership, while for
the view created in this patch we handle the destruction directly upon
compositor tear down.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 9cf602840d)
Similar to how we do it with drm_fb ref counts, increase a reference
count and return the same object.
Plug-in in desktop-shell when we map up the view in order to survive a
weston_surface destruction.
Astute readers will notice that this patch removes weston_view_destroy()
while keeping the balance between removing and adding a
weston_surface_unref() call in desktop_shell_destroy_surface().
The reason is to let weston_surface_unref() handle destruction on its
own. If multiple references are taken, then weston_surface_unref()
doesn't destroy the view, it just decreases the reference, with
a latter call to weston_surface_unref() to determine if the view
should be destroyed as well. This situation happens if we have
close animation enabled, were we have more than one reference taken: one
when mapping the view/surface and when when the surface itself was created,
(what we call, a weak reference).
If only a single reference is taken (for instance if we don't have close
animations enabled) then this weston_surface_unref()
call is inert as that reference is not set-up, leaving libweston to
handle the view destruction.
Following that with a weston_view_destroy() explicit call would cause a
UAF as the view was previous destroyed by a weston_surface_unref() call.
A side-effect of not keeping the weston_view_destroy() call would
happen when tearing down the compositor. If close animations are enabled,
weston_surface_unref() would not destroy the view, and because
weston_view_destroy() no longer exists, we would still have the
view in the other layers by the time we check-up if layers
have views present.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit bd8314078d)
While the original patch was adding a weston_surface_ref() wrapper, this
patch doesn't add any wrapper to avoid a minor version bump, but instead
achieves a similar outcome by inlining the wrapper version being added
by the original commit.
Further more, as the original patch was dependent on another patch,
any mention of weston_surface_unref() in the commit description
should instead be replaced with weston_surface_destroy().
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Calling weston_surface_destroy() one time too many could be a sign we
haven't correctly increased the ref count for it.
Also, if we don't have a surface being passed, do no attempt to
use it.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit d3ed2eb345)
Test different scenarios where child subsurfaces of unmapped
subsurfaces would get mapped. This test will fail in various
ways without the commit
"libweston/compositor: Do not map subsurfaces without buffer"
Also try to test potential regressions of that patch.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit c83f0a1539)
We can end in `subsurface_committed()` in different scenarios
without the surface having an attached buffer. While setting
the mapped state to `true` in that case doesn't matter for
that (sub)surface itself, it triggers its own child subsurfaces
to get mapped when they shouldn't.
Closes https://gitlab.freedesktop.org/wayland/weston/-/issues/426
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit 8b04534c76)
Changing `wl_surface_damage()` to `wl_surface_damage_buffer()`
should not have an effect on the existing tests.
The new test will fail without the commit
"libweston/compositor: Cache buffer damage for synced subsurfaces"
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit dc3b349325)
The spec states:
> Because buffer transformation changes and damage requests may be
> interleaved in the protocol stream, it is impossible to determine
> the actual mapping between surface and buffer damage until
> wl_surface.commit time. Therefore, compositors wishing to take both
> kinds of damage into account will have to accumulate damage from the
> two requests separately and only transform from one to the other after
> receiving the wl_surface.commit.
For subsurfaces in sync mode, arguably the same is the case until the
cached state gets applied eventually. Thus, in order to keep complexity
to a sane level, just accumulate buffer damage and convert it only
when the cached state gets applied.
This mirrors how other compositors like Mutter implement cached damage
and what the spec arguably should demand.
Closes https://gitlab.freedesktop.org/wayland/weston/-/issues/446
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit 933290e6ea)
In multiple output cases, finding the succesor from the inactive layer
might result in picking the wrong view when there are multiple views
being stacked in the inactive layer. This adds two additional checks to
favor views on the same output as the one being destroyed/removed.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit f3221832c5)
This adds an additional check to make sure the current focus surface
is on the same output as the surface that is going to be activated.
This is necessary in order to avoid placing the currently focused one in
the inactive layer, which shouldn't happen in situations where the new
surface is going to be placed on a different output than the currently
focused one.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit f3ad593925)
Some applications would set-up the app_id after the initial commit
(without a buffer) which is too late to correctly assign the application
to the corresponding output set-up in the configuration file.
This patch fixes that by checking one more time, after a buffer has been
attached, if indeed there's an output with an app_id set.
Fixes: #469
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 8a1849db8a)
Instead of a meson option or hidden define, just run these checks always.
It is not Weston's style to add build options for specific asserts, and
currently weston's codebase is expected to always run with asserts
enabled.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
It is used in Mesa. Lets switch to it as well in order to provide
good examples and encourage proper API usage.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Compositors may choose to send multiple scanout or non-scanout
tranches. So instead of assuming that the first respective tranche
contains the format/modifier we're looking for, check all tranches.
While on it, make sure that in case a compositor sends scanout
tranches on the initial feedback, `pick_format_from_scanout_tranche()`
does not unintentionally pick `INITIAL_BUFFER_FORMAT`.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
It doesn't and can't build, because it depends on cairo-gl. We already
have simple-egl which shows how to use EGL/GLESv2 on Wayland.
Signed-off-by: Daniel Stone <daniels@collabora.com>
It's three planes, not two.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 8b167a1703 ("gl-renderer: Store EGL buffer state in weston_buffer")
There's just no good reason to do this.
The query entrypoints already tell us if we need to use
GL_TEXTURE_EXTERNAL_OES for a particular format/modifier. We also have
RGB -> YUV fallbacks which should be able to work well with TEXTURE_2D.
TEXTURE_EXTERNAL pessimises quite hard, forcing GPU-side reloads as well
as bad filtering. Allowing multi-planar formats to use TEXTURE_2D should
thus result in performance and quality improvements.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Now that we can pull everything we need from pixel-formats, go one step
further and reuse the same YUV format descriptors we use to emulate
dmabuf/EGLImage imports for SHM.
This eliminates all special-case YUV/SHM handling.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add a new hide_from_clients flag which, if set, specifies that the
format is only for internal information and processing, and should not
be advertised for clients.
This will be used for formats like R8 and GR88, which are not useful for
client buffers, but are used internally to implement YUV -> RGB
conversion.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We support this as an explicit YUV fallback path in gl-renderer's dmabuf
EGLImage import path, so might as well support it in the SHM path, given
it's just YUV420 with no subsampling.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we're doing partial uploads from SHM buffers, we need to use the
vertical subsampling factor rather than the horizontal for secondary
planes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We already had these with effective width and height, but they're useful
externally as well. Pull them out to a helper.
Signed-off-by: Daniel Stone <daniels@collabora.com>
'depth' isn't actually used to determine the bit depth of meaningful
components generally, but specifically to determine whether we can use
the legacy drmModeAddFB (pre-AddFB2) with those formats.
Rename the member to make it more clear what it's used for.
Signed-off-by: Daniel Stone <daniels@collabora.com>
pixel-formats already stores the gl_format, at least for single-planar
formats; use that instead of storing our own copies.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Instead of checking for each format whether we need compatibility
workarounds for GL implementations not supporting ES3.x or when
GL_EXT_texture_rg isn't present, have each format declare the ideal case
and fix it up later.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than checking all the pixel-format components which are currently
duplicated inside gl-renderer, just check for equality of the pixel
format itself, which will become useful as we remove some of the
duplicate content.
This means that the texture storage will now be reallocated when clients
switch between pixel formats which could've had compatible GL storage
(e.g. XRGB <-> ARGB) on the same surface. However this does not seem
like a case worth optimising, and simplifies the code somewhat.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We've got a nice shiny ARRAY_COPY macro, so use it rather than memcpy or
hand-unrolled assignments.
Signed-off-by: Daniel Stone <daniels@collabora.com>
FreeRDP has some features that start new threads and run
callback functions in them.
We need a way to punt work from these threads back to the
compositor thread.
Co-authored-by: Steve Pronovost <spronovo@microsoft.com>
Co-authored-by: Brenton DeGeer <brdegeer@microsoft.com>
Signed-off-by: Hideyuki Nagase <hideyukn@microsoft.com>
Signed-off-by: Steve Pronovost <spronovo@microsoft.com>
Signed-off-by: Brenton DeGeer <brdegeer@microsoft.com>
Log EGL features similar to how GL ES features are logged: listing just
the ones weston tests for.
This replaces some log messages from gl-renderer.c that become
redundant or belong with EGL better.
has_native_fence_sync and has_wait_sync are not logged, because missing
them already logs warnings.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Feels like this might be nice to log.
The failure case is not fatal, so say it's a warning only.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Marius Vlad
James Le Cuirot
Robert Mader
Derek Foreman
Daniel Stone
Hideyuki Nagase
Pekka Paalanen