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>
This properly takes care of removing any of the views being added into
different layers upon shell destruction. Aggregates the shell_surface
destruction into one place to make things much more clearer. Keep the
animation part only the weston_desktop_surface destruction rather than
doing it at shutdown.
Fixes#509.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Starting with commit 'desktop-shell: Embed keyboard focus handle code
when activating' we are iterating over all the seats when removing a
weston_desktop_surface to be able to invalidate the activate surface.
Upon compositor tear down the shell destroy might invalidate seats
before removal of the weston_desktop_surface making the shell_seat
itself invalid. This wasn't apparent at that time because we're not
handling at that the removal of surfaces from layers.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Attempting to perform a switch on a surface (already) closed will trip
the assert in activate(), so check if we have a weston_desktop_surface
before trying to activate it.
Fixes#543
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
We no longer make use of the keyboard_focus_listener so remove it
entirely.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Derek Foreman <derek.foreman@collabora.com>
We shouldn't be constrained by having a keyboard plugged-in, so avoid
activating/de-activating the window/surface in the keyboard focus
handler and embed it straight into the window activation part.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The shsurf is calloc'ed so the surface count is always 0. Not only
that but the surface is not set as active by default, so there's no
need to de-activate it.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When the surface type of input panel is set as an overlay panel, it's
expected to be shown at near the input cursor. But the current
implementation shows it at center-bottom on the desktop at first then
move it to the correct position while typing.
Signed-off-by: Takuro Ashie <ashie@clear-code.com>
The keyboard focus listener, caps changed and pointer focus listener
were missing when destroying the seat. These are necessary to avoid
using weston_desktop object even if it was destroyed, which happens due
to a focus out event and ultimately handled by the keyboard focus notify
callback.
Once the seats are destroyed (and implictly the focus handlers) we're
safe to destroy weston_desktop object as well.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This properly tracks the seats and with it, destroys them before
destroying weston_desktop object.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Fixes an issue where subsurface extending outside of the main surface
wasn't damaged when minimized resulting in left-over content.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Follow-up from commit 'desktop-shell: don't run fade animation if
compositor is inactive' where the reference was dropped directly,
instead of using weston_surface_destroy().
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When a window is closed, Weston will, by default, run a fade out animation and
defer destroying the underlying surface until it completes. However, if the
compositor is sleeping, and therefore not rendering any frames, this animation
will *never* complete. Therefore, if windows are repeatedly created and
destroyed while in sleep mode, these surfaces will keep accumulating, and since
the buffers attached to them may be backed by an fd, eventually the ulimit will
be reached resulting in a potential crash or other errors.
This can be demonstrated repeatedly launching and killing an X11 application
with Xwayland running.
while true; do xterm & pid=$!; sleep 0.5; kill $pid; done
As soon as the compositor goes to sleep, one can observe a steadily growing
list of dmabufs in the output of lsof.
As a fix, desktop_surface_removed should check whether the compositor is active
before kicking off the fade animation. If it is not, it should instead drop the
extra reference taken in desktop_surface_committed and then destroy the surface
immediately.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.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>
This ensures the layers are torn down properly.
See commit: libweston: add weston_layer_fini()
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
After some changes in the exposay layout, the outer padding makes
no sense anymore. It was used to avoid the panel to get overlapped
by the exposay surfaces and to keep distance from the borders
of the window.
Currently, the exposay is centralized and the panel cannot get
overlapped. The outer padding just creates unnecessary unused
space, what makes exposay's surfaces smaller.
Delete outer padding from struct exposay_output.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The exposay grid is square, but we don't always have enough surfaces
to fill all the columns of the last row. The code to centralize
the surfaces of the last row is not working.
Fix the code that centralizes the surfaces in the last row, making
it more visually pleasant.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Commit "exposay: add margins to centralize exposay" has centralized
the whole exposay, but that's not enough. The internal surfaces of
exposay are not centralized.
Each internal surface of exposay is a square, but most of the windows
are rectangular. Add margin to centralize exposay's surfaces in their
own square.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The exposay is being rendered in the top-left corner of the
screen. Add margins to render it in the center, making it
more visually pleasant.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
We've been using an inner border of fixed size (80px), but this
is dangerous. If you have too many open applications or a small
window, the surface size computed will be negative, crashing
the exposay: "error: weston_view transformation not invertible".
Also, it creates a lot of unnecessary space, making the exposay
unusable when we have a small window or many applications open.
Make inner border to be 10% of surface size and surface size to
be 90% of its original size, avoiding the crashes and making it
more visually pleasant.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Commit "desktop-shell: make get_output_work_area() global" allowed
the usage of get_output_work_area() in exposay. This is necessary to
avoid overlapping the panel when rendering exposay's surfaces.
Use get_output_work_area() to not take into account the panel size,
instead of considering that the whole screen is available to
render exposay's surfaces.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
get_output_work_area() can be used by exposay to know the free space
where it can render its surfaces, what avoids overlapping the panel.
Currently this function is declared as static in
desktop-shell/shell.c, so it cannot be used by exposay.
Remove static from get_output_work_area() and add it to shell.h
so it can be used by exposay as well.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
In exposay_layout(), int pad is being calculated within the
loop. This is unnecessary, as its value is constant. Move it
out of the loop.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
As in some circumstances there could be no output connected, avoid
retrieving the width/height of the output if none was found/connected.
Fixes: #384
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The cms-static, desktop-shell, hmi-controller, ivi-shell, and screen-share
modules use symbols from libexec_weston, e.g.:
$ ldd /usr/lib/x86_64-linux-gnu/weston/desktop-shell.so | grep "not found"
libexec_weston.so.0 => not found
Loading these modules from weston happens to work because the weston executable
itself links against libexec_weston, and has an rpath set. Still, these modules
depend on a library in a non-standard location. Adding an rpath could help
static checkers to make sure all shared objects' dependencies are present.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Introduced with a8da2084, it seems that there are cases when there's no
parent available (zenity, for instance).
Removes any potential child and re-initialize it, in case the parent is
not set. (Simon Ser)
Fixes: #340
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reported-by: n3rdopolis <bluescreenavenger@gmail.com>
If a xdg_toplevel surface has a child (or multiple), the desktop shell
still allows to activate the parent. This can be problematic with
modal dialogs such as message boxes which then are hidden behind the
main window, which might be non-responsive to inputs at this this
point.
The protocol specifies set_parent as follows: "Set the 'parent' of
this surface. This surface should be stacked above the parent surface
and all other ancestor surfaces."
Track parent/child relationship in desktop-shell. Follow the protocol
recommendation and make sure the child stays stacked above the parent.
Fixes: #231
Signed-off-by: Stefan Agner <stefan@agner.ch>
Wayland innovated a lot of cool things, but non-binary boolean values is
the great advances of our time.
Make config_parser_get_bool() work on boolean values, and switch all its
users.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This introduces a new convention of checking through the compositor destroy
listener if the plugin is already initialized. If the plugin is already
initialized, then the plugin entry function succeeds as a no-op. This makes it
safe to load the same plugin multiple times in a running compositor.
Currently module loading functions return failure if a plugin is already
loaded, but that will change in the future. Therefore we need this other method
of ensuring we do not double-initialize a plugin which would lead to list
corruptions the very least.
All plugins are converted to use the new helper, except:
- those that do not have a destroy listener already, and
- hmi-controller which does the same open-coded as the common code pattern
did not fit there.
Plugins should always have a compositor destroy listener registered since they
very least allocate a struct to hold their data. Hence omissions are
highlighted in code.
Backends do not need this because weston_compositor_load_backend() already
protects against double-init. GL-renderer does not export a standard module
init function so cannot be initialized the usual way and therefore is not
vulnerable to double-init.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
All these plugins use symbols that were exported by the weston executable and
are now exported by libexec-weston.so. Linking these to libexec-weston.so fixes
unresolved symbols.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
In the future libweston will stop providing it for its users, since it's not
part of libweston API.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We have two kinds of libweston users: internal and external. Weston, the
frontend, counts as an external user, and should not have access to libweston
private headers. The shell plugins are external users as well, because we
intend people to be able to write them. Renderers, backends, and some plugins
are internal users who will need access to private headers.
Create two different Meson dependency objects, one for each kind.
This makes it less likely to accidentally use a private header.
Screen-share is a Weston plugin and therefore counts as an external user, but
it needs the backend API to deliver input. Until we are comfortable exposing
public API for that purpose, let it use internal headers.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Define common_inc which includes both public_inc and the project root directory.
The project root directory will allow access to config.h and all the shared/
headers.
Replacing all custom '.', '..', '../..', '../shared' etc. include paths with
common_inc reduces clutter in the target definitions and enforces the common
#include directive style, as e.g. including shared/ headers without the
subdirectory name no longer works.
Unfortunately this does not prevent one from using private libweston headers
with the usual include pattern for public headers.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Do not build matrix.c into the shell plugins. The matrix functions are exported
by libweston.so and the shell plugins links to it.
Found by inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When hotunplugging a display, the compositor will tear down the
corresponding output object.
Avoid NULL output dereferences by all surface label getters in
desktop-shell when hotunplugging happens.
Signed-off-by: Miguel A Vico Moya <mvicomoya@nvidia.com>
When Fading out a destroyed surface view finishes, the view is rendered
with very little alpha. After that, since the output isn't updated
unless a event on the output doesn't occurs, the view is still on the
output. By unmapping the view, the output repaint scheduled without the
surface.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
When the last output is destroyed or when a new output is created after
the last output is destroyed, we need to re-position the views to ensure
that all the views are displayed on the output.
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/210
Signed-off-by: Harish Krupo <harishkrupo@gmail.com>