Hi,
Thank you for feedcak. Please see my inline comments.
Best regard,
Tanibata
----- Original Message -----
From: Andreas Pokorny
To: Nobuhiko Tanibata
Cc: [email protected] ; [email protected]
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 <[email protected]>
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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
