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

JoonCheol Park jooncheol at gmail.com
Wed Jun 24 08:31:56 PDT 2015

Thanks pq and all,

I didn't think this would be hot topic :-) All reply from all in this
thread was very very helpful to understand current weston project for me.

2015-06-24 16:52 GMT+09:00 Pekka Paalanen <ppaalanen at gmail.com>:

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

It seems so. Anyway, The headless backend was good enough to start do
something as skeleton, And it was quite nice to understand the backend
plugin :-)

> 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.
If you and Giulio felt like that, that is my fault.
Actually, I didn't know about libweston and plan regarding it when I create
this patch. I'm true newbie :-)
I just hope that my patch work could little help for this good project.

Thanks again for kind explanation.

> Thanks,
> pq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150625/a752e668/attachment-0001.html>

More information about the wayland-devel mailing list