On Tue, 20 May 2014 18:57:46 +0900 Nobuhiko Tanibata <[email protected]> wrote:
> 2014-04-25 20:38 に Pekka Paalanen さんは書きました: > > On Mon, 17 Mar 2014 15:28:22 +0900 > > Nobuhiko Tanibata <[email protected]> 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 <[email protected]> > >> --- > >> > >> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
