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

Pekka Paalanen ppaalanen at gmail.com
Mon Jul 7 00:58:12 PDT 2014


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)?


Thanks,
pq


More information about the wayland-devel mailing list