Adding support for external Weston back-ends

[Pekka Paalanen]

On Thu, 8 Sep 2016 16:45:12 +0200
Krzysztof Konopko <kris at youview.com> wrote:

> Hi,
> 
> I'm aware that loading external back-ends was removed from Weston some time this
> year (in June) but I'd like to ask for reconsidering this decision.  I guess
> this was driven by the intent to support only back-ends hosted within Weston
> tree (easier to maintain) and to encourage openness.

Hi,

it was done for a very good reason indeed, and nothing has changed. My
arguments are below. For TL;DR, there is a summary at the end.

> On the other hand, this might discourage the adoption of Wayland in
> general as Weston, being the reference compositor, is the first go-to
> component to evaluate new platforms.

I don't think it discourages. Why would it?

One cannot see some of the benefits of Wayland at all without a driver
stack that properly implements the standard interfaces (DRM/KMS,
EGL/Wayland, GBM, and particularly *not* fbdev).

The main encouragement for Weston in particular is that it is
MIT-licensed, so anyone can do practically whatever they want with it.

>  And unlikely adopters choose to write the whole compositor
> themselves in the first place.

If one cannot work with upstream, they can always fork (lib)weston and
keep the fork private. The license allows this just fine, they can even
ship it in a product. As a bonus, they get to decide when to update
their fork from upstream.

Obviously everyone else will frown upon forking, but it's fine for
evaluating things. If they actually end up shipping the fork, they may
or may not end up doing a disservice for themselves, and the very least
it is unthankful towards the community. The ultimate goal, if the
evaluation proves positive, should always be aiming for upstream
support by publishing drivers that implement the standard interfaces,
so that one does not need a vendor-specific backend for Weston.

Going upstream is what pays off best in the long run. But that is not
what you are trying to do here, you are trying to do the opposite: have
upstream support your secret private code no-one else will ever have.

>  In some cases this will be closed/proprietary
> platforms (eg. set-top-boxes) where big companies cannot be simply
> asked to open their graphics acceleration drivers (even if they want
> to, it might not be that

Nothing in Weston makes it incompatible with closed/proprietary drivers
as long as they implement the expected interfaces (which all have open
source implementations available for reference). But since you imply
one needs a special backend, they do not have the interfaces
implemented, either yet or never intend to. It is the "never intend to"
that we fight back. Making the implementations open source is a
secondary fight - another matter.

> simple) but it also might be the case for (almost) open platforms
> where during evaluation and prototyping existing solutions (eg. Mesa)
> are not at option.  An example of this might be (aptly) discontinued
> support for rpi-backend within Weston, while V3D driver in Mesa is
> not mature enough and its performance is likely inferior to the
> proprietary one.

Rpi is a poor example for this cause. It is the proprietary
firmware/drivers that broke Weston's rpi-backend. The backend had been
already useless for a long time when it was removed. Something changed
in the proprietary software and Weston did not work anymore. The vendor
did not care, and no-one else could help. It is actually an example
against this cause: it was a waste to invest in a backend that relies
on a proprietary API.

It might have been a different situation if someone else implemented
the same API too.

> Anyway, I think that supporting external back-ends would make no harm in Weston
> project and can only do it good (encourage adoption).

No, I completely totally disagree 100%. First some practical reasons:

Trying to pretend we support external backends will cause serious harm
to upstream development by hindering changes. OTOH, as long as we break
the ABI at will and bump the major version of libweston, external
backends would be playing catch-up anyway.

IOW, whether we added an alternative backend loading API or not, one
will always have to play catch-up with upstream changes. The only
difference is whether you maintain a fork of Weston, or maintain which
commit sha1 your backend will work against and require your users to
install exactly that. Essentially there is no difference for you the
developer, there is more hassle for the users, and there is just harm
for upstream.

One might just as well maintain a private fork of Weston, keeping it
in known state, and merging in upstream development only when one thinks
it is a good time, and then knowing exactly when one has to fix up
the backend. If doing this, one might even be able to contribute back
to upstream by maintaining a stable Weston branch, backporting fixes
from Weston upstream master branch to an upstream stable branch.

Then on to some more philosophical reasons:

The proposition to support external backends is attempting to trade
well-defined, standardized and stable interfaces (DRM, EGL, GBM) for an
unstable, one-project-only, poorly defined API (the Weston backend
interface). It does not make sense in the long run.

Supporting external backends is, particularly what you are proposing it
for, a statement that we accept and support proprietary closed driver
stacks with random proprietary interfaces. We definitely do not want to
make that statement as it will hurt everyone in the long run. The
reasons are the same as why vendors should really work on getting their
kernel drivers merged in the upstream Linux kernel.

> Attached is a proposed patch that adds an _alternative_ API to load back-ends
> externally.

You add yet another API, which is never used upstream, therefore is
never tested, which means it will be always broken. Not a good idea.

Not to mention it will be yet another thing for upstream to maintain,
while upstream gains nothing from supporting it. Without anything
upstream using it, it cannot even be maintained.

The backend API is much much more than just the loader interface.
Currently it is essentially everything in libweston/compositor.h as we
haven't even tried to separate the APIs towards different components.
Your patch is even making it bigger by exporting more functions.

> Equally all existing back-ends could use the same `backend_init()` API as the
> external ones, like it was before, something like:
> 
>     WL_EXPORT int
>     backend_init(struct weston_compositor *compositor,
>                  char *name, int *argc, char **argv,
>                  struct weston_config *wc);
> 
> All configuration parsing would be moved into each back-end library and decouple
> all back-ends nicely from generic libweston code.

We have just gone through a huge struggle to get all config parsing out
of the backends. Putting it back will not be accepted in the
foreseeable future, not even as an option, as it goes against the
design principles of libweston.


	Summary

If one needs a proprietary backend for Weston, Weston has to be forked.
On the premise that one really needs a proprietary backend, this is the
best solution for both the vendor and upstream. However, the vendor
should work hard to make that premise false, and then everyone will win.


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/20160909/b1c226f3/attachment-0001.sig>