[RFC] Common layout library for surfaces in a shell

Tue Dec 10 01:47:36 PST 2013

Hi Nobuhiko-san,

I want to provide some feedback from GENIVI and IVI LayerManagement perspective.
Please find my comments inline.

BR, Timo
-- 
BMW Car IT GmbH
Timo Lotterbach
Spezialist Entwicklung
Petuelring 116
80809 München

Tel.:  +49 89 189311-77
Fax:  +49 89 189311-20
Mail: timo.lotterbach at bmw-carit.de
Web: http://www.bmw-carit.de
----------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Michael Würtenberger und Reinhard Stolle
Sitz und Registergericht: München HRB 134810
----------------------------------------------------------------------

> -----Original Message-----
> From: Tanibata, Nobuhiko (ADITJ/SWG) [mailto:ntanibata at jp.adit-jv.com]
> Sent: Tuesday, December 03, 2013 1:42 AM
> To: wayland-devel at lists.freedesktop.org
> Cc: Michael.Schuldt at bmw.de; Timo Lotterbach; Ishikawa, Tetsuri
> (ADITJ/SWG)
> Subject: [RFC] Common layout library for surfaces in a shell
> 
> Hi Wayland developers,
> 
> In reply to,
> http://lists.freedesktop.org/archives/wayland-devel/2013-
> September/011026.html
> I realign comments. This is more or less a RFC and any input would be very
> much appreciated.
> 
> When I think developing a shell referring Weston for ivi system, I face two
> difficulties. If a solution to solve these two difficulties, it may be useful for ivi
> shall developers. I am not sure that it is only for ivi so it may apply other types
> of system as well.
> 
> The first difficulty is that laying out surfaces by using Weston internal
> method. For the time being, I have to implement e.g. positioning surfaces by
> using Weston internal APIs. Additionally, ivi system often uses layer concept
> to group surfaces. If APIs standardizing management of structure: screen-
> >layer->surface and properties; position, visibility, and son are available, it
> might be helpful to reduce effort to devloper ivi type shell.

[TL] From my perspective, implementing ilmControl.so it's exactly the way to go.
We need to map IVI-style scene setups (screens/layers/surfaces) to Weston
internal scene setup. This mapping is independent of shell behavior and should
only be implemented once.

> One example of such APIs is ivi layer manager, http://projects.genivi.org/ivi-
> layer-management/
> It works outside of compositor but the set of definition can be used to define
> standard APIs for ivi-shell as well.

[TL] I agree. The IVI LayerManagement API is proven to work and supports all
Features currently required by IVI systems. Therefore I consider it a good starting point.

> The second difficulty is that Identifying specific surfaces in a shell. For
> example, such surfaces will be used by specific application like car navigation
> and traffic information. These surfaces need to be laid out, e.g. top level by
> shell when some request happens in the system, for example, switching
> “destination” in the panel or on the steering. It is not done by touch of the
> surface. So these surfaces are identified by shell internally.

[TL] I fully agree to this.
I want to provide some more background on IVI Use Cases.
In IVI systems there are mainly two ways to setup compositing, and both rely on
identifying semantics of application content
(e.g. Navigation, HMI, Browser, Camera Assistance Systems, ...):

1. Compositor knows content/buffer sematics and composes screen content
     according to built-in ruleset (e.g. HMI always in front of Navigation, Browser
     runs in fullscreen mode without HMI, ...)
2. External process controls compositing (e.g. HMI-software). Then the external
     controller must know content/buffer semantics. Additionally a way of
     referencing surfaces from other processes is required.

To allow referencing or identifying surfaces of other processes, we rely on
globally known predefined IDs (e.g. surface 0x1000 = Browser) 

> If Weston has standard way to resolve these two difficulties, it might be
> helpful. Detail parts of proposals are,
> 1.	I am enclosing a png file to show overview of related component. I
> plan to implement “ilmControl.so” to standardize APIs, now is raughly
> implemeted. The name of library and APIs need to be brushed up more.

[TL] Yes, we should find a better name. I would prefer Weston-style naming.

> 2.	Protocol to identify a surface in shell. Genivi ivi layer manger project
> define a reference of the protocol as ivi-application.xml. It can tie Global ID to
> wl_surface.
> -	http://git.projects.genivi.org/?p=wayland-ivi-
> extension.git;a=blob;f=protocol/ivi-
> application.xml;h=aeeeba2267ecb549a43b6a2b4517b257cd66885e;hb=0d8f0
> d36d1696a657426a5bda1342c3743d08a7c (*1)

[TL] Yes, this is mandatory for nearly all IVI Compositing solutions out there.
One of the basic building blocks for Weston IVI-Shell.

> -	To identify wl_surface, I thought wl_shell_surface::set_title can be
> used it. However wl_shell is desktop style, it shall not be used for ivi-shell.
> -	You also find ivi_surface.visibility. We had a discussion that
> wl_surface::frame can be used to recognize timing of invisibility. However, I
> think we can not distinguish exact timing of invisibility or delay due to busy of
> GPU. This needs more feedback.

[TL] Omitting the explicit visibility events would require all client applications to
implement a "visibility detection" on their own. Since the Compositor already
has the information, it can just send the event. This is standard for existing
IVI Compositing solutions.

Some IVI Background:
If a surfaces gets invisibile, the corresponding IVI application receives the
visibility=false event and can react in different ways:
- stop rendering (e.g. Reverse Camera)
- free resources (e.g. splash-screen)
- render at reduced framerate (e.g. Navigation)

> These two proposals may be common for ivi system and may be beneficial as
> reference. For ivi-shell.so, I can share implementation of a simple reference
> how to use ilmControl.so and realize simple IVI layout. Or bringing spec of
> other window manager e.g. tizen ivi is another option with Murphy(*2)

[TL] I fully support both of your proposals, since both are mandatory for
supporting existing IVI applications.

> (*1) wayland-ivi-extension v1 supports ivi-shell implementation of ivi-
> application.xml and controller.xml. Controller.xml might not be shared with
> Wayland because it is done by outside of Weston process. However the
> protocol is important for backward compatibility with Genivi Layer manager
> APIs.
> (*2) https://01.org/projects/murphy in png is Policy manager which can be
> collaborate with PulseAudio, Weston, or whichever you want to control.
> 
> Best regards,
> Nobuhiko
> 
> ---------------------------------------------------------
> Advanced Driver Information Technology Nobuhiko Tanibata / 谷端 伸彦
> Senior Engineer, Software Group
> 1-1 Showa-cho Kariya-shi, Aichi-ken Japan 448-8661
> TEL: +81-(0)-566-61-5669, INTERNAL: 551-43643
> FAX: +81-(0)-566-25-4774
> E-mail: ntanibata at jp.adit-jv.com
> ADIT is joint venture company of DENSO Corporation and Bosch GmbH
> ---------------------------------------------------------