We can get ivisurf, ivilayer and iviscreen
easily from ivi_view. Then, we do not need
to check, if ivi_view's layer is the same
as the given ivilayer.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If a layer is removed from a screen's render order list, but the
changes are not commited. Then, the layer could not be added to the
same screen. Because on_screen property of the layer is only changed
in ivi_layout_commit_changes API, when active render order of the screen
is changed.
It is not possible to change the order of layers in a screen without
clearing and commiting the changes before. This patch fixes this issue.
After this patch, the pending render order list of a screen is always
modified regardless of its active render order list.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If a surface is removed from a layer's render order list, but the
changes are not commited. Then, the surface could not be added to the
same layer. Because ivi_view of the surface is still in the render order
list of the layer.
It is not possible to change the order of surfaces in a layer without
clearing and commiting the changes before. This patch fixes this issue.
After this patch, the pending render order list of a layer is always
modified regardless of its active render order list.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This avoids loading a shell as a module, so we are sure to have only one
shell loaded at a time.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Currently, layers’ order depends on the module loading order and it does
not survive runtime modifications (like shell locking/unlocking).
With this patch, modules can safely add their own layer at the expected
position in the stack, with runtime persistence.
v4 Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Acked-by: Daniel Stone <daniels@collabora.com>
[Pekka: fix three whitespace issues]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- ivi-shell/hmi-controller.c:41: a to an
- ivi-shell/hmi-controller.c:1296: Duplicated 'a'
- ivi-shell/ivi-layout-export.h:28: An to A
Signed-off-by: Abdur Rehman <arehmanq199@gmail.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
I wrote comments on which list they are used with
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
[Pekka: fix surface_list to layer_list, add ivi_layout_transition_set::transition_list]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
I removed unused members of ivi_layout* data
structs.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This is a follow up for ivi-shell to manually
set mapped status for views/surfaces it controls
v2:
- Updated for changes in git master
Signed-off-by: Armin Krezović <krezovic.armin@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The name suggests that it activates surfaces, but the code says it
rather just assigns keyboard focus. Rename it for clarity, and so the
original function name could be used for something more appropriate
later. Switch order of parameters since keyboard focus is a property of
the seat. Update all callers as appropriate.
Change was asked for by pq, May 26, 2016:
"This should be called weston_seat_set_keyboard_focus(seat, surface).
Keyboard focus is a property of the seat."
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This patch introduces ivi_layout_view data struct,
which is a wrapper of weston_view.
There is always only one ivi_layout_view for an
ivi_layout_surface and ivi_layout_layer pair.
A surface could have many views with different
geometry and transformations, so that a surface
can be shown on:
1. On many screens
2. On the same screen with different positions
The geometry of a view is modified, when properties of
its layer are changed through ivi_layout_interface.
Users of ivi_layout_interface does not have direct access
to ivi_layout_view structure.
v2 changes:
1. Use ivi_view_is_rendered function instead of
active member
2. Add descriptions to introduced members of
structs
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
[Natsume: add empty line]
Reviewed-by: Wataru Natsume <wnatsume@jp.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add surface_created listener after the initialization of launchers.
Otherwise, surfaces of the launchers will be added to the application
layer too.
This does create a race where we might miss some surfaces that get
created before the UI client signals ready, but it was agreed the race
is not significant. You cannot use the launchers before the UI is ready,
and someone using systemd integration to launch clients in parallel to
Weston with ivi-shell and hmi-controller is unlikely. After all,
hmi-controller is just a demo.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
[Pekka: added extra commit message notes]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This is the start of separating weston-the-compositor source files from
libweston source files.
This is moving all the files related to the 'weston' binary. Also the
CMS and systemd plugins are moved.
xwayland plugin is not moved, because it will be turned into a
libweston feature.
To avoid breaking the build, #includes for weston.h are fixed to use
compositor/weston.h. This serves as a reminder that such files may need
further attention: moving to the right directory, or maybe using the
proper -I flags instead.
v2: Move also screen-share.c, and add a note about weston-launch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Benoit Gschwind <gschwind@gnu-log.net>
Acked-by: Benoit Gschwind <gschwind@gnu-log.net>
[Pekka: rebased]
A surface could have more than one views.
Therefore, it is not possible to map a surface to
a specific view. The implementation of the API
iterates the list of views of the surface, and
returns the first found view.
It is not necessary to have this API to found
a view of the surface. Therefore, I removed the API.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The backends are now installed in lib/libweston-0, and the include
files that will be used by libweston in include/libweston-0. The other
modules and weston-specific include files are kept in the old paths.
A new wet_load_module() is added to load plugins in the old path,
which is not part of libweston, but weston only and defined in main.c.
To allow that to be used by out of tree weston plugins, the function
is declared in a new weston.h, installed in include/weston.
The -0 in the paths is the abi version of libweston, and it will also
be used by the libweston .so. If the abi changes the number will need
to be increased.
Signed-off-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The config can now be retrieved with a new function defined in weston.h,
wet_get_config(weston_compositor*).
Signed-off-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
They belong in the compositor rather than libweston since they
set signals handlers, and a library should not do that behind its
user's back. Besides, they were using functions in main.c already
so they were not usable by other compositors.
Signed-off-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
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>
This is derived from the implementation. I was not sure whether "under"
referred to object relationships or region intersections.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
On_layer of ivi_layout_surface should be NULL in the layer_destroy.
Previous code might access to removed ivilayer and cause SEGV.
Signed-off-by: Wataru Natsume <wataru_natsume@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The add_notification_configure_surface API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to
add_listener_configure_surface.
This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
by controller plugins
3. Remove API is not needed. Controller plugins can easily
remove the listener link.
The remove API is removed too:
- ivi_layout_remove_notification_configure_surface
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The add_notification_remove_surface API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to add_listener_remove_surface.
This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
by controller plugins
3. Remove API is not needed. Controller plugins can easily
remove the listener link.
The remove API is removed too:
- ivi_layout_remove_notification_remove_surface
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The add_notification_remove_layer API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to add_listener_remove_layer.
This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
by controller plugins
3. Remove API is not needed. Controller plugins can easily
remove the listener link.
The remove API is removed too:
- ivi_layout_remove_notification_remove_layer
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The add_notification_layer_surface API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to add_listener_layer_surface.
This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
by controller plugins
3. Remove API is not needed. Controller plugins can easily
remove the listener link.
The remove API is removed too:
- ivi_layout_remove_notification_create_layer
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The add_notification_create_surface API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to
add_listener_create_surface.
This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
by controller plugins
3. Remove API is not needed. Controller plugins can easily
remove the listener link.
The remove API is removed too:
- ivi_layout_remove_notification_create_surface
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The layer_add_notification API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to layer_add_listener.
This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
by controller plugins
3. Remove API is not needed. Controller plugins can easily
remove the listener link.
This patch also remove two APIs which are not needed:
- ivi_layout_layer_remove_notification
- ivi_layout_layer_remove_notification_by_callback
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The surface_add_notification API accepts a simple
wl_listener instead of a ivi-shell specific notification
function. Therefore, the API is renamed to surface_add_listener.
This change has several advantages:
1. Code cleanup
2. No dynamic memory allocation. Listeners are allocated
by controller plugins
3. Remove API is not needed. Controller plugins can easily
remove the listener link.
This patch also remove two APIs which are not needed:
- ivi_layout_surface_remove_notification
- ivi_layout_surface_remove_notification_by_callback
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
I moved the event_mask to ivi_layout_*_properties struct,
so that it is easily accessible with get_properties_of_*
APIs.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
content_observer_notification is removed by the commit:
193e301c74.
Therefore, this callback function is unused.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add more sanity checks to get_ivi_shell_surface() just in case.
If the configure hook is set, we must always have non-NULL
configure_private.
Check the ivi_shell_surface matches the surface.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Eugen Friedrich <friedrix@gmail.com>
This should not get called unless there is an ivi_shell_surface.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Eugen Friedrich <friedrix@gmail.com>
Copied from desktop-shell/input-panel.c, add a label function for the
input panel.
This patch strictly reduces the difference between input-panel.c and
input-panel-ivi.c.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Eugen Friedrich <friedrix@gmail.com>
To be used by the Weston timeline feature for identifying surfaces in a
trace. The 'get_label' functionality can also be used by any debugging
code, too.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Eugen Friedrich <friedrix@gmail.com>
The controller plugins use IVI Layout API with weston outputs.
Therefore, this API is not required.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Wataru Natsume <wnatsume@jp.adit-jv.com>
The controller plugins does not use ivi screens for IVI layout APIs.
They use weston outputs directly. Therefore, this API is unnecessary.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Wataru Natsume <wnatsume@jp.adit-jv.com>
It is an internal API, which returns ivi_layout_screen
for a pregiven weston_output.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Wataru Natsume <wnatsume@jp.adit-jv.com>
IVI layout APIs now are called with weston_output pointers,
instead of ivi_layout_screen pointers.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Wataru Natsume <wnatsume@jp.adit-jv.com>
The compositor data struct already has a list of weston outputs.
Therefore, this API is not required.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Wataru Natsume <wnatsume@jp.adit-jv.com>
The controller plugins can get the screen resolution directly from
weston output. Therefore, this API is not required.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Wataru Natsume <wnatsume@jp.adit-jv.com>
ivi-screen does not have an id. IVI layout implementation is using
id of weston output. Therefore, this API is unnecessary.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Wataru Natsume <wnatsume@jp.adit-jv.com>
The width of the first base layer is used for all panels.
Every display has a base layer which is as big as the
display. Therefore, it is wrong to use the width of the
first base layer for all panels, because every display
could have a different resolution.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
In current implementation, the size of the first application
layer is used for the background image of a display.
This is wrong because:
1. The background surface should be fullscreen.
2. Each display could have different resolution.
We should use the size of the base layer of each display
for the background image.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Direct fail_on_null calls now produce output like:
[weston-info] clients/weston-info.c:714: out of memory
xmalloc, et al produce output on failure like:
[weston-info] out of memory (-1)
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It is not necessary check the ivi-id of pregiven objects (layer or
surface). Traversing the list of all objects is sure to find the exact
same pointer we start with, bugs aside.
The controller modules are responsible for providing valid pointers. We
cannot protect from invalid pointers anyway.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
[Pekka: fix subject, add commit message]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It is not necessary check the ivi-id of pregiven objects (layer or
surface). Traversing the list of all objects is sure to find the exact
same pointer we start with, bugs aside.
The controller modules are responsible for providing valid pointers. We
cannot protect from invalid pointers anyway.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
[Pekka: commit message]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It is not necessary check the ivi-id of pregiven objects (layer or
surface). Traversing the list of all objects is sure to find the exact
same pointer we start with, bugs aside.
The controller modules are responsible for providing valid pointers. We
cannot protect from invalid pointers anyway.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
[Pekka: commit message]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It is not necessary check the ivi-id of pregiven objects (layer or
surface). Traversing the list of all objects is sure to find the exact
same pointer we start with, bugs aside.
The controller modules are responsible for providing valid pointers. We
cannot protect from invalid pointers anyway.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
[Pekka: commit message]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It is not necessary check the ivi-id of pregiven objects (layer or
surface). Traversing the list of all objects is sure to find the exact
same pointer we start with, bugs aside.
The controller modules are responsible for providing valid pointers. We
cannot protect from invalid pointers anyway.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
[Pekka: commit message]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
In all my rebases, this got accidentally left behind. The implementation
was removed in 4a7503976b but
32ca791df8 reintroduced it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This new header encapsulates the API that ivi-layout offers to
ivi-shell.c to call.
ivi-shell.c no longer uses ivi-layout-private.h. This limits the
ivi-layout internal structures to just ivi-layout code.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
Now that ivi-layout calls directly into ivi-shell.c, this signal is no
longer used. Remove it.
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>
Every .c file must include config.h as the first thing.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
The content observer notification struct and its
set API (ivi_layout_surface_set_content_observer)
are removed. Because they are unused.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If surface transitions are not removed when surface is being removed, it
can lead to crash later when transition will finish, as it will try to
reference already freed memory.
This change exposes function that can remove all existing transitions
for given surface and it is being called during surface cleanup.
Signed-off-by: Mateusz Polrola <mateuszx.potrola@intel.com>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
get_surfaces_on_layer() allocates memory and stores the pointer to
'ivisurfs'. But it was not freed.
Signed-off-by: Wataru Natsume <WATARU_NATSUME@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The warning of ivisurface reassign can be removed. It is ok to reassign
a surface to a layer it is already on.
The warning started to show up during normal operations since patch
"hmi-controller: remove duplicate commit_changes in random mode".
Signed-off-by: Wataru Natsume <WATARU_NATSUME@xddp.denso.co.jp>
[Pekka: rewrote commit message, removed unneeded comments.]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Previous code cleaned up surfaces in layer once and then added
surfaces to a layer in random. In this flow, two commitchanges are
required.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
[WATARU_NATSUME@xddp.denso.co.jp: Removes unnecessary check]
Signed-off-by: Wataru Natsume <WATARU_NATSUME@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
update_opacity is only called when a ivi-surface is visible. But the
previous code also checks event masks redundantly. However if the event
happens when ivi-surface is invisible, opacity is not calculated. This
patch removes this redundant check to fix potential bug.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
[jonas: only send focus wl_pointer.frame if resource supports it]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Use an event struct to pass axis events around. This helps dealing with the
upcoming axis discrete changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
It shows ivi applications at screensa randomly.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It shows ivi applications in fullscreen per screen like,
The first screen: Application 1,4,5,6,,,,
The seconed screen: Application 2,
The third screen: Application 3
Thie mode assigns one application to each screen at first. And remaind
applications more than screens will be assigned to the first screen.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It shows 2 ivi application in a screen at side-by-side. It moves
additinal application more than 2xN to next screen N+1.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It shows 8 ivi applications in a screen at tiling. It moves additional
application more than 8xN to next screen N+1.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
To locate surfaces of application on multi screens, multi layers are
created baseod on application-layer-id + base-layer-id-offset x N.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
A surface ID for layer of background/panel image is set by key: background-id
or panel-id at weston.ini. To support multi screens, it also support offset,
surface-id-offset, to offset the surface ID to next ID for a layer on next
screen.
According to the above key, hmi-controller and ivi-shell-user-interface
who increments the number of screens per notification of wl_output.
crate surface and draw background/panel image on multi surface on screens.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
A layer ID for screen is set by key: base-layer-id at weston.ini. To
support multi screens. It also support offset to offset the layer ID
to next ID for next screen.
For example,
base-layer-id=1000
base-layer-id-offset=10000
Layer id for screen 0: 1000
Layer id for screen 1: 11000
Layer id for screen 2: 21000
To support multi screen, create layers for background and panel bar which
located in the below per screens. At the moment, it is only layers.
Surfaces to be created at next patch in the patch set.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- get screens from weston core
- provide screens as internel method
- the iviscn is stored in array inverse order in index.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
A weston_surface is transformed to multi screen coordinate, global
coordinate by matrix:m now.
Additionally, a mask needs to be calucated, taking account into,
- multi screen coordination: a destination rectangle of layer in the
coordination is easily calcurated by adding weston_output.{x,y} in
simple. This is because there is no scaled and rotated transformation.
- intersect inside of a screen the layer is assigned to. This is because
overlapped region of weston surface in another screen shall not be
displayed according to ivi use case.
Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
In single screen, the coordinates of layer local coordinates are the
same as global coordinates. However, to support multi screens, the
layer-local coordinates shall be transformed to multi screen coordinates,
which is global coordinates. The abosolute coordinates of a screen in global
stored in (x,y) of output of its weston output so it shall be used to
transform layer-local to global coordinates.
Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
For multi screen support, ivi_layout_screen to be taken account into
property change in commitChanges.
Property change is now done in update_prop so to consider ivi_screen
property for caluculating transform of weston surface, ivi_layout_screen
is added as a parameter of update_prop.
However, update_prop of weston_view of a ivi_surface can not be done
even if it is set on a screen. The propoerty change shall be done only
when a visibility of ivi_surface or ivi_layer which contains the
ivi_surface is ON. Such a condition shall be checked at commit_changes
as well to avoid calling update_prop, which actually updates
weston_views.
Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Similar with Desktop shell, set activate to weston surface which is
left-clicked by pointer or touched. This is needed to focus it with a seat.
Without this, a feature who gets activated weston surface by using
weston_surface_get_main_surface doesn't work correctly because it can
not get correct focused weston surface. For example, input-panel uses
weston_surface_get_main_surface to get a weston surface. With this
weston surface, it get a member: output to decide which output shall
show a input-panel, software keyboard. Without activation,
input-panel-ivi can not find a correct output which shows e.g.
weston-editor who uses input-method.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It breaks from wl_list_for_each of screens when the frist screen found.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This is potential bug when it supports several screens. If view_list is
initilized here, the views, which are set by the previous screen, are
cleared. So View list shall be initilized in front of wl_list_for_each
of all screens.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
In just previous wl_list_for_each_safe, list of layer in a screen is
cleaned up. And then, the list is re-constructed from
pending.layer_list.
In this re-construction, if order.link of a layer were inserted into a
screen whose number is later one of current screen, the order.link will
inserted into layer_list of two screens. This shall be avoided.
However, if we want to implement a feature to allow a layer to be added
to multiple screens. A layer shall have several order.link per screens.
So, I marked here as TODO.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It just return the first screen found in screen list.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Instead of only passing absolute pointer coordinates, effectively
loosing motion event data, pass a struct that can potentially contain
different types of motion events, currently being absolute and relative.
A helper function to get resulting absolute coordinates was added for
when previous callbacks simply used the (x, y) coordinates.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mariusz Ceier <mceier+wayland@gmail.com>
Reviewed-by: Jan Arne Petersen <janarne@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Don't only send motions and buttons but also axis events through the
pointer grab interface.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
The name of ivi_controller_interface is changed to ivi_layout_interface
with this patch.
This name is better suited to the interface, because it is implemented
in ivi-layout.c and its methods are linked to ivi_layout* functions.
Furthermore, the controller modules (e.g. hmi-controller) are the users
of this interface and they have their own interfaces,
which are called *_controller_interface,
e.g.: ivi_hmi_controller_interface.
This causes confusion about the software architecture.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Tested-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
The internal API "get_weston_view" is introduced, which returns the
weston_view of the given ivi_layout_surface. The API returns a NULL
pointer, if the ivi_layout_surface does not have any weston_view.
The weston_view is required in many places of ivi-shell implementation.
Therefore, this API will reduce lines of code. Furthermore, it will
increase the maintainability of the ivi-shell implementation.
Old way of getting the weston_view was flawed, because the views list of
the weston_surface is read without controlling the existence of the
weston_surface. New implementation explicitly throws an error if the
weston_surface does not exist.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Tested-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
[Pekka: Line-wrapped the commit message.]
This internal API is redundant, because a surface is allowed to be only
on one layer.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Tested-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
This internal API is redundant, because a layer is allowed to be only on
one screen.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Tested-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
link_layer's sole purpose is to link a surface to multiple layers, if
the surface should be shown in multiple layers. This can be only
achieved, if the surface has multiple weston_views with different
transformation matrices.
Current implementation assumes in many places that a ivi_surface has
only one weston_view. Therefore, a surface can be only shown on one
layer.
Although this (a surface on multiple layers) is a nice to have feature
for ivi-shell, it is not very crucial. In any case, it is not an easy
task to implement this feature, because it has lot of corner cases.
I removed with this patch the link_layer data structure, because it does
not have any purpose in current implementation.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Tested-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
[Pekka: Line-wrapped the commit message.]
link_screen's sole purpose is to link a layer to multiple screens, if
the layer should be shown in multiple screens. This can be only
achieved, if surfaces of the layer have multiple weston_views dedicated
to the different screens.
Current implementation assumes in many places that a ivi_surface has
only one weston_view. Therefore, a layer can be only shown on one
screen.
Although this (a layer on multiple screens) is a nice to have feature
for ivi-shell, it is not very crucial. In any case, it is not an easy
task to implement this feature, because it has lot of corner cases.
I removed with this patch the link_screen data structure, because it
does not have any purpose in current implementation.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Tested-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
[Pekka: Line-wrapped commit message.]
Check the return from layout_transition_register in order to fix
potential leak of memory pointed to by transition. And don't register a
null transition.
Signed-off-by: Lucas Tanure <tanure@linux.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Several fixes to handle invalid transition objects:
1. Free transition in ivi_layout_transition_fade_layer if we fail to
allocate memory for data
2. Check if transition is not null and if layout_transition_register was
ok before return, if not, free transition
3. Destroy transition if layout_transition_register was not ok, we can't
just free transition, we need to call layout_transition_destroy in
order to free private_data from transition
Signed-off-by: Lucas Tanure <tanure@linux.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
create_layout_transition does not initialize is_transition_func.
This patch initializes it to NULL.
Signed-off-by: John-John Tedro <johnjohn.tedro@gmail.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
layout_transition_register could not work and we need to free trans in
the calling function.
Signed-off-by: Lucas Tanure <tanure@linux.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Free transition before return. We don't need to use layout_transition_destroy,
because transition was not registered yet.
v2: consolidate memory leaks fixes
Signed-off-by: Lucas Tanure <tanure@linux.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
A layer for workspace is used to display icons for invoking applications
in several pages. These pages are swapped from one to next page. The
width of the layer was decided as a size of screen before reading
weston.ini. This worked correctly because there was no feature of
clipping of layer so the width of layer was not taken account.
Now clipping feature is supported. So the width shall be set to correct
one after reading weston.ini.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
View clip region is set in surface-local coordinates. To compute that
region, the ivi-layer destination rectangle in the global coordinates
are transformed back into the surface-local coordinates.
The transformation is computed by first forming the transformation
matric for the forward mappings, and then inverting it. The inverse
matric is used to transform the destination rectangles to the
surface-local coordinate system. The intersection of the rectangles is
the view clip mask.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Checking wl_list_empty() on a link offers no information: if it returns
true, wl_list_remove() is safe to do. If it returns false, you still do
not know if wl_list_remove() is safe; the link could be part of a list,
or the link could be "uninitialized" (e.g. just wl_list_remove()'d).
(From Pekka Paalanen's comment at
http://lists.freedesktop.org/archives/wayland-devel/2015-August/023987.html).
Calling wl_list_init just before wl_list_insert is redundant. Because
the links of the list are not read before it is overwritten by
wl_list_insert.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
[Pekka: line-wrapped commit message]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It is only possible to remove a layer from the order.layer_list of a
screen, when ivi_layout_screen_set_render_order is called with an empty
array. Therefore, list of layers are cumulated if the API is called
many times with different list of layers.
Change how the flags are set:
- Introduce the dirty parameter for triggering the render order change.
- IVI_NOTIFICATION_REMOVE/ADD flags are set only at commit_screen_list.
Checking wl_list_empty() on a link offers no information: if it returns
true, wl_list_remove() is safe to do. If it returns false, you still do
not know if wl_list_remove() is safe; the link could be part of a list,
or the link could be "uninitialized" (e.g. just wl_list_remove()'d).
(From Pekka Paalanen's comment at
http://lists.freedesktop.org/archives/wayland-devel/2015-August/023987.html).
Calling wl_list_init just before wl_list_insert is redundant. Because
the links of the list are not read before it is overwritten by
wl_list_insert.
Use assert to control if the ivilayer->order.surface_list is empty.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
[Pekka: line-wrapped commit message]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It is only possible to remove a surface from the order.surface_list of a
layer, when ivi_layout_layer_set_render_order is called with an empty
array. Therefore, list of surfaces are cumulated if the API is called
many times with different list of surfaces.
Change how the flags are set:
- Introduce the dirty parameter for triggering the render order change.
- IVI_NOTIFICATION_REMOVE/ADD flags are set only at commit_layer_list.
Checking wl_list_empty() on a link offers no information: if it returns
true, wl_list_remove() is safe to do. If it returns false, you still do
not know if wl_list_remove() is safe; the link could be part of a list,
or the link could be "uninitialized" (e.g. just wl_list_remove()'d).
(From Pekka Paalanen's comment at
http://lists.freedesktop.org/archives/wayland-devel/2015-August/023987.html).
Calling wl_list_init just before wl_list_insert is redundant, because
the links of the list are not read before it is overwritten by
wl_list_insert.
Use assert to control if the ivilayer->order.surface_list is empty.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
[Pekka: wrapped the commit message]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
[Earlier version Reviewed-by: Nobuhiko Tanibata
<NOBUHIKO_TANIBATA@xddp.denso.co.jp>]
The final list of surfaces of set render order shall be applied. So link
of surfaces and list of surfaces in a layer shall be initialized. And
then the order of surfaces shall be restructured.
Use existing clear_surface_pending_list function to clear the list.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Tested-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
- opening braces are on the same line as the if statement
- opening braces are not on the same line as the function name
- space between for/while/if and opening parenthesis
Signed-off-by: Dawid Gajownik <gajownik@gmail.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Keyboards and pointers aren't freed when devices are removed, so we should
really be testing keyboard_device_count and pointer_device_count in most
cases, not the actual pointers. Otherwise we end up with different
behaviour after removing a device than we had before it was inserted.
This commit renames the touch/keyboard/pointer pointers and adds helper
functions to get them that hide this complexity and return NULL when
*_device_count is 0.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Normally we need to check if a seat's [device_type]_count is > 0 before
we can use the associated pointer. However, in a binding you're
guaranteed that the seat has a device of that type. If we pass in
that type instead of the seat, it's obvious we don't have to test it.
The bindings can still get the seat pointer via whatever->seat if they
need it.
This is preparation for a follow up patch that prevents direct access
to seat->device_type pointers, and this will save us a few tests at
that point.
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Transform matrix for transforming a surface to global_matrix is
calculated from
* ivi_layout_surface_properties
* ivi_layout_layer_properties
This patch pareares sub-method like following,
1/ calc_surface_to_global_matrix()
calc_transformation_matrix() is called twice with
ivi_layout_surface/layer_properties respectively.
2/ calc_transformation_matrix()
This calcurates matrix from orientation, source rectangle and
destination rectangle.
2-1/ To calculate rotation, fit centor of source rectangle to (0,0)
temporarily. This is moved back in 2-4.
2-2/ Apply rotation variant
2-3/ Apply scale variant
2-4/ Apply positioning variant, taking account into 2-1 temporary
positioning.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
To refactor transform of ivi_layout_surface and ivi_layout_surface to be
more readable logical flow.
Remove following parts once,
* definition of weston_transform in ivi_layout_surface
* update_layer_orientation
* update_layer_position
* update_surface_position
* update_surface_orientation
* update_scale
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
There is no logic update.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
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>
"remove" is not proper name beacause it destorys a layer. The name of
the api is changed from layer_remove to layer_destroy.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
In previous code, it sends notification whenever setter calls. This
patch fixs that notification will not happens if there is no change of
properties by setter.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Previous code sends notification without event mask. So the notification
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This interface is required for user to manage screens per IDs.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
To get property changes of ivi_layer, callbacks can be registered.
However there was no API to remove a callback rather than removing all
callbacks by using layer_remove_notification.
layer_remove_notification_by_callback can do it.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
To get property changes of ivi_surface, callbacks can be registered.
However there was no API to remove a callback rather than remove all
callbacks by using surface_remove_notification.
surface_remove_notification_by_callback can do it.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
if a controller calls ivi_layout_layer_create_with_demenstion with a ID
which is already created before, the API returns exist ivi_layer.
However addtionally, it shall count up ref count to destroy ivi_layer
when ref count is 0. The previous code will destroy ivi_layer
immediately even if the other code still refers ivi_layer.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
ivi_shell_surface lifetime shall follow the ivi_surface protocol object
lifetime, and frees the ivi-id by destroying the ivi_layout_surface
from both wl_surface and ivi_surface destruction as the protocol specifies.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Removed duplicate definitions of the container_of() macro and
refactored sources to use the single implementation.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
To help reduce code duplication and also 'kitchen-sink' includes
the ARRAY_LENGTH macro was moved to a stand-alone file and
referenced from the sources consuming it. Other macros will be
added in subsequent passes.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Using the parent '../' path component in #include statements makes
the codebase more rigid and is redundant due to proper -I use.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Whether a input method is used should be the responsibility
of the shell because some shells may not want to implement
an input method at all
Signed-off-by: Murray Calavera <murray.calavera@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
