[RFC] Common layout library for surfaces in a shell
Tanibata, Nobuhiko (ADITJ/SWG)
ntanibata at jp.adit-jv.com
Thu Dec 12 06:44:12 PST 2013
Hi Timo,
Thank you for input!
@other members,
Any input would be very much appreciated as well.
Now I am also enclosing a link of PoC to implement Common Layout library named libweston-layout.so temporarily.
https://github.com/ntanibata/weston-ivi-shell/tree/weston-layout-v1
If you can try it and feedback, it would be helpful for me.
Overview of PoC
- Common Layout library: weston-layout.h having comments per method and weston-layout.c provides implementation.
Layouting surface is done by weston_matrix to realize opacity, orientation,,,,inside of each interface. I think weston-layout library might be helpful to develop own shell without many steps.
https://github.com/ntanibata/weston-ivi-shell/commit/7a6a4d26a747fb6cd106ff50f2227e6ba6b9103d
- hmi-controller.so is a reference to show how to use waston-layout. I implement 4 kinds of layout, tiling, side by side, full screen, and random. I attach a screenshot of tiling example.
https://github.com/ntanibata/weston-ivi-shell/commit/797ff8e1601d920c1fb2dec0a2bf2023a7038ee1
- hmi-client is a reference draws the UI has switches to inform modes to hmi-controller to change layout.
https://github.com/ntanibata/weston-ivi-shell/commit/7a6a4d26a747fb6cd106ff50f2227e6ba6b9103d
BR,
Nobuhiko
> -----Original Message-----
> From: Timo Lotterbach [mailto:Timo.Lotterbach at bmw-carit.de]
> Sent: Tuesday, December 10, 2013 6:48 PM
> To: Tanibata, Nobuhiko (ADITJ/SWG);
> wayland-devel at lists.freedesktop.org
> Cc: Michael.Schuldt at bmw.de; Ishikawa, Tetsuri (ADITJ/SWG)
> Subject: RE: [RFC] Common layout library for surfaces in a shell
>
> 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
> > >layer->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.
[NT] Yes, my motivation is that if such a common layout library is maintaind as adaptation layer to keep compatible with different version of weston.
>
> > 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.
[NT] Name: libweston-layout.so might be one of options. I also add a proposal at the top of this email.
>
> > 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
> > ---------------------------------------------------------
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wayland-screenshot.jpg
Type: image/jpeg
Size: 203060 bytes
Desc: wayland-screenshot.jpg
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131212/41f6afa9/attachment-0001.jpg>
More information about the wayland-devel
mailing list