[PATCH weston-ivi-shell v4 5/9] A reference implementation how to use weston-layout library.

[Nobuhiko Tanibata]

2014-07-07 16:58 に Pekka Paalanen さんは書きました:
> On Tue, 20 May 2014 18:57:46 +0900
> Nobuhiko Tanibata <nobuhiko_tanibata at xddp.denso.co.jp> wrote:
> 
>> 2014-04-25 20:38 に Pekka Paalanen さんは書きました:
>> > On Mon, 17 Mar 2014 15:28:22 +0900
>> > Nobuhiko Tanibata <NOBUHIKO_TANIBATA at 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_TANIBATA at 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.
> 
> Umm, my question was about Weston vs. gnome-shell vs. KWin vs. ...,
> not really about weston-on-x11 vs. weston-on-drm vs.
> weston-on-whatever.
> 
> Other compositors have none of the weston_* structs, nor
> anything weston's compositor.h defines.
> 
> Can the API depend on Weston definitions, or is it going to be
> compositor-agnostic and work if your compositor happens to be e.g.
> gnome-shell (if implemented)?
> 

Hi pq,

I expect weston would be qualified by distribution, e.g. TIZEN IVI. So I 
prefer concentrating a shell part like ivi-shell to archive ivi use 
cases based on compositor APIs.

BR,
ntanibata

> 
> Thanks,
> pq