2014-04-25 20:38 に Pekka Paalanen さんは書きました:
> On Mon, 17 Mar 2014 15:28:22 +0900
> Nobuhiko Tanibata <nobuhiko_tanib...@xddp.denso.co.jp> wrote:
>
>> The library is used to manage layout of surfaces/layers. Layout change
>> is
>> triggered by ivi-hmi-controller protocol, ivi-hmi-controller.xml. A
>> reference
>> how to use the protocol, see hmi-controller-homescreen.
>>
>> In-Vehicle Infotainment system usually manage properties of
>> surfaces/layers
>> by only a central component which decide where surfaces/layers shall
>> be. This
>> reference show examples to implement the central component as a module
>> of
>> weston.
>>
>> Default Scene graph of UI is defined in hmi_controller_create. It
>> consists of
>> - In the bottom, a base layer to group surfaces of background, panel,
>> and buttons
>> - Next, a application layer to show application surfaces.
>> - Workspace background layer to show a surface of background image.
>> - Workspace layer to show launcher to launch application with icons.
>> Paths to
>> binary and icon are defined in weston.ini. The width of this layer
>> is longer
>> than the size of screen because a workspace has several pages and is
>> controlled by motion of input.
>>
>> Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanib...@xddp.denso.co.jp>
>> ---
>>
>> Changes for v2:
>> - squash Makefile to this patch
>>
>> Changes for v3 and v4
>> - nothing. Version number aligned to the first patch
>>
>> ivi-shell/.gitignore | 7 +
>> ivi-shell/Makefile.am | 19 +-
>> ivi-shell/hmi-controller.c | 1775
>> ++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 1799 insertions(+), 2 deletions(-)
>> create mode 100644 ivi-shell/.gitignore
>> create mode 100644 ivi-shell/hmi-controller.c
>
> Hi,
>
> so this is the hmi-controller. This is the part that IVI vendors will
> be customizing, is it? Or replacing, actually?
Yes. You are right. hmi-controller is just a reference how to use
ivi-layout APIs. Each IVI vendors shall customize it or implement the
same part from scratch to realize its business logic.
>
> The picture in your PDF has both ivi-controller.so and
> hmi-controller.so, where the ivi-controller.so is exposing the
> ivi-controller Wayland extension. These will be exclusive, right? Never
> used at the same time.
It depends on vendor use case. If vendor want to use ivi-controller.so
for debugging to retrieve properties of surface. it can be used with
it.
However basically, these will be exclusive.
>
> hmi-controller.so exposes the ivi_hmi_controller private Wayland
> protocol extension, right? So this patch series does not yet have the
> ivi-controller part at all, and ivi_hmi_controller is just a part of
> the demo that is hmi-controller et al.? And all that would be replaced
> by a "real" IVI thing?
Yes. it would be replaced.
>
> Oh yeah, you said the ivi-controller stuff is at
> http://git.projects.genivi.org/?p=wayland-ivi-extension.git;a=summary
>
> Okay, I'm actually happy that part is not in this patch series, the
> protocol extension looks huge. ;-)
>
> I'm not going through this patch too carefully, just making some
> general
> observations.
General observation is fine.
>
> There are lots of stuff using the weston-layout API, but I see also a
> lot stuff using Weston core API like the grab handlers and seat stuff.
> Since this is the part that vendors replace, would it not be better to
> have the Weston core related stuff back in ivi-shell.so?
>
> Or is the stuff used here such, that a real ivi-controller will not
> need it?
>
> Or is it just a work in progress to establish an abstraction and that
> part is still to do?
It is in progress. however grab handlers and seat stuff can be used as
Weston core API is.
The motivation of this parts is that,
view class is a little difficult for traditional IVI user who
implement
its UI controll by using layout APIs. So I would like to abstract such
a
APIs at first.
>
> How independent of a particular compositor implementation is the so
> called weston-layout abstraction supposed to be? Will it evolve into a
> completely compositor-agnostic API?
Compositor is independent from ivi-layout APIs. Because it is
implemented by using weston view. If weston view is independent on
compositor, e.g. drm or x11. ivi-layout API can works with any
compositor.
