[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