[PATCH weston] README: introduce libweston

[Pekka Paalanen]

On Wed, 15 Jul 2015 10:51:34 +0300
Giulio Camuffo <giuliocamuffo at gmail.com> wrote:

> Hi, one comment below but it looks ok to me, also with Bryce's comments.
> 
> 2015-07-14 13:07 GMT+03:00 Pekka Paalanen <ppaalanen at gmail.com>:
> > From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> >
> > What is libweston and where do we intend to go with it.
> >
> > Cc: Giulio Camuffo <giuliocamuffo at gmail.com>
> > Signed-off-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> > ---
> >  README | 139 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> >  1 file changed, 138 insertions(+), 1 deletion(-)
> >
> > diff --git a/README b/README

> > +Libweston design goals
> > +----------------------
> > +
> > +The high-level goal of libweston is that what used to be shell plugins
> > +will be main executables. Instead of launching 'weston' with various
> > +arguments to choose the shell, one would be launching
> > +'weston-desktop', 'weston-ivi', 'orbital', etc. The main executable
> 
> That's ok, though splitting weston in various executables is not my
> goal so i don't think i'm going to do it :P.

Sure, no problem. :-)

It's just a logical extension as I'm sure other projects will want to
have their own main(), and up to now we have assumed they are just
plugins.

I think converting Weston to do this will help in the libweston API
design. Our shell plugins want to launch several processes, so it will
be simpler if they just do it with our main.c provided code, rather
than plumb through libweston.

Do you have an opinion about other plugins?

I would suggest that libweston would not have "a plugin API" for
loading shared objects that are not libweston internal details. Any
plugin system would be specific to the hosting program. Of course,
those plugins could use the libweston API as they wish, if the host
program intends it.

This means that if we share the Xwayland XWM implementation through
libweston, xwayland.so will be a libweston internal detail. That's all
good so far, but then other projects likely want their own code for
drawing the X11 decorations so we're going to need some API for that.

I never looked into the color management plugins enough to make a guess
whether they should be completely or partly a (optional) libweston
feature. Maybe Weston could just offer (renderer-specific?) ways to set
the color correction parameters (LUT, matrix, whatever), and it would
be the host program's responsibility to get those parameters from
somewhere?

Are there other plugins I've forgot?

hmi-controller.so is plugin to the ivi-shell plugin, so it naturally
becomes a plugin for the weston-ivi host program.

Just so the following doesn't get lost, some time ago I gathered a
small TODO list for post-libweston:
- remove IN_WESTON
- weston-launch to launch all kinds of libweston apps; argv[0] based?
- turn desktop-shell from a plugin into an executable
- turn ivi-shell from a plugin into an executable
- remove -export-dynamic


Thanks,
pq