[PATCH weston 0/8] IVI Screen refactoring

Pekka Paalanen ppaalanen at gmail.com
Thu Mar 24 10:14:55 UTC 2016


On Thu, 24 Mar 2016 00:18:18 +0000
"Natsume, Wataru (ADITJ/SWG)" <wnatsume at jp.adit-jv.com> wrote:

> Hello Pekka-san, Emre-san,
> 
> It is fine with me as well. This refactoring removes duplicated logic
> in ivi-layout and results in lower maintenance effort.
> 
> Acked-by: Wataru Natsume <wnatsume at jp.adit-jv.com>

All pushed:
   90a6fc6..1c04d7b  master -> master


Thanks,
pq


> -----Original Message-----
> From: wayland-devel
> [mailto:wayland-devel-bounces at lists.freedesktop.org] On Behalf Of
> Pekka Paalanen Sent: Friday, March 18, 2016 8:25 PM To: Ucan, Emre
> (ADITG/SW1); wataru_natsume Cc: Friedrich, Eugen (ADITG/SW1);
> wayland-devel at lists.freedesktop.org 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?
> 
> 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?
> 
> - 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.
> 
> 
> Thanks,
> pq

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160324/4b20d28a/attachment-0001.sig>


More information about the wayland-devel mailing list