Hi Manuel-san and Dominig-san, "If community allows us to support multiple shell in one compositor and xdg-shell became standard shell in Weston, I can support fall back feature to xdg_shell when client doesn't support ivi-application. In this case, get_xdg_surface and other main protocol can be supported."
>That would be great ! Thanks a lot for your proposal. (regarding upstream >XDG-Shell, it is supposed to be totally stabilized in Weston 1.7. I >effectively have read messages were it was said that xdg-shell would replace >wl_shell someday ; the current pro is that it has a lot more features). Please let me know your ideas; It is acceptable by community? Ivi-shell supports ivi-application.xml and some parts of xdg-shell.xml? BR, Nobuhiko Tanibata From: Manuel Bachmann [mailto:[email protected]] Sent: Monday, September 15, 2014 8:49 PM To: Tanibata, Nobuhiko (ADITJ/SWG) Cc: Counihan, Tom; Dominig ar Foll (Intel OTC); [email protected]; Ishikawa, Tetsuri (ADITJ/SWG) Subject: Re: [RFC] IVI-Shell, Wayland, and middleware API unification Hi Janos, Tanibata-San, and thanks for your very detailed responses ! Janos, "In the ICO paradigm applications should not be able to show themselves, get on the top, or go full-size unconditionally, without the approval of the managing authority, ie. the HomeScreen /system-controller. From this respect executing those request unconditionally in IVI shell does not appear to be very wise. Those request should be forwarded to the managing authority for consideration rather than execute them unconditionally. The ivi-controller interface is quite suitable for this." "do not implement any hardwired policies for the wl- and xdg-shell calls, eg. map the xdg_surface_set_minimized => ivi_layout_surfaceSetVisibility, deliver the requests to the managing authority over ivi-controller interface." Thanks to your answer, I think I understand ; and this explains better the separation between the "ivi-shell" and "ivi-layout" modules. The map call of "xdg_surface_set_minimized()" was arbitray on my part, and could very well be delivered to ivi-controller component as you describe. I will take a look at it ; until then, I just disabled the call in my code base. "convince upstream folks about the multiple shell support (once it has been already there but it was removed). If GENIVI folks do not want it we could make the wl- and/or xdg-shell support as compile-time option." Sure, a flag such as "--enable-xdg-shell" or "--enable-xdg-wrapper" could easily be implemented. I also get the feeling that this would help ICO integration in the future (because if I understand correctly, wl_shell support in only in the Tizen repository currently ; having a fallback shell upstream would reduce the delta). But Tanibata-San, who develops and maintains IVI-Shell, may also have an opinion on this :-). Tanibata-San, " - If xdg-shell support, I would be great to merge them into one. - ivi-application.surface_create(ivi_id,surface) to map ID with wl_surface - allow to load ivi-layout module to add ivi-features. - security model not to allow client application to use a part of xdg-shell protocol; interface to control e.g. position/size like xdg_surface_set_minimized. - In the future, ivi-controller shall be bound by only authorized manager like murphy or else. This is one of suggestion from Intel graphic engineer you may know." Such a model may be elegant but also complicated for a first step. Regardind ivi-controller and murphy, I will take a look at it. "If community allows us to support multiple shell in one compositor and xdg-shell became standard shell in Weston, I can support fall back feature to xdg_shell when client doesn't support ivi-application. In this case, get_xdg_surface and other main protocol can be supported." That would be great ! Thanks a lot for your proposal. (regarding upstream XDG-Shell, it is supposed to be totally stabilized in Weston 1.7. I effectively have read messages were it was said that xdg-shell would replace wl_shell someday ; the current pro is that it has a lot more features). "But other interface to control position or resize of the shell surface shall not be supported because of security reason e.g. application can control." I totally understand your concern of not allowing direct access to the shell surface. It was an error on my side. I just disabled the call to "ivi_layout_surface_set_Visibility" in the demo code (https://github.com/Tarnyko/weston-ivi-shell/commit/1e121f1e1a55553b6e1aa9afc7f73f06f774270a) so people do not get confused by this. Best regarrds, 2014-09-15 2:29 GMT+02:00 Tanibata, Nobuhiko (ADITJ/SWG) <[email protected]>: Hi Manual-san, Tom-san, Janos-san and Dominig-san, Motivation of IVI-shell(ivi-application+ivi-layout internal apis)+ivi-controller is to fit requirement and use case in automotive, GENIVI. So if a proposal can cover it, I think there is no concerning from GENIVI. Use case - Layer/surface can be identified by Numeric ID. In automotive, it shall be under stringently control by e.g. car maker to avoid malware. - ivi-controller interface shall be bound by only authorized central controller. Ivi-application protocol and ivi-controller protocol shall be divided into two. I think the second is a little mentioned by Janos-san feedback. So my proposal if I take account into Manual-san suggestion. - If xdg-shell support, I would be great to merge them into one. - ivi-application.surface_create(ivi_id,surface) to map ID with wl_surface - allow to load ivi-layout module to add ivi-features. - security model not to allow client application to use a part of xdg-shell protocol; interface to control e.g. position/size like xdg_surface_set_minimized. - In the future, ivi-controller shall be bound by only authorized manager like murphy or else. This is one of suggestion from Intel graphic engineer you may know. Another option is the same as Janos-san, If community allows us to support multiple shell in one compositor and xdg-shell became standard shell in Weston, I can support fall back feature to xdg_shell when client doesn't support ivi-application. In this case, get_xdg_surface and other main protocol can be supported. But other interface to control position or resize of the shell surface shall not be supported because of security reason e.g. application can control them by itself. BR, Nobuhiko Tanibata > -----Original Message----- > From: IVI [mailto:[email protected]] On Behalf Of Counihan, Tom > Sent: Saturday, September 13, 2014 1:06 AM > To: Dominig ar Foll (Intel OTC); [email protected] > Subject: RE: [RFC] IVI-Shell, Wayland, and middleware API unification > > Hi Dominig, > > > -----Original Message----- > > From: IVI [mailto:[email protected]] On Behalf Of Dominig ar > > Foll (Intel OTC) > > Sent: Friday, September 12, 2014 2:55 PM > > To: [email protected] > > Subject: Re: [RFC] IVI-Shell, Wayland, and middleware API unification > > > > Tom, > > > > our motivation in investigating such option is driven by the fact that > > the acceptance of the IVI shell by the Wayland/Weston community, in > > view of its integration upstream, is at best fairly remote at worse > > unlikely, while XDG has already been adopted by the community and accepted > upstream. > > The motivation has logic based upon the assumption you describe. However, > when observing the wayland traffic, particularly the great work Manuel and > Tanibata have been pushing, I came away with a different opinion re upstream > acceptance. > I confess I could be totally wrong, but would gladly take your input to correct > my understanding - the "worse unlikely" is a pretty grave scenario. Can you > direct me to where you base your opinion on? Did you mean for a particular > version, or in general you are skeptical of upstream acceptance? > > > > > > Manuel proposition would enable to expand the compatibility of Genivi > > (IVI-shell) to standard application. > > The immediate interesting side effect is that tool kit such as Ozone > > (crosswalk), efl or qt could work out of the box with their XDG extensions. > > I was under the impression that Ozone was receiving some ivi shell support > - which would be very useful? Am I wrong? > https://github.com/01org/ozone-wayland/commit/a034a018b6ec317ec5559dcce6 > efec916ec40512 > > > > > I personally only see benefit, but a sorer look from a greater > > community is valuable as we might have missed some hidden side effect. > > Janos has followed with a compressive reply after this mail. > > Warm Regards > Tom. > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 Business address: Dromore House, East Park, > Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please contact > the sender and delete all copies. > > > _______________________________________________ > IVI mailing list > [email protected] > https://lists.tizen.org/listinfo/ivi _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi -- Regards, Manuel BACHMANN Tizen Project VANNES-FR _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
