The DRM backend uses changes in the cursor view memory address and
surface damage to detect when it needs to re-upload to a cursor plane
framebuffer.
However, when a cursor view is destroyed and then recreated, e.g., when
the pointer cursor surface is updated, the newly created view may have
the same memory address as the just destroyed one. If no new cursor
buffer is provided (because it was attached, committed and used
previously) when this address reuse occurs, then there also isn't any
updated surface damage and the backend doesn't update the cursor plane
framebuffer at all.
To fix this issue utilize the destroy signal to track when the cursor
view is destroyed, and clear the cached cursor_view value in drm_output.
After clearing the cached value, the next cursor view is always
considered new and thus uploaded to the plane properly.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
This reverts commit 81ef6d0ab3.
This also removes a bit from "tests: ensure color-lcms plugin loads".
Use of the shadow buffer is determined automatically based on
color transformations by the previous commit
"gl-renderer: use shadow framebuffer automatically".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This creates the FP16 shadow framebuffer automatically if the color
transformation from blending space to output space is not identity and
the backend does not claim to implement it on the renderer's behalf.
That makes the weston_output_set_renderer_shadow_buffer() API and
use-renderer-shadow weston.ini option obsolete.
To still cater for the one test that needs to enable the shadow
framebuffer in spite of not needing it for color correct blending, the
quirk it uses now also forces the shadow.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Compile time constants play an important role in keeping the shader
programs fast. Introduce an informal annotation to mark compile time
constants to make the shader code easier to reason with.
This will make much more sense once functions with compile time constant
parameters are added.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Trying to support GL ES 2.0 + extensions along with GL ES 3.0 for better
control is becoming too complicated fast. In this patch you see the
GL_RGBA vs. GL_RBA16F and GL_HALF_FLOAT vs. GL_HALF_FLOAT_OES paths.
More such cases will come, e.g. GL_RED_EXT vs. GL_R32F.
Make things simpler and require GL ES 3.0 +
GL_EXT_color_buffer_half_float for all color management related
functionality. If one doesn't have GL ES 3.0, all you lose is color
management.
Also, all extensions needed by color transformation operations are
gathered under one boolean flag instead of having a flag per extension,
again for simplicity.
This makes the GL ES extension handling much easier.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This reverts commit 36d699a164.
A different way to fix this same issue is the previous commit
"gl-renderer: do not unbind the context on output destroy"
which is needed for other reasons.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If we make EGL_NO_CONTEXT current, all following GL calls are
no-ops. This will be a problem when gl-renderer introduces
gl_renderer_color_transform containing GL textures and needs to destroy
them when weston_color_transform is destroyed. Mesa would print the the
warning that glDeleteTextures is no-op.
To fix this, keep our GL context current when destroying a GL output.
In case EGL_KHR_surfaceless_context is not available, we must use
dummy_surface.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This creates the color-lcms plugin that in the future will be using
Little CMS as the color matching module, processing ICC profiles, and
producing HDR tone mappings.
Right now, this new plugin is functionally equivalent to the no-op color
manager, except it already links to lcms2 and checks that the renderer
supports color operations.
Color-lcms is a libweston plugin that is loaded with explicit
weston_compositor API. This does not currently allow loading alternative
color manager plugins. External color manager plugins might be
considered in the future when the libweston APIs around color management
stabilize.
This libweston plugin uses the same build option as the old cms-static
Weston plugins, as they both need lcms2. The minimum version for lcms2
was chosen by what Debian Buster provides today and for no other reason.
This plugin intends to support the Wayland CM&HDR protocol extension and
hence sets supports_client_protocol to true. This will expose the
protocol extension to clients when it gets implemented.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is needed when the compositor produces any content internally:
- the lines in triangle fan debug
- the censoring color fill (unmet HDCP requirements)
Solid color surfaces do not need this special-casing because
weston_surface is supposed to carry color space information, which will
get used in gl_shader_config_init_for_view().
This makes sure the internally produced graphics fit in, e.g on a
monitor in HDR mode.
For now, just ensure there is an identity transformation. Actual
implementations in GL-renderer will follow later.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is needed when drawing anything internal directly to an output,
like the borders/decorations in a nested compositor setup. This makes
the assumption that the internal stuff starts in sRGB, which should be
safe. As borders are never blended with other content, this should also
be sufficient.
This patch is a reminder that that path exists, rather than a real
implementation. To be implemented when someone needs it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the blending space to monitor space color transform. It needs to
be implemented in the renderers, unless a backend sets
from_blend_to_output_by_backend = true, in which case the backend does
it and the renderer does not.
The intention is that from_blend_to_output_by_backend can be toggled
frame by frame to allow backends to react to dynamic change of output
color profile.
For now, renderers just assert that they don't need to do anything for
output color transform.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/467#note_814985
This starts building the framework required for implementing color
management.
The main new interface is struct weston_color_manager. This commit also
adds a no-op color manager implementation, which is used if no other
color manager is loaded. This no-op color manager simply provides
identity color transforms for everything, so that Weston keeps running
exactly like before.
weston_color_manager interface is incomplete and will be extended later.
Colorspace objects are not introduced in this commit. However, when
client content colorspace and output colorspace definitions are
combined, they will produce color transformations from client content to
output blending space and from output blending space to output space.
This commit introduces a placeholder struct for color transforms,
weston_color_transform. Objects of this type are expected to be heavy to
create and store, which is why they are designed to be shared as much as
possible, ideally making their instances unique. As color transform
description is intended to be generic in libweston core, renderers and
backends are expected to derive their own state for each transform
object as necessary. Creating and storing the derived state maybe be
expensive as well, more the reason to re-use these objects as much as
possible. E.g. GL-renderer might upload a 3D LUT into a texture and keep
the texture around. DRM-backend might create a KMS blob for a LUT and
keep that around.
As a color transform depends on both the surface and the output, a
transform object may need to be created for each unique pair of them.
Therefore color transforms are referenced from weston_paint_node. As
paint nodes exist for not just surface+output but surface+view+output
triplets, the code ensures that all paint nodes (having different view)
for the same surface+output have the same color transform state.
As a special case, if weston_color_transform is NULL, it means identity
transform. This short-circuits some checks and memory allocations, but
it does mean we use a separate member on weston_paint_node to know if
the color transform has been initialized or not.
Color transformations are pre-created at the weston_output
paint_node_z_order_list creation step. Currently the z order lists
contain all views globally, which means we populate color transforms we
may never need, e.g. a view is never shown on a particular output.
This problem should get fixed naturally when z order lists are
constructed "pruned" in the future: to contain only those paint nodes
that actually contribute to the output's image.
As nothing actually supports color transforms yet, both renderers and
the DRM-backend assert that they only get identity transforms. This
check has the side-effect that all surface-output pairs actually get a
weston_surface_color_transform_ref even though it points to NULL
weston_color_transform.
This design is inspired by Sebastian Wick's Weston color management
work.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A following patch will need the paint node in
gl_shader_config_init_for_view() for color transformations.
While passing the paint node through, rename the functions to be more
appropriate and get surface/view/output from the paint node.
This is a pure refactoring with no functional change.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A following patch will need the paint node in draw_view() for color
transformations.
While passing the paint node into draw_paint_node, also use the paint
node. This is a pure refactoring with no functional change.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add a regression test to verify that the cursor image is correctly
updated when setting a cursor surface with an already committed buffer
from a previous pointer entry, without recommitting a cursor buffer for
the current entry.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Store the pointer serial for events that provide one, so that it can be
used by tests to send requests that require it (e.g., setting the cursor
surface).
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
When setting a cursor surface, use the surface dimensions, instead of the
weston_surface buffer reference, to check if the surface has any
content. A weston_surface without any buffer reference may in fact
have a buffer which was committed in a previous pointer entry, dropped
by weston_surface and now held only internally by the renderer.
Without this fix, when a pointer enters a surface, the cursor image is
not correctly updated if we set a cursor surface with an already
committed buffer from a previous pointer entry, without recommitting the
cursor buffer for the current entry. This can be seen, for example, in
the experimental Wine Wayland driver which handles the cursor in a way
that leads to the following scenario:
Setup: cursor_surface.attach(buffer) & cursor_surface.commit()
On first wl_pointer.enter: pointer.set_cursor(cursor_surface)
compositor/renderer redraws
wl_pointer.leave
On second wl_pointer.enter: pointer.set_cursor(cursor_surface)
When handling the second pointer.set_cursor() request the current code
doesn't find a buffer attached to the cursor_surface (only the renderer
now has a reference to it), so it doesn't update the respective view for
the cursor.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
In commit d8e09afc9f ("tests: Convert ivi-shell-app-test.c to use
`weston_ini_setup`") the reference weston.ini for the ivi-shell was
removed, because it is not required by the test anymore.
The reference weston.ini still has value as an example for the ivi-shell
and how the ivi-shell-user-interface has to be configured. Retrieving
this information from the test case is not intuitive. Furthermore, the
file is still referenced by the ivi-shell/README, and the
configuration_data for generating the file was not fully removed.
Bring back the reference weston.ini for the ivi-shell and, while at it, cleanup
the configuration_data() to define only keys that are actually used in
weston.ivi.in.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Remove all the backend code to support drivers without universal planes.
From[1]:
"The code needed to support kernels where DRM does not support uiniversal
planes makes the DRM-backend a little more complicated, because it needs
to create fake planes for primary and cursor. The lifetimes of the fake
planes does not match the lifetime of "proper" planes, which is surprising."
And since the universal planes left the experimetal flag in 2014[2] it is
safe to remove the support now.
[1] https://gitlab.freedesktop.org/wayland/weston/-/issues/427
[2] https://cgit.freedesktop.org/drm/drm-tip/commit/?id=c7dbc6c9ae5c3baa3be755a228a349374d043b5b
Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Memleak found by ASAN:
Direct leak of 258 byte(s) in 8 object(s) allocated from:
#0 0x7f3eedb6e817 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.6+0x57817)
#1 0x55821ce5e6a5 in stream_alloc ../clients/weston-debug.c:94
#2 0x55821ce5e974 in stream_find ../clients/weston-debug.c:128
#3 0x55821ce5eb15 in debug_advertise ../clients/weston-debug.c:157
#4 0x7f3eed7b4d1c (/usr/lib/x86_64-linux-gnu/libffi.so.7+0x6d1c)
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Memleak found by ASAN:
Direct leak of 21 byte(s) in 1 object(s) allocated from:
#0 0x7fe7a917fe8f in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xa9e8f)
#1 0x7fe7a9129874 (/usr/lib/x86_64-linux-gnu/libasan.so.6+0x53874)
#2 0x7fe7a5a23469 in weston_wm_window_read_properties ../xwayland/window-manager.c:574
#3 0x7fe7a5a28d3b in weston_wm_handle_map_request ../xwayland/window-manager.c:1178
#4 0x7fe7a5a31660 in weston_wm_handle_event ../xwayland/window-manager.c:2291
#5 0x7fe7a8c261a1 in wl_event_loop_dispatch ../src/event-loop.c:1027
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Memleak found by ASAN:
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fe7a917fe8f in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xa9e8f)
#1 0x7fe7a5a40736 in theme_create ../shared/cairo-util.c:419
#2 0x7fe7a5a3363c in weston_wm_create ../xwayland/window-manager.c:2619
#3 0x7fe7a5a2017e in weston_xwayland_xserver_loaded ../xwayland/launcher.c:313
#4 0x7fe7a90b4d14 in handle_sigusr1 ../compositor/xwayland.c:57
#5 0x7fe7a8c2585d in wl_event_source_signal_dispatch ../src/event-loop.c:685
#6 0x7ffcdb04ef6f ([stack]+0x1df6f)
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Fix an issue where the keyboard leds will go out of sync when a new
keyboard is connected.
The issue can be easily reproduced by connecting two keyboards, enabling
caps lock, and reconnecting one of the keyboards. Without the patch the
leds on both keyboards will turn off while the actual caps lock state
will stay enabled.
Signed-off-by: Samu Nuutamo <samu.nuutamo@gmail.com>
Fixes ASan leak:
Direct leak of 80 byte(s) in 1 object(s) allocated from:
#0 0x7fe7791f4518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fe779100892 in zalloc ../../git/wayland/src/wayland-private.h:232
#2 0x7fe779100892 in proxy_create ../../git/wayland/src/wayland-client.c:422
#3 0x7fe779100ede in create_outgoing_proxy ../../git/wayland/src/wayland-client.c:651
#4 0x7fe779100ede in wl_proxy_marshal_array_constructor_versioned ../../git/wayland/src/wayland-client.c:736
#5 0x7fe779101226 in wl_proxy_marshal_constructor ../../git/wayland/src/wayland-client.c:834
#6 0x56428c9bc578 in zwp_input_panel_v1_get_input_panel_surface protocol/input-method-unstable-v1-client-protocol.h:678
#7 0x56428c9c0bbb in set_toplevel ../../git/weston/clients/keyboard.c:965
#8 0x56428c9c0c8d in display_output_handler ../../git/weston/clients/keyboard.c:980
#9 0x56428c9ddead in display_handle_mode ../../git/weston/clients/window.c:5700
#10 0x7fe7786668ed in ffi_call_unix64 (/lib/x86_64-linux-gnu/libffi.so.6+0x68ed)
#11 0x7fe7786662be in ffi_call (/lib/x86_64-linux-gnu/libffi.so.6+0x62be)
#12 0x7fe779103fac in wl_closure_invoke ../../git/wayland/src/connection.c:1018
#13 0x7fe779100a48 in dispatch_event ../../git/wayland/src/wayland-client.c:1452
#14 0x7fe779101e43 in dispatch_queue ../../git/wayland/src/wayland-client.c:1598
#15 0x7fe779101e43 in wl_display_dispatch_queue_pending ../../git/wayland/src/wayland-client.c:1840
#16 0x56428c9e031c in handle_display_data ../../git/weston/clients/window.c:6211
#17 0x56428c9e2147 in display_run ../../git/weston/clients/window.c:6553
#18 0x56428c9c1559 in main ../../git/weston/clients/keyboard.c:1053
#19 0x7fe77885e09a in __libc_start_main ../csu/libc-start.c:308
#20 0x56428c9bc029 in _start (/home/pq/build/weston-meson/clients/weston-keyboard+0x19029)
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This fixes ASan report:
SUMMARY: AddressSanitizer: 151360 byte(s) leaked in 451 allocation(s).
The leaks can be observed if you let weston-desktop-shell start fully
before shutting down Weston. Many simple test suite tests are too fast
to hit this, or do not even use desktop-shell.
This clean-up code is copied from keyboard_handle_keymap().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes ASan reported leaks:
Direct leak of 256 byte(s) in 1 object(s) allocated from:
#0 0x7f8266f2d330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x7f8266c8589a (/lib/x86_64-linux-gnu/libpixman-1.so.0+0x5089a)
#2 0x7f8266c4ea77 (/lib/x86_64-linux-gnu/libpixman-1.so.0+0x19a77)
#3 0x55fa7818f8e8 in load_png ../../git/weston/shared/image-loader.c:297
#4 0x55fa7819039e in load_image ../../git/weston/shared/image-loader.c:423
#5 0x55fa78187b3e in load_cairo_surface ../../git/weston/shared/cairo-util.c:354
#6 0x55fa7815ff8a in background_draw ../../git/weston/clients/desktop-shell.c:779
#7 0x55fa7817b2c2 in widget_redraw ../../git/weston/clients/window.c:4520
#8 0x55fa7817b831 in surface_redraw ../../git/weston/clients/window.c:4578
#9 0x55fa7817b9a7 in idle_redraw ../../git/weston/clients/window.c:4607
#10 0x55fa78184ea4 in display_run ../../git/weston/clients/window.c:6527
#11 0x55fa781646fb in main ../../git/weston/clients/desktop-shell.c:1556
#12 0x7f826659709a in __libc_start_main ../csu/libc-start.c:308
#13 0x55fa7815c0a9 in _start (/home/pq/build/weston-meson/clients/weston-desktop-shell+0x120a9)
Indirect leak of 8024 byte(s) in 1 object(s) allocated from:
#0 0x7f8266f2d330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x55fa7818f5e7 in load_png ../../git/weston/shared/image-loader.c:275
#2 0x55fa7819039e in load_image ../../git/weston/shared/image-loader.c:423
#3 0x55fa78187b3e in load_cairo_surface ../../git/weston/shared/cairo-util.c:354
#4 0x55fa7815ff8a in background_draw ../../git/weston/clients/desktop-shell.c:779
#5 0x55fa7817b2c2 in widget_redraw ../../git/weston/clients/window.c:4520
#6 0x55fa7817b831 in surface_redraw ../../git/weston/clients/window.c:4578
#7 0x55fa7817b9a7 in idle_redraw ../../git/weston/clients/window.c:4607
#8 0x55fa78184ea4 in display_run ../../git/weston/clients/window.c:6527
#9 0x55fa781646fb in main ../../git/weston/clients/desktop-shell.c:1556
#10 0x7f826659709a in __libc_start_main ../csu/libc-start.c:308
#11 0x55fa7815c0a9 in _start (/home/pq/build/weston-meson/clients/weston-desktop-shell+0x120a9)
from the command
ASAN_OPTIONS=fast_unwind_on_malloc=0,malloc_context_size=50 \
LSAN_OPTIONS=suppressions=/home/pq/git/weston/.gitlab-ci/leak-sanitizer.supp \
./tests/test-viewporter test_viewporter_bad_source_rect
by recording the pixman image as user data so it can be freed when the
surface is destroyed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
== 8 bytes in 1 blocks are definitely lost in loss record 4 of 71
== at 0x48450F8: malloc (vg_replace_malloc.c:309)
== by 0x500213F: strdup (strdup.c:42)
== by 0x40A57F: display_handle_geometry (in weston-desktop-shell)
== by 0x4864D27: ffi_call_SYSV (in libffi.so.6.0.4)
== by 0x4865697: ffi_call (in libffi.so.6.0.4)
== by 0x4880E07: wl_closure_invoke (connection.c:935)
== by 0x487DD73: dispatch_event.isra.5 (wayland-client.c:1310)
== by 0x487EF87: dispatch_queue (wayland-client.c:1456)
== by 0x487EF87: wl_display_dispatch_queue_pending (wayland-client.c:1698)
== by 0x4104E3: handle_display_data (in weston-desktop-shell)
== by 0x40FE8F: display_run (in weston-desktop-shell)
== by 0x405AB3: main (in weston-desktop-shell)
Signed-off-by: Lujin Wang <luwang@nvidia.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This fixes the following ASan detected leaks:
Direct leak of 88 byte(s) in 1 object(s) allocated from:
#0 0x7f8c3455f330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x7f8c33c60906 in wl_event_loop_add_timer ../../git/wayland/src/event-loop.c:571
#2 0x7f8c2ff98f46 in shell_fade_init ../../git/weston/desktop-shell/shell.c:4211
#3 0x7f8c2ff9e1da in wet_shell_init ../../git/weston/desktop-shell/shell.c:5266
#4 0x7f8c3443ede5 in wet_load_shell ../../git/weston/compositor/main.c:956
#5 0x7f8c3444fdb9 in wet_main ../../git/weston/compositor/main.c:3434
#6 0x55878ad3bfc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#7 0x55878ad3f9fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#8 0x55878ad2fbd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46
#9 0x55878ad2fc58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48
#10 0x55878ad3ffaf in main ../../git/weston/tests/weston-test-runner.c:661
#11 0x7f8c340b409a in __libc_start_main ../csu/libc-start.c:308
#12 0x55878ad2f769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769)
Indirect leak of 856 byte(s) in 1 object(s) allocated from:
#0 0x7f8c3455f518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7f8c33c99b73 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7f8c33c9cfb1 in weston_surface_create ../../git/weston/libweston/compositor.c:574
#3 0x7f8c2ff98230 in shell_fade_create_surface_for_output ../../git/weston/desktop-shell/shell.c:4059
#4 0x7f8c2ff98df6 in shell_fade_init ../../git/weston/desktop-shell/shell.c:4202
#5 0x7f8c2ff9e1da in wet_shell_init ../../git/weston/desktop-shell/shell.c:5266
#6 0x7f8c3443ede5 in wet_load_shell ../../git/weston/compositor/main.c:956
#7 0x7f8c3444fdb9 in wet_main ../../git/weston/compositor/main.c:3434
#8 0x55878ad3bfc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#9 0x55878ad3f9fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#10 0x55878ad2fbd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46
#11 0x55878ad2fc58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48
#12 0x55878ad3ffaf in main ../../git/weston/tests/weston-test-runner.c:661
#13 0x7f8c340b409a in __libc_start_main ../csu/libc-start.c:308
#14 0x55878ad2f769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769)
Indirect leak of 608 byte(s) in 1 object(s) allocated from:
#0 0x7f8c3455f518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7f8c33c99b73 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7f8c33c9bed5 in weston_view_create ../../git/weston/libweston/compositor.c:365
#3 0x7f8c2ff98251 in shell_fade_create_surface_for_output ../../git/weston/desktop-shell/shell.c:4063
#4 0x7f8c2ff98df6 in shell_fade_init ../../git/weston/desktop-shell/shell.c:4202
#5 0x7f8c2ff9e1da in wet_shell_init ../../git/weston/desktop-shell/shell.c:5266
#6 0x7f8c3443ede5 in wet_load_shell ../../git/weston/compositor/main.c:956
#7 0x7f8c3444fdb9 in wet_main ../../git/weston/compositor/main.c:3434
#8 0x55878ad3bfc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#9 0x55878ad3f9fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#10 0x55878ad2fbd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46
#11 0x55878ad2fc58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48
#12 0x55878ad3ffaf in main ../../git/weston/tests/weston-test-runner.c:661
#13 0x7f8c340b409a in __libc_start_main ../csu/libc-start.c:308
#14 0x55878ad2f769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769)
They were found with:
ASAN_OPTIONS=fast_unwind_on_malloc=0,malloc_context_size=50 \
LSAN_OPTIONS=suppressions=/home/pq/git/weston/.gitlab-ci/leak-sanitizer.supp \
./tests/test-viewporter test_viewporter_double_create
Turns out shell_destroy() had an open-coded and outdated copy of the
tear-down sequence, so fixing the leaks in only handle_output_destroy()
was not enough.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Most other places call a variable like this 'shell_output', so let's do
that here too. The old name was really confusing.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Plugs ASan reported leaks:
Direct leak of 88 byte(s) in 1 object(s) allocated from:
#0 0x7f338f70a518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7f338afe22f3 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7f338afe3cc2 in weston_desktop_xwayland_init ../../git/weston/libweston-desktop/xwayland.c:410
#3 0x7f338afdbaef in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:87
#4 0x7f338b148d39 in wet_shell_init ../../git/weston/desktop-shell/shell.c:5224
#5 0x7f338f5e9de5 in wet_load_shell ../../git/weston/compositor/main.c:956
#6 0x7f338f5fadb9 in wet_main ../../git/weston/compositor/main.c:3434
#7 0x5646d2392fc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#8 0x5646d23969fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#9 0x5646d2386bd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46
#10 0x5646d2386c58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48
#11 0x5646d2396faf in main ../../git/weston/tests/weston-test-runner.c:661
#12 0x7f338f25f09a in __libc_start_main ../csu/libc-start.c:308
#13 0x5646d2386769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769)
Indirect leak of 152 byte(s) in 1 object(s) allocated from:
#0 0x7f338f70a518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7f338afdb811 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7f338afdb92d in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:65
#3 0x7f338b148d39 in wet_shell_init ../../git/weston/desktop-shell/shell.c:5224
#4 0x7f338f5e9de5 in wet_load_shell ../../git/weston/compositor/main.c:956
#5 0x7f338f5fadb9 in wet_main ../../git/weston/compositor/main.c:3434
#6 0x5646d2392fc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#7 0x5646d23969fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#8 0x5646d2386bd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46
#9 0x5646d2386c58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48
#10 0x5646d2396faf in main ../../git/weston/tests/weston-test-runner.c:661
#11 0x7f338f25f09a in __libc_start_main ../csu/libc-start.c:308
#12 0x5646d2386769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769)
Indirect leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7f338f70a518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7f338afdc5ae in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7f338afdc89e in weston_desktop_client_create ../../git/weston/libweston-desktop/client.c:108
#3 0x7f338afe3d2a in weston_desktop_xwayland_init ../../git/weston/libweston-desktop/xwayland.c:415
#4 0x7f338afdbaef in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:87
#5 0x7f338b148d39 in wet_shell_init ../../git/weston/desktop-shell/shell.c:5224
#6 0x7f338f5e9de5 in wet_load_shell ../../git/weston/compositor/main.c:956
#7 0x7f338f5fadb9 in wet_main ../../git/weston/compositor/main.c:3434
#8 0x5646d2392fc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#9 0x5646d23969fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#10 0x5646d2386bd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46
#11 0x5646d2386c58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48
#12 0x5646d2396faf in main ../../git/weston/tests/weston-test-runner.c:661
#13 0x7f338f25f09a in __libc_start_main ../csu/libc-start.c:308
#14 0x5646d2386769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769)
Oops.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Clean up after each test to avoid ASan reporting leaks.
At few points client_roundtrip() is replaced with client_destroy()
because the latter does a final roundtrip anyway.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
expect_protocol_error() ensures that the connection has failed in the
expected way. To satisfy ASan leak detection, we still need to tear down
everything, including call client_destroy().
client_destroy() needs to check that tear-down does not cause protocol
errors, so it does one last roundtrip that checks that is succeeds. But
if the connection is already down in an expected way, this roundtrip
cannot succeed and must be skipped.
Also moves the roundtrip under 'if (wl_display)', assuming the 'if' is
there for a reason - but obviously that reason was never used as it
would have crashed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
ASan will detect leaks also outside of the code we build, and sometimes
that external code leaks and we cannot work around it. Then we need to
suppress the leak reports to make our own ASan testing succeed. This
commit only introduces the suppressions file, making use of it CI is for
another time. This file is useful for manual targeted testing as below.
Start by suppressing two functions what weston-keyboard client ends up
calling, suppressing leak reports like these:
Indirect leak of 96 byte(s) in 3 object(s) allocated from:
#0 0x7fc109c3d518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fc109083d18 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x20d18)
#2 0x7fc1090849a7 in FcPatternDuplicate (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x219a7)
#3 0x7fc109adf93e (/lib/x86_64-linux-gnu/libcairo.so.2+0xbb93e)
#4 0x7fc109adfc8d (/lib/x86_64-linux-gnu/libcairo.so.2+0xbbc8d)
#5 0x7fc109aa02e7 in cairo_toy_font_face_create (/lib/x86_64-linux-gnu/libcairo.so.2+0x7c2e7)
#6 0x7fc109aa856c in cairo_select_font_face (/lib/x86_64-linux-gnu/libcairo.so.2+0x8456c)
#7 0x5603cb49a06a in redraw_handler ../../git/weston/clients/keyboard.c:378
#8 0x5603cb4b506b in widget_redraw ../../git/weston/clients/window.c:4520
#9 0x5603cb4b55da in surface_redraw ../../git/weston/clients/window.c:4578
#10 0x5603cb4b5750 in idle_redraw ../../git/weston/clients/window.c:4607
#11 0x5603cb4bebe3 in display_run ../../git/weston/clients/window.c:6525
#12 0x5603cb49e55d in main ../../git/weston/clients/keyboard.c:1054
#13 0x7fc1092a709a in __libc_start_main ../csu/libc-start.c:308
#14 0x5603cb499019 in _start (/home/pq/build/weston-meson/clients/weston-keyboard+0x19019)
Indirect leak of 528 byte(s) in 51 object(s) allocated from:
#0 0x7fc109b8e810 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x3a810)
#1 0x7fc109082fc4 in FcValueSave (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1ffc4)
#2 0x7fc109083d2e (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x20d2e)
#3 0x7fc1090852c7 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x222c7)
#4 0x7fc10908c28b (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x2928b)
#5 0x7fc108603a15 (/lib/x86_64-linux-gnu/libexpat.so.1+0xba15)
#6 0x7fc1086044bb (/lib/x86_64-linux-gnu/libexpat.so.1+0xc4bb)
#7 0x7fc108601f8a (/lib/x86_64-linux-gnu/libexpat.so.1+0x9f8a)
#8 0x7fc108602e7a (/lib/x86_64-linux-gnu/libexpat.so.1+0xae7a)
#9 0x7fc108606a37 in XML_ParseBuffer (/lib/x86_64-linux-gnu/libexpat.so.1+0xea37)
#10 0x7fc10908a0fa (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x270fa)
#11 0x7fc10908a519 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x27519)
#12 0x7fc10908a73a (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x2773a)
#13 0x7fc10908b48f (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x2848f)
#14 0x7fc108603a15 (/lib/x86_64-linux-gnu/libexpat.so.1+0xba15)
#15 0x7fc1086044bb (/lib/x86_64-linux-gnu/libexpat.so.1+0xc4bb)
#16 0x7fc108601f8a (/lib/x86_64-linux-gnu/libexpat.so.1+0x9f8a)
#17 0x7fc108602e7a (/lib/x86_64-linux-gnu/libexpat.so.1+0xae7a)
#18 0x7fc108606a37 in XML_ParseBuffer (/lib/x86_64-linux-gnu/libexpat.so.1+0xea37)
#19 0x7fc10908a0fa (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x270fa)
#20 0x7fc10908a519 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x27519)
#21 0x7fc10907c4b3 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x194b3)
#22 0x7fc10907c715 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x19715)
#23 0x7fc10906e8e6 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0xb8e6)
#24 0x7fc109070928 in FcConfigSubstituteWithPat (/lib/x86_64-linux-gnu/libfontconfig.so.1+0xd928)
#25 0x7fc109ae2d6b (/lib/x86_64-linux-gnu/libcairo.so.2+0xbed6b)
#26 0x7fc109a8aba2 in cairo_scaled_font_create (/lib/x86_64-linux-gnu/libcairo.so.2+0x66ba2)
#27 0x7fc109a50d1d (/lib/x86_64-linux-gnu/libcairo.so.2+0x2cd1d)
#28 0x7fc109a53be0 (/lib/x86_64-linux-gnu/libcairo.so.2+0x2fbe0)
#29 0x7fc109a4c1df (/lib/x86_64-linux-gnu/libcairo.so.2+0x281df)
#30 0x7fc109aa8dab in cairo_text_extents (/lib/x86_64-linux-gnu/libcairo.so.2+0x84dab)
#31 0x5603cb499af3 in draw_key ../../git/weston/clients/keyboard.c:329
#32 0x5603cb49a30c in redraw_handler ../../git/weston/clients/keyboard.c:392
#33 0x5603cb4b506b in widget_redraw ../../git/weston/clients/window.c:4520
#34 0x5603cb4b55da in surface_redraw ../../git/weston/clients/window.c:4578
#35 0x5603cb4b5750 in idle_redraw ../../git/weston/clients/window.c:4607
#36 0x5603cb4bebe3 in display_run ../../git/weston/clients/window.c:6525
#37 0x5603cb49e55d in main ../../git/weston/clients/keyboard.c:1054
#38 0x7fc1092a709a in __libc_start_main ../csu/libc-start.c:308
#39 0x5603cb499019 in _start (/home/pq/build/weston-meson/clients/weston-keyboard+0x19019)
With the command line
ASAN_OPTIONS=fast_unwind_on_malloc=0,malloc_context_size=50 \
LSAN_OPTIONS=suppressions=/home/pq/git/weston/.gitlab-ci/leak-sanitizer.supp \
./tests/test-viewporter test_viewporter_double_create
Suppressions used:
count bytes template
5 357 cairo_select_font_face
130 9104 cairo_text_extents
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Another patch will want to call global_destroy() too.
Pure refactoring, no functional change.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This fixes a bunch of leaks when trying to run a Weston test with
desktop-shell, which spawns weston-keyboard.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Trying to run viewporter-test with ASan leak checking,
weston-desktop-shell helper client reports many leaks, because the
compositor quits before the client can start. Hence the
wl_display_roundtrip() fails.
Clean up by calling display_destroy() when wl_display_roundtrip() fails.
It's late enough that all kinds of things may have been allocated, so a
special local tear-down path is not feasible.
To make that work, display_destroy() must handle many things that might
be NULL which normally aren't. Also display_create() needs to initialize
lists early enough so that cleaning them up works.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Currently, Weston clients update the pointer cursor by first issuing
a wl_surface.commit request to update the buffer, then a
wl_pointer.set_cursor request to update the hotspot. This causes an
issue because buffer and hotspot aren't updated atomically: in-between
the two requests, the buffer is new but the hotspot is old.
To fix this issue, create a new surface each time the cursor is
updated.
Signed-off-by: Simon Ser <contact@emersion.fr>
struct weston_test_surface in the test harness' compositor plugin had no
tear down code, which lead to ASan report on alpha-blending test:
Direct leak of 64 byte(s) in 2 object(s) allocated from:
#0 0x7f8931f10330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x7f892d934425 in move_surface ../../git/weston/tests/weston-test.c:181
#2 0x7f893159d8ed in ffi_call_unix64 (/lib/x86_64-linux-gnu/libffi.so.6+0x68ed)
While at it, let's do this properly for once:
- put the creation in a new function
- hook up to the weston_surface destroy signal so this actually gets
freed (fixes the leak)
- check that we don't overwrite another surface role
- check that committed_private actually is ours
- set the surface label func so it gets properly listed in debugs and
traces
- use the proper surface role setup call, so no-one stomps on anyones
toes if a test makes a mistake by using a wrong wl_surface
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes a leak found by ASan in alpha-blending-test.
Direct leak of 160 byte(s) in 2 object(s) allocated from:
#0 0x7f511fe11518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7f511fc76373 in zalloc ../../git/wayland/src/wayland-private.h:232
#2 0x7f511fc76373 in proxy_create ../../git/wayland/src/wayland-client.c:422
#3 0x7f511fc79dcc in create_outgoing_proxy ../../git/wayland/src/wayland-client.c:651
#4 0x7f511fc79dcc in wl_proxy_marshal_array_constructor_versioned ../../git/wayland/src/wayland-client.c:736
#5 0x7f511fc7b17b in wl_proxy_marshal_constructor_versioned ../../git/wayland/src/wayland-client.c:873
#6 0x5583e5348f43 in wl_registry_bind /home/pq/local/include/wayland-client-protocol.h:1165
#7 0x5583e534cfbe in handle_global ../../git/weston/tests/weston-test-client-helper.c:800
#8 0x7f511f34b8ed in ffi_call_unix64 (/lib/x86_64-linux-gnu/libffi.so.6+0x68ed)
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixed a leak found by ASan:
Direct leak of 160 byte(s) in 2 object(s) allocated from:
#0 0x7f511fe11518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7f511fc76373 in zalloc ../../git/wayland/src/wayland-private.h:232
#2 0x7f511fc76373 in proxy_create ../../git/wayland/src/wayland-client.c:422
#3 0x7f511fc79dcc in create_outgoing_proxy ../../git/wayland/src/wayland-client.c:651
#4 0x7f511fc79dcc in wl_proxy_marshal_array_constructor_versioned ../../git/wayland/src/wayland-client.c:736
#5 0x7f511fc7b17b in wl_proxy_marshal_constructor_versioned ../../git/wayland/src/wayland-client.c:873
#6 0x5583e5348f43 in wl_registry_bind /home/pq/local/include/wayland-client-protocol.h:1165
#7 0x5583e535140b in bind_to_singleton_global ../../git/weston/tests/weston-test-client-helper.c:1863
#8 0x5583e5348752 in alpha_blend_monotonic ../../git/weston/tests/alpha-blending-test.c:219
#9 0x5583e5348571 in wrapalpha_blend_monotonic ../../git/weston/tests/alpha-blending-test.c:200
#10 0x5583e53554cc in run_test ../../git/weston/tests/weston-test-runner.c:162
#11 0x5583e5355b6d in run_case ../../git/weston/tests/weston-test-runner.c:277
#12 0x5583e5355913 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235
#13 0x5583e5355df5 in testsuite_run ../../git/weston/tests/weston-test-runner.c:311
#14 0x7f511aaaf752 in client_thread_routine ../../git/weston/tests/weston-test.c:404
#15 0x7f511f88cfa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes a definitely lost:
== 56 bytes in 1 blocks are definitely lost in loss record 16 of 45
== at 0x48450F8: malloc (vg_replace_malloc.c:309)
== by 0x4B55E93: wl_event_loop_add_timer (event-loop.c:197)
== by 0x4126CF: weston_compositor_create (in /usr/local/bin/weston)
== by 0x409997: main (in /usr/local/bin/weston)
Signed-off-by: Lujin Wang <luwang@nvidia.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This fixes the following leaks detected by ASan in
./tests/test-alpha-blending:
Direct leak of 176 byte(s) in 2 object(s) allocated from:
#0 0x7fb447880518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fb4432c12d7 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7fb4432c2ca6 in weston_desktop_xwayland_init ../../git/weston/libweston-desktop/xwayland.c:410
#3 0x7fb4432baadf in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:87
#4 0x7fb4432e1e1f in wet_shell_init ../../git/weston/tests/weston-test-desktop-shell.c:224
#5 0x7fb44775fddd in wet_load_shell ../../git/weston/compositor/main.c:956
#6 0x7fb447770db1 in wet_main ../../git/weston/compositor/main.c:3434
#7 0x56172c599279 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#8 0x56172c59cce5 in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#9 0x56172c58dc8c in fixture_setup ../../git/weston/tests/alpha-blending-test.c:65
#10 0x56172c58dd31 in fixture_setup_run_ ../../git/weston/tests/alpha-blending-test.c:67
#11 0x56172c59d29a in main ../../git/weston/tests/weston-test-runner.c:661
#12 0x7fb4473d509a in __libc_start_main ../csu/libc-start.c:308
Indirect leak of 144 byte(s) in 2 object(s) allocated from:
#0 0x7fb447880518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fb4432bb592 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7fb4432bb882 in weston_desktop_client_create ../../git/weston/libweston-desktop/client.c:108
#3 0x7fb4432c2d0e in weston_desktop_xwayland_init ../../git/weston/libweston-desktop/xwayland.c:415
#4 0x7fb4432baadf in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:87
#5 0x7fb4432e1e1f in wet_shell_init ../../git/weston/tests/weston-test-desktop-shell.c:224
#6 0x7fb44775fddd in wet_load_shell ../../git/weston/compositor/main.c:956
#7 0x7fb447770db1 in wet_main ../../git/weston/compositor/main.c:3434
#8 0x56172c599279 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#9 0x56172c59cce5 in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#10 0x56172c58dc8c in fixture_setup ../../git/weston/tests/alpha-blending-test.c:65
#11 0x56172c58dd31 in fixture_setup_run_ ../../git/weston/tests/alpha-blending-test.c:67
#12 0x56172c59d29a in main ../../git/weston/tests/weston-test-runner.c:661
#13 0x7fb4473d509a in __libc_start_main ../csu/libc-start.c:308
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This new function is callable explicitly, unlike the old function that
used to have the same name.
This will be needed when tearing down what
weston_desktop_xwayland_init() puts up.
Since calling weston_desktop_client_destroy() for an external client
(one that has a wl_resource for this) is a bug, add asserts to prevent
it. This will only be needed for the internal client: XWM.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This function here is a wl_resource destructor, but we will need another
function for externally triggered destroy when wl_resource does not
exist.
Rename the existing function, because the old name fits better the new
function to be written.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This ensures the layers are torn down properly.
See commit: libweston: add weston_layer_fini()
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This ensures the layers are torn down properly.
See commit: libweston: add weston_layer_fini()
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Alexandros Frantzis
Pekka Paalanen
Michael Tretter
Igor Matheus Andrade Torrente
Marius Vlad
Samu Nuutamo
Lujin Wang
Simon Ser