[PATCH weston 0/6] ivi-shell proposal

[Nobuhiko Tanibata]

Hi,

Thank you for feedcak. Please see my inline comments.

Best regard,
Tanibata

----- Original Message ----- 
From: Andreas Pokorny
To: Nobuhiko Tanibata
Cc: wayland-devel at lists.freedesktop.org ; securitycheck at denso.co.jp
Sent: Thursday, September 05, 2013 5:34 AM
Subject: Re: [PATCH weston 0/6] ivi-shell proposal


Hi,

Overall I like that genivi is now a lot more accessible/visible from the 
outside. I understand the necessity of dealing with layers on a lower level 
to make use of the efficient blending of display controllers. But that logic 
should be only implemented within the compositor. Clients should not deal 
with the set of available layers - their position / size or orientation on 
screen.

NT: In the case of automotive, a HMI controller ususally manages surfaces 
and layers. If Weston is only a compostiro on system, implementing them 
within compsitor should be fine. On the other use case of automotive, it has 
a use case of having several backends in a one system to ensure truct zone 
or domain separation. E.g. assign an own proprietary backend to a phsical 
plane. I think common apis like Genivi LM might be helpful to controll all 
of them by one set of APIs.

Configuration changes are far more simpler (read: flicker free) to implement 
when those are only done in one process, with wayland that would be the 
compositor. In the case of automotive devices the compositor should also be 
responsible for drawing the main user interface. So the compositor would be 
well aware of the current scene assembly - like displayed applications. The 
applications would only deal with providing buffer content.

NT: Yes, you are collect. a compositor shall be responsible for ficker free. 
Via ivi protocol, attributes can be set. However, compositor still can takes 
cares of e.g. how to move a surface from one to another without ficker. In 
the future, I think a plugin model might be helpful to define the behavior 
of transition as add-on.

In the end integrating navigation, camera 3rd party application windows 
(instead of layers) should be a lot easier.


regards
Andreas




2013/9/4 Nobuhiko Tanibata <NOBUHIKO_TANIBATA at xddp.denso.co.jp>

Hi,

This series implements ivi-shell to fulfill use cases of In-Vehicle 
Infotainment, IVI. Such use cases are well overviewed in a project; Genivi 
IVI layer management.
http://projects.genivi.org/ivi-layer-management/node/13

A motivation of this series and basis idea are introduced by Ossama at 
Automotive Linux Summit 2012 spring. The series implements ivi-shell part. 
Additionally, GENIVI LM Client Library at slide 20 is contributed to 
ivi-layer-management project to support compatible interfaces for Genivi 
Layer management users.
http://events.linuxfoundation.org/images/stories/pdf/als2012_othman.pdf

Before I start implementation of ivi-shell, Core members of Genivi IVI layer 
management defined draft of ivi-shell.xml to fulfill requirements of IVI 
layer management, inviting Kristian. The series also includes the 
ivi-shell.xml with updates I faced in actual implementation.

Please give me any suggestions.

Best regards,
Tanibata

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel