[RFC] Common layout library for surfaces in a shell
Tanibata, Nobuhiko (ADITJ/SWG)
ntanibata at jp.adit-jv.com
Mon Dec 2 16:42:28 PST 2013
Hi Wayland developers,
In reply to,
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.
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.
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.
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.
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=0d8f0d36d1696a657426a5bda1342c3743d08a7c (*1)
- 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.
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)
(*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.
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
E-mail: ntanibata at jp.adit-jv.com
ADIT is joint venture company of DENSO Corporation and Bosch GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 18625 bytes
More information about the wayland-devel