[PATCH weston 0/6] ivi-shell proposal

[Michael.Schuldt at bmw.de]

Hi all,

let me give some technical background on the extension, and why we have decided to design the
first approach of the extensions like it is published from Tanibata-san.
In general, we would like to get the feedback on the extensions, to get it fitting in the FOSS approach,
fulfilling the ivi requirements. See my comments in line. 

>> Hi,
>> 
>> I would like to get feedback about that if somebody has a similar
>> motivation to support ivi as well as desktop and tablet. So it is not a
>> stone, just a proposal. If somebody has good idea, I would like to use
>> it or collaborate it.
> 
> Ok, I just had the understanding that the layer manager simply has to
> be a separate process and not built into the compositor. 

Not really. Currently in the compliance from genivi, we have the separation
of Graphic Backend Server and LayerManagement. But this should now change we
want to skip that approach and want define a protocol + ivi extensions, including
a reference compositor. We have decided to use wayland + ivi extension as compositor protocol and
weston as the reference implementation for that.

> If that is
> not the case, then that is very good news indeed. Everything that
> manages surfaces, layers, windows, or whatever belongs into the
> compositor process, where they are much easier to implement and you
> don't need to introduce interfaces and IPC which are later hard to
> develop further and cause latencies. 

Sure that is the technical best fitting solution for that, we
do not want to use separate IPC for the composition approach. 
> So I'm roughly on the same track as Andreas Pokorny.

We too, but unfortunately it is not possible all the time to get
the complete user interface included in the compositor itself. We
have to guarantee fast startup time to get early video running in 2
seconds. On different systems we can not achieve that with complete HMI-UI
is up. 

> Have you tried to map your IVI concepts of surface/layer/display to
> Wayland wl_surface, wl_subsurface, and wl_output? I don't really
> see what kind of interfaces your applications (Wayland clients?)
> expect to use.
> 
> When I look at the protocol in ivi-shell.xml, I get the feeling that:
> - Interfaces ivi_layer, ivi_controller_surface,
>   ivi_controller_layer, ivi_controller_screen, and ivi_controller should
>   be internal implementation details inside the weston process, not
>   protocol. Having these as interfaces looks like the X architecture,
>   where the X server process and window manager process continuously
>   struggle to keep each other up-to-date, and carefully try to keep
>   state in sync (and fail), which also makes races and glitches
>   practically unavoidable. - Interface ivi_client is just a reinvention
>   of wl_compositor and wl_subcompositor.
> - Interface ivi_surface is a reinvention of wl_surface.

Let me explain, why this separation occurs. 
>From the ivi perspective we have separated the different applications
in ivi-client, ivi-control. 

ivi-client: Is just a client, like browser, navigation which is embedded in 
the browser. That belongs to the ivi-surface. These process have really limited
access the can just create the surface and that's all. The only important point
which the want to know is if the visibility has changed and the size to adapt
the rendered content.  A navigation should not render the content if it is not
visible or assigned to a layer. 

ivi-controller : This is the main application which is controlling the compositor
like the UI. That could be the hmi, but it can also some debug applications and
application which is triggering a screen shot of surfaces, layer, displays.
If you driving a car during the development you want to get some screenshots which
are normally triggered by an external application like the log and trace framework.

> Yes, I see there are some details to may want to control like
> surface opacity, that the current Wayland protocols do not support,
> but I don't think that replacing everything is a good way to start.
> It is also very hard to see how objects from all these interfaces are
> created, and how (if?) they associate to any other protocol objects.

On goal is to get setup a complete scenery during the startup of the
compositor. Therefore the compositor is able to just initialize the main
visible attribute during startup. That implies too that it should be possible,
without the final application is running (like navigation). Therefore we
need some logical objects like ivi-surface, ivi-layer. Which can be already
controlled, whithout a application which holds the content is already running.

> Btw. if you need support for surface scaling and cropping, there have
> been discussion on the Wayland mailing list to bring a crop & scale
> protocol extension to Wayland. It is actually necessary for efficient
> video playback etc., so pushing that forward would be nice.

Yeah I see that, and we will consider it. I think we can redesign the
approach like source and destination region to the crop and scale instead.

> After looking through the two links you gave, the ivi-shell.xml,
> and what you have wrote in the emails, I still have no clue what is
> the big picture here.
> 
> - What processes are going to use which interfaces? It looks to me
>   like some interfaces are not meant for all Wayland clients, but
>   how is it supposed to work?
> - What components are in a whole IVI system, from the point of view
>   of Wayland protocol? What are the responsibilities of each
>   component and how are these distributed into processes?

ivi-control : Is the only process which is allowed to control the compositor
itself. But they need some informations about other applications which are
running. In the ivi-domain, each graphical application has a unique ID which
is defined by the OEM or platform provider. 
ivi-client :  are just other applications like browser or navigation.

> - What does a typical IVI application do in terms of Wayland
>   protocol? Are you using wl_compositor at all? Or any other
>   Wayland core interfaces?

We were focused on just using the wayland core interface. But we are
open to extend this approach.

> The protocol you propose seems to have many references to
> "id_native" and "native content", what is all this "native" stuff
> about? Or all the integer id's you seem to be sending back and
> forth, why can't you use real protocol objects to refer to those?

This is a little bit confusing, the initial set of these objects like
it is defined here :

http://git.projects.genivi.org/?p=layer_management.git;a=blob;f=wayland-ivi-extension/protocol/ivi-shell.xml;h=6092b13ef31e55f3db338be2e471d0e956be5b9e;hb=ivi-extension

Is focused on using the ivi-surface instead of the native id. The rational behind that
is to define unique ids over the complete process space. Therefore the HMI is able
to control the different ivi-surface properties.

In the end we are very lucky about any input to get a final best fitting solution for
both the ivi aspects and the final implementation for that in the FOSS domain.

Regards

Michael.