[PATCH weston] compositor: Separate hardcoded backend related code from compositor

Pekka Paalanen ppaalanen at gmail.com
Tue Jun 23 23:41:20 PDT 2015

On Tue, 23 Jun 2015 11:22:18 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> On Tue, Jun 23, 2015 at 10:49 AM, Giulio Camuffo <giuliocamuffo at gmail.com>
> wrote:
> > Well, but you are adding weston specific stuff into the backends code,
> > that is the options handling. In libweston the backends do not parse
> > the command line or the config file, so all the backend options are
> > weston specific.
> >
> This just seems wrong to me. Why are these backends .so files at all, then?

Because those backends pull in different libraries, some of which you
definitely do not want to be pulling in all the time, unless you use a
backend that specifically requires them. The X11 libs are a good
example, and EGL and GL libs too.

Also, packagers could split (lib)Weston into core and backend-specific
packages, each of which having their own dependencies. I don't know if
anyone does this or if it actually works, but I believe it is useful.
No need to install all X11 libs if you don't want the x11-backend nor
Xwayland. The same for GL.

Sure we could build a compositor executable once for each backend, but
that tends to lead to a combinatorial explosion of backends x shells (x

The aim is to make the shell implementation the "main program
executable", which means you start a DE by running that DE-specific
program, which links to libweston to provide compositor features. Yes,
in the future it means you'd be running 'weston-desktop' or
'weston-ivi' or 'orbital' or 'whatever', not just 'weston'.

Also please note, that this is not the final nor stable libweston API
design. Things *will* change in the future. Right now we just want
small steps toward something that resembles a usable libweston. It is
NOT something that will happen over one release cycle. I expect it will
take about a dozen cycles to finalize. Yes, we *will* break the
libweston API often, and we have prepared for that, hopefully well


More information about the wayland-devel mailing list