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

[Nobuhiko Tanibata]

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.
> 
> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel