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.
I am just trying to understand what exactly the API surface is, that
external modules like ivi-controller.so will be using. Are they allowed
to use Weston core API, ivi-shell.so exported API, only weston-layout
API?
I said it before, that I think you should pay attention to proper
versioning of the weston-layout API, or tie that to Weston core
versioning.
Again, I would suggest:
- document what APIs the external modules can use
- write a header for the API that ivi-shell.so will export for the
external modules; this would replace the weston-layout.h and be
smaller
Thank you for comments.
I prepare ivi-layout-export.h with description per API in v5.
- let ivi-shell.so export the above mentioned API, so you get rid of
the library interfaces between libweston-layout and ivi-shell; just
merge the code and remove everything that falls out by refactoring
Basically, I tried to follow your comment. However according to current
implementation
of weston, ivi-shell is loaded by dlopen without RTLD_GLOBAL. So to add
ivi-layout APIs,
I prepare ivi-layout.so as module to be loaded with RTLD_GLOBAL on
ivi-shell.
The name of "ivi-layout.so" is fixed string in ivi-shell.
That would mean external modules used libwayland-server, weston
core(?),
and the ivi-shell.so exported APIs, and not additionally depending on
yet another library libweston-layout.so.
I don't think you currently export any API from ivi-shell.so, but
external modules still depend on it anyway, by relying on it using
libweston-layout.so properly. I think it would be good to make this
dependency explicit.
Thanks.
I added key: "ivi-module" in weston.ini.in to explicitly say that
modules depends on ivi-shell and ivi-layout APIs.
BR,
Nobohiko
What do you think?
I believe it should work.
Thanks,
pq
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
