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 <ppaala...@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 <joonch...@gmail.com> wrote: > > > Hi Giulio, pq! > > > > > > 2015-06-23 20:57 GMT+09:00 Pekka Paalanen <ppaala...@gmail.com>: > > > > > On Tue, 23 Jun 2015 14:14:53 +0300 > > > Giulio Camuffo <giuliocamu...@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 >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel