[PATCH weston 00/14] Desktop Protocol Support for IVI-Shell

Wed Oct 25 15:19:10 UTC 2017

Hi Pekka,

Thank you for your mail. The answers can be found inline. I also attached some slides I did for the AGL AMM in Dresden, where I talked about my changes.

Best regards

Michael Teyfel
Engineering Software Base (ADITG/ESB)

Tel. +49 5121 49 6932

> -----Original Message-----
> From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> Sent: Mittwoch, 25. Oktober 2017 09:09
> To: Matt Hoosier; Teyfel, Michael (ADITG/ESB)
> Cc: Ucan, Emre (ADITG/ESB); wayland-devel at lists.freedesktop.org
> Subject: Re: [PATCH weston 00/14] Desktop Protocol Support for IVI-Shell
> 
> On Tue, 24 Oct 2017 09:08:19 -0500
> Matt Hoosier <matt.hoosier at gmail.com> 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.

 [Teyfel, Michael (ADITG/SW1)] 
Please refer to the slides. We want to ensure that all mandatory features of xdg-protocol should be supported. In the end there won't be a support of desktop applications to a full extent but in a way that meets the requirements of ivi-systems. So to speak the behavior may be different in some cases and the reasoning of ivi-system being different is still valid from our perspective. Our main goal is to support the xdg protocol not to be a fully blown desktop shell.

> 
> 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.
> 
[Teyfel, Michael (ADITG/SW1)] 
You are right, we may not support all functionality of a desktop applications but we take care to support all the mandatory events and request.

> How will that be possible without specifically writing the applications to
> behave in IVI-specific ways?
[Teyfel, Michael (ADITG/SW1)] 
We have 2 core features in ivi-shell: an id agent, which will be located in the wayland-ivi-extension repository soon, and the layout protocol.

> 
> 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.
[Teyfel, Michael (ADITG/SW1)] 
We only used the concept of X11 of having the window manager outside of the compositor. There might be a risk of people using it like you assumed, but in the end the project has the opportunity to decide, if the window manager is inside or outside of the compositor. For example in our case it is not favorable to keep the window manager inside of the compositor. This is due to our focus on ivi-systems, where the requirements differ from project to project, which forces us to stick to our current architecture.  

> 
> 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.
[Teyfel, Michael (ADITG/SW1)]
Well, you are right. There is no id-agent in this repository, but there will be a reference implementation of the id-agent in the wayland-ivi-extension repository soon. For the Weston repository we decided not to add the id-agent and changed the hmi-controller accordingly. You are able to test the changes by means of hmi-controller.

> 
> 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?).
> 
> 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.
[Teyfel, Michael (ADITG/SW1)] 
The ivi-controller is not bypassed and is still able to control every surface whether it is generated by an ivi-application or a desktop-application. Please look at slide 9. You can see that the id-agent is crucial / mandatory for ivi-controller. Hmi-controller on the other side acts differently and an id-agent is not mandatory for it.

> 
> 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?
> 
[Teyfel, Michael (ADITG/SW1)] 
Yes, it is mixing both.

> 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?
[Teyfel, Michael (ADITG/SW1)] 
Please refer to slide 11. We aim to support xdg-protocol, which means we are moving the id generation from the application to the compositor. This enables us to use existing frameworks without alternation (e.g. gstreamer). You are right, xdg protocol apps for ivi-systems might behave differently than normal desktop applications.  But these changes will make it easier for app developers to write applications  for ivi-systems, for us it is easier to use existing frameworks and also the id generation is moved to the compositor. The benefit of a central id agent is that we are able to handle the ids of all applications in one location and you could also add policies about which applications are allowed to show content and which not.

> 
> 
> Thanks,
> pq
> 
> > On Tue, Oct 17, 2017 at 5:51 AM, Ucan, Emre (ADITG/ESB) <
> > eucan at de.adit-jv.com> wrote:
> >
> > > Hi,
> > >
> > > I already reviewed the patches before Michael sent:
> > > Reviewed-by: Emre Ucan <eucan at de.adit-jv.com>
> > >
> > > Best regards
> > >
> > > Emre Ucan
> > > Engineering Software Base (ADITG/ESB)
> > >
> > > Tel. +49 5121 49 6937
> > >
> > > > -----Original Message-----
> > > > From: wayland-devel [mailto:wayland-devel-
> > > > bounces at lists.freedesktop.org] On Behalf Of Michael Teyfel
> > > > Sent: Dienstag, 17. Oktober 2017 12:02
> > > > To: wayland-devel at lists.freedesktop.org
> > > > 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.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: AGL_AMM_XDG_Shell_Support_Michael_Teyfel.pdf
Type: application/pdf
Size: 362382 bytes
Desc: AGL_AMM_XDG_Shell_Support_Michael_Teyfel.pdf
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171025/39e9eb30/attachment-0001.pdf>