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