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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Giulio Camuffo
Pekka Paalanen
Bryce Harrington
Yong Bakos
Wataru Natsume
Ucan, Emre (ADITG/SW1)
Mateusz Polrola
Nobuhiko Tanibata