Hi Pekka, My comments are below. I will mark them as [Emre] and [/Emre]. Sorry about improper formatting (outlook).
Thanks, Emre -----Original Message----- From: Pekka Paalanen [mailto:[email protected]] Sent: Mittwoch, 25. Oktober 2017 09:09 To: Matt Hoosier; Teyfel, Michael (ADITG/ESB) Cc: Ucan, Emre (ADITG/ESB); [email protected] Subject: Re: [PATCH weston 00/14] Desktop Protocol Support for IVI-Shell On Tue, 24 Oct 2017 09:08:19 -0500 Matt Hoosier <[email protected]> wrote: > I'm not at all familiar with the internal implementation of ivi-shell, > so I can't give much meaningful review. But I am very much in favor of > this patch series. Without wl_shell and xdg_shell support, I've never > been able to really give ivi-shell serious consideration on my > products. The ability to use generic client Wayland programs is very > important. Hi, the very reason why ivi-shell ever came to be was that the operating environment of graphical applications in IVI was so different from a normal desktop, that it was simply impossible to have desktop applications work in a meaningful way there. I would like to hear why and how this has now changed. [Emre] In my opinion, they are not that different. The requirement to have an external window manager to control application content is specific to IVI systems. We need unique surface ids to be able to control surfaces from outside, and this is entire point of ivi-application protocol. But we have to change every existing wayland application, framework and gstreamer plugin to support IVI-shell. This is not feasible. Instead we can assign IDs in compositor with id-agent. [/Emre] The premise of supporting desktop shell protocols in an IVI-shell environment is that all desktop applications using the full extent of the desktop shell protocols will always work correctly and meaningfully, without modification. [Emre] Most of the applications would just work fine. It is much better than not supporting them at all. [/Emre] How will that be possible without specifically writing the applications to behave in IVI-specific ways? Assuming the above is possible, I also see the risk that lego-block desktop environments will start using ivi-shell to push window management into an external process, undoing a lot of the benefits of a Wayland architecture simply because that is how X11 worked. [Emre] They can do it anyway using libweston and libweston-desktop with or without ivi-controller protocol.[/Emre] When I glanced through the proposal, I didn't find an example implementation of the most important new component introduced: the ivi-surface id agent. Hence I do not think it is possible to fully evaluate this work as is. [Emre] We have a PoC implementation for id-agent which only reads ID and window title pairs, and sets it. But I don't think we need to have it in Weston repository. One can use ivi-shell without surface-IDs. HMI controller does not need IDs for example. [\Emre] I don't even understand how it can show desktop shell protocol using windows at all without an id agent - I believe it should not, because if it does, then it is bypassing the IVI controller which I cannot imagine to be a wanted feature. Simply the fact that it is using libweston-desktop means that the IVI controller cannot manage all the surfaces (libweston-desktop exposes only top-level windows and handles everything else internally - how could the internal handling be always correct in an IVI environment?). [Emre] Controller plugins are still responsible to make a surface visible on the screen. You are definitely right that some applications can cause problem in an IVI system. It is but still better than not supporting desktop protocols. We can choose which application should run in the system. [\Emre] IMO, an id agent should be mandatory. Otherwise it is too easy to just forget about it and trust your luck that the desktop apps and libweston-desktop will keep on behaving as you happened to test and that the behaviour would be appropriate in an IVI environment to begin with. [Emre] In my opinion, it should not be mandatory. In future maybe, we could get rid of external window manager. HMI controller plugin works just fine without an id-agent. On the otherhand, IVI-controller would just ignore surfaces without IDs. Therefore, you cannot just try your luck. [\Emre] If you proposed that e.g. some outputs were dedicated for desktop apps and some outputs for IVI apps, then I could see it working without complete IVI controller integration, as the two categories would be kept separate. It would be like running a desktop compositor on some outputs and an IVI compositor on the other outputs (which is actually implementable real soon now thanks to DRM leases, or already with fullscreen-shell protocol). But as I understand, this proposal is aiming to mix both kinds of apps on the same outputs, is it not? [Emre] This won't fix our problem. I cannot say to HMI developers that they are allowed to put video content only on one display, because waylandsink or vaapisink is only supporting desktop protocols. If this proposal will be accepted, I want to also deprecate ivi-application protocol entirely. [/Emre] I am confused how this proposal is a proper solution, as I'm not sure what the problem to be solved is. Why do you want to run desktop apps on an IVI system instead of apps that are designed for work right in an IVI system? [Emre] Applications are the smaller part of the problem. You are right that the most of automotive applications are IVI specific implementations. But gstreamer plugins and frameworks are more important. I cannot modify every gstreamer sink plugin which exist on the planet. Desktop protocols are standard which we have to follow. Actually, IMO ivi-shell is not a proper wayland compositor. Because it is violating wayland protocol by not supporting wl_shell interface. Therefore, we have to at least support wl_shell interface in ivi-shell. Why not support it via libweston-desktop ? [\Emre] Thanks, pq > On Tue, Oct 17, 2017 at 5:51 AM, Ucan, Emre (ADITG/ESB) < > [email protected]> wrote: > > > Hi, > > > > I already reviewed the patches before Michael sent: > > Reviewed-by: Emre Ucan <[email protected]> > > > > Best regards > > > > Emre Ucan > > Engineering Software Base (ADITG/ESB) > > > > Tel. +49 5121 49 6937 > > > > > -----Original Message----- > > > From: wayland-devel [mailto:wayland-devel- > > > [email protected]] On Behalf Of Michael Teyfel > > > Sent: Dienstag, 17. Oktober 2017 12:02 > > > To: [email protected] > > > Subject: [PATCH weston 00/14] Desktop Protocol Support for > > > IVI-Shell > > > > > > Hello all, > > > > > > since some time I’m working on ivi-shell to add xdg-protocol > > > support by means of libweston-desktop. Due to my changes both > > > xdg-protocol applications and ivi-shell / ivi-application-protocol > > > applications are > > supported > > > within ivi-shell now. The known functionality is preserved and > > > just > > extended > > > by a further protocol. The advantage is that client applications > > > do not > > need to > > > be edited to generate an id and are also not limited to use the > > > custom > > ivi- > > > application protocol anymore, since the ids are handled by an id > > > agent > > inside > > > of weston now. _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
