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

[Pekka Paalanen]

Hi all

TL;DR:

Everything is open, let's make small steps only, in priority order
determined by the intended audience. We have as many release cycles of
time to use for improving the code and interfaces as we want.


On Wed, 24 Jun 2015 02:40:08 +0900
JoonCheol Park <jooncheol at gmail.com> wrote:

> Hi Giulio, pq!
> 
> 
> 2015-06-23 20:57 GMT+09:00 Pekka Paalanen <ppaalanen at gmail.com>:
> 
> > On Tue, 23 Jun 2015 14:14:53 +0300
> > Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > This kinda goes in the opposite direction to my libweston patches. In
> > > that series i move the command line handling away from the backends
> > > code to make them work in multiple compositors. This moves even more
> > > compositor-specific stuff in the backends so we need to decide if we
> > > want this or libweston.
> >
> > We want libweston.
> >
> 
> I just quick review the libweston on the github (
> https://github.com/giucam/weston/). When it will be applied to mainstream ?

We're aiming for the 1.9 release, but as I want to repeat, this
work will not be complete for a long long time. See below.

> My understanding about libweston is for reuse the x11/drm related code for
> other compositor project (like libinput). Yes, It is everyone want :-)
> But, since the backend structure which manages multiple plugins and load
> symbol 'backend_xxx()'  is weston compositor specific stuff and it is not
> in the scope of libweston, I believe my proposal is not the opposite idea
> to the libweston what you are preparing.
> (In your repository, my proposal may change the src/weston.c to remove
> hardcoded backend option outputs. It is not part of libweston library. )

The scope of libweston is very unclear at the moment, anyway. We
are taking small steps to making it usable by others, which will take
many release cycles. There is time to fix the details.

Your work is much in the right direction. Until now, we have not really
cared about the details of config handling etc. so yes, it's a mess at
the moment, to be cleaned up. I'd like to see cooperation with the
libweston effort.

One idea we would like to see is that configuration is passed into
libweston in some "generic" form, so that a main program can use
whatever to load it (ini, xml, gnome-settings, registry, LDAP, generate
it on the fly, ...). So far, different backends use different sets of
options, so we have to have that somehow. How exactly is not important
right now.

> > JoonCheol, any particular reason you are proposing this?
> > Are you building external backends?
> >
> 
> Yeap, I'm trying to make some fun experiments based on headless backend
> code.

It is an open question whether external backends should be supported by
libweston at all. Weston today does not support them, and that's what
we start with. Future may hold different.

It is also an open question of how much the user of libweston should
care about the particular backends. One major difference between the
various backends is that some run on "bare" hardware (drm, fbdev, rpi)
and some are running under another display system (x11, wayland, rdp?).
I suspect the user of libweston has to care about at least that much.

> > AFAIK the Weston SDK (the installed headers) for external plugins never
> > supported external backends, so I'm curious.
> >
> >
> Since this kind of plugin just need header files for building and weston.pc
> is also already supported, I thought that building external backend plugin
> is supported (and ideally possible in current version of weston)... but
> wasn't it??

For instance, gl-renderer.h was never exported (installed with Weston),
neither any of the input or launching support headers. I'm a little bit
surprised you got away with it, it certainly was not meant to work.

Perhaps the headless backend is too simple to show those deficiencies.

Also, Weston currently has no notion between what is API meant for
backends and what is API meant for shells, or for arbitrary plugins. Or
renderers, for that matter. It's all just a huge free-for-all mess
right now. You can't even be sure what is API at all.

> If it can be supported, it would be good for like my case. Developer can
> create the backend plugin without build all weston source.. (like other
> '-dev' pkg supported program)

The API surface between Weston core and the backends is huge. The API
surface between the shell implementation and plugins vs. Weston core is
huge too. My plan was for us to tackle these one by one, over many
release cycles. Also because this will be mostly volunteer work, we
have to allow lots and lots of time for things to develop.

We start with the API surface used by the shell implementations,
because shells are the things the expected users of libweston will be
replacing. Libweston's intended audience does not include backend
developers at first.

This is a deliberate policy decision or at least a proposal in an
attempt to keep things manageable.

I also repeat what I wrote in another reply in this thread:

	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 enough.

If supporting external backends seems doable, we can perfectly well do
it later. The primary focus of the current libweston work is to support
the "my own window manager" developers, not people who enable new
hardware platforms.

Why not people who enable new hardware platforms? Because libweston is
not the only driver-facing implementation out there, and it was never
meant to be the only one. If you add platform-specific enablement to
(lib)weston, it does not help Gnome or E, and likely not KDE either.
So you'd be missing most of the desktop users.

Proper new hardware platform enablement belongs in the kernel drivers
and EGL and GL implementations. (I'm looking forward to the day when
the drm-backend with gl-renderer just works on Raspberry Pi, so we can
nuke the rpi backend and renderer from Weston.)


If you can propose a better interface for things you don't like in
Giulio's libweston patch series, please do! But I don't think "this is
not perfect" or even "this is not very good" are enough reason to block
that series, because we can work things out over time. It is quite
different from, say, protocol design.


Thanks,
pq