[PATCH weston 0/6] ivi-shell proposal

[Pekka Paalanen]

On Fri, 6 Sep 2013 08:39:24 +0900
"Nobuhiko Tanibata" <NOBUHIKO_TANIBATA at xddp.denso.co.jp> wrote:

> ----- Original Message ----- 
> From: "Pekka Paalanen" <ppaalanen at gmail.com>
> To: "Nobuhiko Tanibata" <NOBUHIKO_TANIBATA at xddp.denso.co.jp>
> Cc: <wayland-devel at lists.freedesktop.org>; <securitycheck at denso.co.jp>
> Sent: Thursday, September 05, 2013 10:02 PM
> Subject: Re: [PATCH weston 0/6] ivi-shell proposal
> 
> 
> > On Wed, 4 Sep 2013 09:08:26 +0900
> > "Nobuhiko Tanibata" <NOBUHIKO_TANIBATA at xddp.denso.co.jp> wrote:
> >
> >> Hi,
> >>
> >> This series implements ivi-shell to fulfill use cases of In-Vehicle
> >> Infotainment, IVI. Such use cases are well overviewed in a project;
> >> Genivi IVI layer management.
> >> http://projects.genivi.org/ivi-layer-management/node/13
> >>
> >> A motivation of this series and basis idea are introduced by Ossama
> >> at Automotive Linux Summit 2012 spring. The series implements
> >> ivi-shell part. Additionally, GENIVI LM Client Library at slide 20 is
> >> contributed to ivi-layer-management project to support compatible
> >> interfaces for Genivi Layer management users.
> >> http://events.linuxfoundation.org/images/stories/pdf/als2012_othman.pdf
> >>
> >> Before I start implementation of ivi-shell, Core members of Genivi
> >> IVI layer management defined draft of ivi-shell.xml to fulfill
> >> requirements of IVI layer management, inviting Kristian. The series
> >> also includes the ivi-shell.xml with updates I faced in actual
> >> implementation.
> >>
> >> Please give me any suggestions.
> >
> > Hi,
> >
> > I have understood that the whole design has been cut deep into stone a
> > long time ago. What are you able to change now? I do not think it is
> > worth commenting on things you can no longer change, so what aspects are
> > you looking suggestions for?
> >
> 
> 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. 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. Roundtrips and synchronous
calls between processes can become a difficult bottle-neck, as X11
has taught us. Also having too many processes becomes a real mess
when trying to avoid deadlocks but still keep things coherent and
glitch-free (see X11 server vs. window manager vs. ...).

So I'm roughly on the same track as Andreas Pokorny.

Weston should become the window manager and layer manager, while
weston backends deal with the hardware details of compositing. For
example, the Raspberry Pi backend of Weston forwards all
compositing to the VideoCore firmware, unlike any other backend
who actually render a composite themselves. However, the rpi
backend does not forward all surfaces to VideoCore all the time,
but only the visible ones as needed. And Weston is the only
component that *can* know what is visible at any time, since Weston
contains the complete scene graph. Weston's internal architecture
is also well-suited for *automatically* deciding how to use the
limited hardware resources like overlays efficiently, and fall back
as necessary, per each output frame. You cannot do that, if you
tell applications about specific hardware resources.

I suspect there might be some terminology differences here.
Something like what IVI calls a "compositor" is a "weston backend"
when talking about Weston and Wayland, and IVI layer manager is
actually a window manager which is just a shell plugin to Weston.
Or am I completely off?

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.

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.

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.

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?

- 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?

These are just few questions to get you oriented on what kind of
things puzzle me here. Obviously, I have never been in touch with
Genivi stuff before, and I would assume most here have not either.

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?


The above is the first impression from someone, who does not know
anything about the IVI architecture, but is fairly familiar with
Wayland. Sorry if it came out harsh, but I feel like I totally
missed the whole background of this proposal: why design it like
that?


Cheers,
pq