[PATCH weston 04/11] make the backends compositor-neutral

[Pekka Paalanen]

On Mon, 13 Jul 2015 14:19:17 -0700
"Jon A. Cruz" <jonc at osg.samsung.com> wrote:

> On 07/10/2015 04:32 AM, Pekka Paalanen wrote:
> > 
> > As I see it, the main reason the backends are .so files instead of
> > built into libweston or the main executable is that we can restrict the
> > dependencies.
> > 
> > I can well imagine a packager splitting Weston into several packages,
> > for example: core, gl-renderer, x11-backend, drm-backend, xwayland
> > 
> > - gl-renderer pulls in dependency to libEGL and GLESv2
> > - x11-backend and xwayland pull in X11 libs
> > - drm-backend pulls in libdrm and libgbm (which probably pulls in Mesa
> >   or something)
> > 
> > In all other aspects, I consider backends an integral part of
> > libweston, and could just be built in to libweston instead of
> > separate .so files.

...

> > I agree with Giulio here. We cannot avoid the "main.c" knowing about
> > all possible parameters a backend might take. Main needs to know about
> > them, and main chooses which parameters it exposes to the user via
> > command line and/or config file options.

...

> > These are only suggestions, but I believe the right approach is to have
> > the main in charge of all options exposed to the user. I do not think
> > letting libweston and backends to define arbitrary new options without
> > the main ever knowing about them is a good idea. If you accept this,
> > then the remaining question is what should the option-setting API of
> > libweston look like. We can very well leave that question open for now,
> > and just use whatever works at the moment.

...

> > There is also the question of runtime-appearing objects that need
> > configuration. Outputs are a perfect example: a hotplug may create a
> > new output, and then you may want to have a special configuration for
> > it. Can a main predict everything and encode all configurations a
> > priori during the compositor init, or we allow the main to make up a
> > configuraton when something new appears?
> > 
> > The latter cannot really be implemented without some kind of callbacks.
> > The benefit is that a main can e.g. detect a class of outputs and apply
> > particular configuration on them, without the need to list every
> > possible output name in advance to achieve the same (if that is even
> > possible).
> > 
> > One more question are parameters that a main might want to change after
> > initialization. I think those are out of scope for this discussion, as
> > we are replacing config file and command line options which were only
> > ever set at startup. If an option becomes more dynamic than that, we
> > need new API for it, maybe a la libinput.
> 
> This sounds like very solid analysis of the factors, and addresses most
> of my concerns. I also discussed things a bit with Giulio on IRC to get
> some more clarification on intent. (To call this out up front, once he
> clarified some of his intent that removed any of my blocking concerns on
> this patchset).

Hi Jon,

cool, nice to hear.

> Point 1:
> 
> It could be inferred from some of the implementation details that the
> different backends were being encapsulated away from libweston and the
> main executable to allow for arbitrary ones to be added in the future.
> However, that appears to be counter to the current design intent. The
> follow up discussions have indicated that the focus is just more on
> modularity and ease of loading rather than future-proof support for
> arbitrary back-ends.
> 
> Passing the back-end specific config struct thus seems like a solid
> implementation for now. However the one aspect of passing it as a void*
> parameter to a common overloaded function stood out as a red flag. If
> instead each back-end had a back-end specific init function that takes
> the corresponding struct directly (without wrapping it in a void *) then
> compile-time safety would be regained. However that in turn does
> complicate the loading API a bit.
> 
> The addition of the backend_type and magic members on the init struct
> would go to mitigate most of the risk from using void*, so that winds up
> things nicely for the immediate timeframe.

Yup. I even thought that the "enum backend_type" in struct
weston_backend_config might replace the parameter for choosing the
backend completely. That is, libweston does not need to verify that a
config matches the chosen backend - the config actually chooses the
backend.

But before we can use an "enum backend_type", libweston needs to know
the path from where to load its internal .so files, so we will have
some intermediate API for a while until that is solved.

> Point 2:
> 
> Finally, there is a second design question that Giulio flagged for me:
> is libweston intended to be "a library any compositor can use to
> implement Wayland" or instead is it to be "a collection of related yet
> independent building blocks a program can use to build a Wayland
> compositor"?
> 
> This doesn't have to be set in stone immediately. However it does go to
> address the points where there is code not "in libweston" but "in
> main.c" that is doing work that some would consider the domain of
> libweston. Starting to settle out what functionality should remain in a
> main() function (command-line parameter parsing and config parsing
> definitely fall into this area) and what functionality should eventually
> migrate to live "inside libweston" can benefit from clarity on this
> design intent.

On many parts, this is an open question indeed. I touched it a bit in
http://lists.freedesktop.org/archives/wayland-devel/2015-July/023331.html
when trying to figure what to do with weston.pc and where would today's
weston plugins belong.

I think this is something for the libweston users to chime in on. After
all, whole point of libweston is to let people leverage what we wrote
for Weston, so it is mostly up to them on what pieces they actually
want.

There is only one libweston user that I know of atm. (Giulio's Orbital)
and I think we need more to find a good design.

However, I don't think we want libweston to become a "collection of any
random crap someone might use", but where to draw the line is a good
question.

In fact, all this is part of the long way towards stabilizing
libweston's API.

FWIW, as a future goal is(?) to turn also Weston's own shells into main
executables, we'll likely have a convenience library in weston for the
most stuff currently going into main.c.


Thanks,
pq