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

[JoonCheol Park]

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

Thanks

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


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