For some reason, it seems that ivi-layout.c has tried hard to avoid
calling directly into ivi-shell.c. This means there is a jump through
hoops just to get the configure event sent to the clients. Ivi-shell
registers a listener for a ivi-layout signal for sending the event.
Instead, let ivi-layout.c call directly into ivi-shell.c, and expose a
function to send out the configure events. This reduces some confusion
on who calls what.
The main idea though is that this makes ivi-shell.c not depend on struct
ivi_layout_surface fields directly anymore. In following patches,
ivi_layout_surface can be made opaque for ivi-shell.c.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
It's our standard practice. This file will get used a bit more in the
future.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
We used to rely on the order in which the
weston_compositor::destroy_signal callbacks happened, to not access
freed memory. Don't know when, but this broke at least with ivi-shell,
which caused crashes in random places on compositor shutdown.
Valgrind found the following:
Invalid write of size 8
at 0xC2EDC69: unbind_input_panel (input-panel-ivi.c:340)
by 0x4E3B6BB: destroy_resource (wayland-server.c:537)
by 0x4E3E085: for_each_helper.isra.0 (wayland-util.c:359)
by 0x4E3E60D: wl_map_for_each (wayland-util.c:365)
by 0x4E3BEC7: wl_client_destroy (wayland-server.c:675)
by 0x4182F2: text_backend_notifier_destroy (text-backend.c:1047)
by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
by 0x4084FB: main (compositor.c:5465)
Address 0x67ea360 is 208 bytes inside a block of size 232 free'd
at 0x4C2A6BC: free (vg_replace_malloc.c:473)
by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
by 0x4084FB: main (compositor.c:5465)
Invalid write of size 8
at 0x4E3E0D7: wl_list_remove (wayland-util.c:57)
by 0xC2EDEE9: destroy_input_panel_surface (input-panel-ivi.c:191)
by 0x4E3B6BB: destroy_resource (wayland-server.c:537)
by 0x4E3BC7B: wl_resource_destroy (wayland-server.c:550)
by 0x40DB8B: wl_signal_emit (wayland-server-core.h:264)
by 0x40DB8B: weston_surface_destroy (compositor.c:1883)
by 0x40DB8B: weston_surface_destroy (compositor.c:1873)
by 0x4E3B6BB: destroy_resource (wayland-server.c:537)
by 0x4E3E085: for_each_helper.isra.0 (wayland-util.c:359)
by 0x4E3E60D: wl_map_for_each (wayland-util.c:365)
by 0x4E3BEC7: wl_client_destroy (wayland-server.c:675)
by 0x4182F2: text_backend_notifier_destroy (text-backend.c:1047)
by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
by 0x4084FB: main (compositor.c:5465)
Address 0x67ea370 is 224 bytes inside a block of size 232 free'd
at 0x4C2A6BC: free (vg_replace_malloc.c:473)
by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
by 0x4084FB: main (compositor.c:5465)
Invalid write of size 8
at 0x4E3E0E7: wl_list_remove (wayland-util.c:58)
by 0xC2EDEE9: destroy_input_panel_surface (input-panel-ivi.c:191)
by 0x4E3B6BB: destroy_resource (wayland-server.c:537)
by 0x4E3BC7B: wl_resource_destroy (wayland-server.c:550)
by 0x40DB8B: wl_signal_emit (wayland-server-core.h:264)
by 0x40DB8B: weston_surface_destroy (compositor.c:1883)
by 0x40DB8B: weston_surface_destroy (compositor.c:1873)
by 0x4E3B6BB: destroy_resource (wayland-server.c:537)
by 0x4E3E085: for_each_helper.isra.0 (wayland-util.c:359)
by 0x4E3E60D: wl_map_for_each (wayland-util.c:365)
by 0x4E3BEC7: wl_client_destroy (wayland-server.c:675)
by 0x4182F2: text_backend_notifier_destroy (text-backend.c:1047)
by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
by 0x4084FB: main (compositor.c:5465)
Address 0x67ea368 is 216 bytes inside a block of size 232 free'd
at 0x4C2A6BC: free (vg_replace_malloc.c:473)
by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
by 0x4084FB: main (compositor.c:5465)
Looking at the first of these, unbind_input_panel() gets called when the
text-backend destroys its helper client which has bound to input_panel
interface. This happens after the shell's destroy_signal callback has
been called, so the shell has already been freed.
The other two errors come from
wl_list_remove(&input_panel_surface->link);
which has gone stale when the shell was destroyed
(shell->input_panel.surfaces list).
Rather than creating even more destroy listeners and hooking them up in
spaghetti, modify text-backend to not hook up to the compositor destroy
signal. Instead, make it the text_backend_init() callers' responsibility
to also call text_backend_destroy() appropriately, before the shell goes
away.
This fixed all the above Valgrind errors, and avoid a crash with
ivi-shell when exiting Weston.
Also using desktop-shell exhibited similar Valgrind errors which are
fixed by this patch, but those didn't happen to cause any crashes AFAIK.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
ivi-layout.so is separately built and loaded by using dlopen with
RTLD_GLOBAL. This was because these apis defined in ivi-layout.so shall
be used by ivi-modules; e.g. hmi-controller. This shall be improved that
a struct ivi_layout_api contains the whole exported API as function
pointers to be exposed as module_init.
This patch alone builds, but loading controller modules at runtime
failes. This failure will be fixed by following patches.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- introduces ivi-shell/input-panel-ivi.c which is basically copied
from desktop shell. It shall be improvaded to remove duplicate
implementation.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- ivi-shell.so
- introduces ivi-shell/ivi-shell.[ch]
In-Vehicle Infotainment system traditionally manages surfaces with
global identification. A protocol, ivi_application, supports such a
feature by implementing a request, ivi_application::surface_creation
defined in ivi_application.xml.
The ivi-shell explicitly loads ivi-layout.so and a module to add
business logic like how to layout surfaces by using ivi-layout APIs.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
