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>
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>
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>
0x55fa7818f8e8 in load_png ../../git/weston/shared/image-loader.c:297
#4
An error occurred
0x55fa7819039e in load_image ../../git/weston/shared/image-loader.c:423
#5
An error occurred
0x55fa78187b3e in load_cairo_surface ../../git/weston/shared/cairo-util.c:354
#6
An error occurred
0x55fa7815ff8a in background_draw ../../git/weston/clients/desktop-shell.c:779
#7
An error occurred
0x55fa7817b2c2 in widget_redraw ../../git/weston/clients/window.c:4520
#8
An error occurred
0x55fa7817b831 in surface_redraw ../../git/weston/clients/window.c:4578
#9
An error occurred
0x55fa7817b9a7 in idle_redraw ../../git/weston/clients/window.c:4607
#10
An error occurred
0x55fa78184ea4 in display_run ../../git/weston/clients/window.c:6527
#11
An error occurred
0x55fa781646fb in main ../../git/weston/clients/desktop-shell.c:1556
#12
An error occurred
0x7f826659709a in __libc_start_main ../csu/libc-start.c:308
#13
An error occurred
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
An error occurred
0x7f8266f2d330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1
An error occurred
0x55fa7818f5e7 in load_png ../../git/weston/shared/image-loader.c:275
#2
An error occurred
0x55fa7819039e in load_image ../../git/weston/shared/image-loader.c:423
#3
An error occurred
0x55fa78187b3e in load_cairo_surface ../../git/weston/shared/cairo-util.c:354
#4
An error occurred
0x55fa7815ff8a in background_draw ../../git/weston/clients/desktop-shell.c:779
#5
An error occurred
0x55fa7817b2c2 in widget_redraw ../../git/weston/clients/window.c:4520
#6
An error occurred
0x55fa7817b831 in surface_redraw ../../git/weston/clients/window.c:4578
#7
An error occurred
0x55fa7817b9a7 in idle_redraw ../../git/weston/clients/window.c:4607
#8
An error occurred
0x55fa78184ea4 in display_run ../../git/weston/clients/window.c:6527
#9
An error occurred
0x55fa781646fb in main ../../git/weston/clients/desktop-shell.c:1556
#10
An error occurred
0x7f826659709a in __libc_start_main ../csu/libc-start.c:308
#11
An error occurred
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
An error occurred
0x7f8c3455f330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1
An error occurred
0x7f8c33c60906 in wl_event_loop_add_timer ../../git/wayland/src/event-loop.c:571
#2
An error occurred
0x7f8c2ff98f46 in shell_fade_init ../../git/weston/desktop-shell/shell.c:4211
#3
An error occurred
0x7f8c2ff9e1da in wet_shell_init ../../git/weston/desktop-shell/shell.c:5266
#4
An error occurred
0x7f8c3443ede5 in wet_load_shell ../../git/weston/compositor/main.c:956
#5
An error occurred
0x7f8c3444fdb9 in wet_main ../../git/weston/compositor/main.c:3434
#6
An error occurred
0x55878ad3bfc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#7
An error occurred
0x55878ad3f9fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#8
An error occurred
0x55878ad2fbd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46
#9
An error occurred
0x55878ad2fc58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48
#10
An error occurred
0x55878ad3ffaf in main ../../git/weston/tests/weston-test-runner.c:661
#11
An error occurred
0x7f8c340b409a in __libc_start_main ../csu/libc-start.c:308
#12
An error occurred
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
An error occurred
0x7f8c3455f518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1
An error occurred
0x7f8c33c99b73 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2
An error occurred
0x7f8c33c9cfb1 in weston_surface_create ../../git/weston/libweston/compositor.c:574
#3
An error occurred
0x7f8c2ff98230 in shell_fade_create_surface_for_output ../../git/weston/desktop-shell/shell.c:4059
#4
An error occurred
0x7f8c2ff98df6 in shell_fade_init ../../git/weston/desktop-shell/shell.c:4202
#5
An error occurred
0x7f8c2ff9e1da in wet_shell_init ../../git/weston/desktop-shell/shell.c:5266
#6
An error occurred
0x7f8c3443ede5 in wet_load_shell ../../git/weston/compositor/main.c:956
#7
An error occurred
0x7f8c3444fdb9 in wet_main ../../git/weston/compositor/main.c:3434
#8
An error occurred
0x55878ad3bfc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#9
An error occurred
0x55878ad3f9fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#10
An error occurred
0x55878ad2fbd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46
#11
An error occurred
0x55878ad2fc58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48
#12
An error occurred
0x55878ad3ffaf in main ../../git/weston/tests/weston-test-runner.c:661
#13
An error occurred
0x7f8c340b409a in __libc_start_main ../csu/libc-start.c:308
#14
An error occurred
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
An error occurred
0x7f8c3455f518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1
An error occurred
0x7f8c33c99b73 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2
An error occurred
0x7f8c33c9bed5 in weston_view_create ../../git/weston/libweston/compositor.c:365
#3
An error occurred
0x7f8c2ff98251 in shell_fade_create_surface_for_output ../../git/weston/desktop-shell/shell.c:4063
#4
An error occurred
0x7f8c2ff98df6 in shell_fade_init ../../git/weston/desktop-shell/shell.c:4202
#5
An error occurred
0x7f8c2ff9e1da in wet_shell_init ../../git/weston/desktop-shell/shell.c:5266
#6
An error occurred
0x7f8c3443ede5 in wet_load_shell ../../git/weston/compositor/main.c:956
#7
An error occurred
0x7f8c3444fdb9 in wet_main ../../git/weston/compositor/main.c:3434
#8
An error occurred
0x55878ad3bfc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#9
An error occurred
0x55878ad3f9fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#10
An error occurred
0x55878ad2fbd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46
#11
An error occurred
0x55878ad2fc58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48
#12
An error occurred
0x55878ad3ffaf in main ../../git/weston/tests/weston-test-runner.c:661
#13
An error occurred
0x7f8c340b409a in __libc_start_main ../csu/libc-start.c:308
#14
An error occurred
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>
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
An error occurred
0x7fc109c3d518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1
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
An error occurred
0x7f8931f10330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1
An error occurred
0x7f892d934425 in move_surface ../../git/weston/tests/weston-test.c:181
#2
An error occurred
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 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 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>
This ensures the layers are torn down properly.
See commit: libweston: add weston_layer_fini()
There would be a lot more to tear down here, but that is for another
time.
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>
Layers did not have a fini sequence before, which means the compositor
layer list might have stale pointers temporarily when shutting down. A
bigger problem might be having views linger after the destruction of the
layer.
These problems were not observed yet, but if they exist, this patch
should help to find them and then fix them.
The check in weston_compositor_shutdown() is not an assert yet, because
it will trigger until all components call weston_layer_fini() correctly.
Some components do not even have a tear-down function to call it from at
all, like fullscreen-shell.
The same with the check in weston_layer_fini().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>