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>
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>
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>
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>
Jussi Kukkonen