[PATCH weston 0/8] IVI Screen refactoring

[Ucan, Emre (ADITG/SW1)]

Hi Pekka,

> -----Original Message-----
> From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> Sent: Freitag, 18. März 2016 12:24
> To: Ucan, Emre (ADITG/SW1); wataru_natsume
> Cc: wayland-devel at lists.freedesktop.org; Friedrich, Eugen (ADITG/SW1)
> Subject: Re: [PATCH weston 0/8] IVI Screen refactoring
> 
> On Thu, 17 Mar 2016 15:30:22 +0000
> "Ucan, Emre (ADITG/SW1)" <eucan at de.adit-jv.com> wrote:
> 
> > Basic idea of the patch series is to use weston_output in public APIs.
> > The controller plugins will call IVI Layout API with weston output
> > instead of ivi_layout_screen. This change simplifies the IVI Layout API
> > implementation, e.g.:
> >
> > 1. Don't need to have id_screen. Weston output already has ID.
> > 2. The screen resolution can be get from weston output directly.
> > 3. Get screns API is unnecessary, because the compositor already has a
> >    list of outputs.
> >
> > Emre Ucan (8):
> >   ivi-shell: remove id_screen
> >   ivi-shell: remove ivi_layout_get_id_of_screen API
> >   ivi-shell: remove ivi_layout_get_screen_resolution API
> >   ivi-shell: remove ivi_layout_get_screens API
> >   ivi-shell: use weston_output in public APIs
> >   ivi-shell: implement get_screen_from_output
> >   ivi-shell: remove ivi_layout_get_screen_from_id API
> >   ivi-shell: remove ivi_layout_get_screen_output API
> >
> >  ivi-shell/hmi-controller.c       |   99 +++++++--------------------
> >  ivi-shell/ivi-layout-export.h    |   62 +++--------------
> >  ivi-shell/ivi-layout.c           |  136 ++++++++++----------------------------
> >  tests/ivi_layout-internal-test.c |  125 +++++------------------------------
> >  4 files changed, 82 insertions(+), 340 deletions(-)
> >
> 
> Hi Emre,
> 
> I see this as an offical step towards removing the mid-layer called
> ivi-layout, and leaving it as a helper interface to realize the
> surface(/view)/layer/screen hierarchy. So the direction is for
> controllers to use more Weston core API rather than ivi-layout to
> eventually wrap all of Weston core API. Am I correct?

You are right. It does not make sense to wrap weston core API. The controller plugins should
use weston infrastructure as much as possible. This would increase stability and code readability.
> 
> Can I get an Acked-by from someone else (Natsume-san?) that it is ok to
> move the ivi-layout architecture in this direction?
> 
> Personally I am happy to see things going in this direction.
> 
> Some details:
> 
> - Weston will aggressively re-use output ids, and does not guarantee
>   any persistent mapping between an output (connector) and an id. Is
>   this ok, or would you need more reliable screen ids?

In an IVI system, it is important that a connector get same screen id reliably in every boot.
As you said, the output IDs are not reliable. Therefore, i want to use output names to distinguish between different connector types.
Then,  the controller plugin (i.e. ivi-controller) can set a persistent mapping for the connector types, e.g.:

HDMIA-1=3
LVDS2=99
.
.
.

I know that these names are only valid for drm-backend, and different displays could get the same output name, if you plug to the same connector.
But these restrictions are OK. Hot plugging displays are not an important use-case for us anyway.

> 
> - For get_screen_resolution, I would prefer a function for controllers
>   to call to get it. That would be the perfect place to document what
>   "screen resolution" actually means, because we have things like
>   output scale and output transform, which ivi-layout has so far just
>   assumed being identity. These parameters make the difference between
>   the coordinate systems the shell uses to lay out surfaces, and the
>   coordinate system on the monitor device. It would be ok to make this
>   a Weston core function, provided it is accurately documented. Note,
>   that output scale and transform are not controlled by the shell
>   (at least yet).
> 
> Other than that, all the patches look good to me. I'll just wait for
> someone else to Ack this plan before trying to land this series.

I will ask Natsume-san today for Ack.
Thank you very much.
> 
> 
> Thanks,
> pq

Best regards

Emre Ucan
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6937