This too is a public installed header.
The public headers are moved under a new top-level directory include/ to make
them clearly stand out as special (public API).
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The main idea is to make libweston users use the form
#include <libweston/libweston.h>
instead of the plain
#include <compositor.h>
which is prone to name conflicts. This is reflected both in the installed
files, and the internal header search paths so that Weston would use the exact
same form as an external project using libweston would.
The public headers are moved under a new top-level directory include/ to make
them clearly stand out as special (public API).
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
input panel related members of ivi_shell struct are
not required anymore. Also get_default_view(),
input_panel_setup() and input_panel_destroy() are not used.
Therefore, we can remove them.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
If compositor wakes up from sleep state, we have
to trigger repaint for all outputs.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Add ivi-layout API for getting an ivi_layout_surface from a
weston_surface if it exists. This can be used by controllers that hook
up to core Weston callbacks and get handed a weston_surface, but need to
use ivi-layout API to manipulate it.
The only ways ivi-layout itself would be able to go from weston_surface
to ivi_layout_surface are either searching through the list of all
ivi_layout_surfaces or adding a dummy destroy listener to the
weston_surface. Therefore the implementation is delegated to
ivi-shell.c.
Ivi-shell.c can easily look up the ivi_shell_surface for a
weston_surface, and that will map 1:1 to an ivi_layout_surface.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
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>
