<div dir="ltr">Thanks pq and all,<div><br></div><div>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. </div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-24 16:52 GMT+09:00 Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all<br>
<br>
TL;DR:<br>
<br>
Everything is open, let's make small steps only, in priority order<br>
determined by the intended audience. We have as many release cycles of<br>
time to use for improving the code and interfaces as we want.<br>
<span class=""><br>
<br>
On Wed, 24 Jun 2015 02:40:08 +0900<br>
JoonCheol Park <<a href="mailto:jooncheol@gmail.com">jooncheol@gmail.com</a>> wrote:<br>
<br>
> Hi Giulio, pq!<br>
><br>
><br>
> 2015-06-23 20:57 GMT+09:00 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>>:<br>
><br>
> > On Tue, 23 Jun 2015 14:14:53 +0300<br>
> > Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a>> wrote:<br>
> ><br>
> > > Hi,<br>
> > ><br>
> > > This kinda goes in the opposite direction to my libweston patches. In<br>
> > > that series i move the command line handling away from the backends<br>
> > > code to make them work in multiple compositors. This moves even more<br>
> > > compositor-specific stuff in the backends so we need to decide if we<br>
> > > want this or libweston.<br>
> ><br>
> > We want libweston.<br>
> ><br>
><br>
> I just quick review the libweston on the github (<br>
> <a href="https://github.com/giucam/weston/" rel="noreferrer" target="_blank">https://github.com/giucam/weston/</a>). When it will be applied to mainstream ?<br>
<br>
</span>We're aiming for the 1.9 release, but as I want to repeat, this<br>
work will not be complete for a long long time. See below.<br>
<span class=""><br>
> My understanding about libweston is for reuse the x11/drm related code for<br>
> other compositor project (like libinput). Yes, It is everyone want :-)<br>
> But, since the backend structure which manages multiple plugins and load<br>
> symbol 'backend_xxx()'  is weston compositor specific stuff and it is not<br>
> in the scope of libweston, I believe my proposal is not the opposite idea<br>
> to the libweston what you are preparing.<br>
> (In your repository, my proposal may change the src/weston.c to remove<br>
> hardcoded backend option outputs. It is not part of libweston library. )<br>
<br>
</span>The scope of libweston is very unclear at the moment, anyway. We<br>
are taking small steps to making it usable by others, which will take<br>
many release cycles. There is time to fix the details.<br>
<br>
Your work is much in the right direction. Until now, we have not really<br>
cared about the details of config handling etc. so yes, it's a mess at<br>
the moment, to be cleaned up. I'd like to see cooperation with the<br>
libweston effort. <br></blockquote><div><br></div><div>Thanks</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
One idea we would like to see is that configuration is passed into<br>
libweston in some "generic" form, so that a main program can use<br>
whatever to load it (ini, xml, gnome-settings, registry, LDAP, generate<br>
it on the fly, ...). So far, different backends use different sets of<br>
options, so we have to have that somehow. How exactly is not important<br>
right now.<br>
<span class=""><br>
> > JoonCheol, any particular reason you are proposing this?<br>
> > Are you building external backends?<br>
> ><br>
><br>
> Yeap, I'm trying to make some fun experiments based on headless backend<br>
> code.<br>
<br>
</span>It is an open question whether external backends should be supported by<br>
libweston at all. Weston today does not support them, and that's what<br>
we start with. Future may hold different.<br>
<br>
It is also an open question of how much the user of libweston should<br>
care about the particular backends. One major difference between the<br>
various backends is that some run on "bare" hardware (drm, fbdev, rpi)<br>
and some are running under another display system (x11, wayland, rdp?).<br>
I suspect the user of libweston has to care about at least that much. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> > AFAIK the Weston SDK (the installed headers) for external plugins never<br>
> > supported external backends, so I'm curious.<br>
> ><br>
> ><br>
> Since this kind of plugin just need header files for building and weston.pc<br>
> is also already supported, I thought that building external backend plugin<br>
> is supported (and ideally possible in current version of weston)... but<br>
> wasn't it??<br>
<br>
</span>For instance, gl-renderer.h was never exported (installed with Weston),<br>
neither any of the input or launching support headers. I'm a little bit<br>
surprised you got away with it, it certainly was not meant to work.<br>
<br>
Perhaps the headless backend is too simple to show those deficiencies.<br></blockquote><div><br></div><div>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 :-) </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Also, Weston currently has no notion between what is API meant for<br>
backends and what is API meant for shells, or for arbitrary plugins. Or<br>
renderers, for that matter. It's all just a huge free-for-all mess<br>
right now. You can't even be sure what is API at all.<br>
<span class=""><br>
> If it can be supported, it would be good for like my case. Developer can<br>
> create the backend plugin without build all weston source.. (like other<br>
> '-dev' pkg supported program)<br>
<br>
</span>The API surface between Weston core and the backends is huge. The API<br>
surface between the shell implementation and plugins vs. Weston core is<br>
huge too. My plan was for us to tackle these one by one, over many<br>
release cycles. Also because this will be mostly volunteer work, we<br>
have to allow lots and lots of time for things to develop.<br>
<br>
We start with the API surface used by the shell implementations,<br>
because shells are the things the expected users of libweston will be<br>
replacing. Libweston's intended audience does not include backend<br>
developers at first.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
This is a deliberate policy decision or at least a proposal in an<br>
attempt to keep things manageable.<br>
<br>
I also repeat what I wrote in another reply in this thread:<br>
<span class=""><br>
        Please note, that this is not the final nor stable libweston<br>
        API design. Things *will* change in the future. Right now we<br>
        just want small steps toward something that resembles a usable<br>
        libweston. It is NOT something that will happen over one<br>
        release cycle. I expect it will take about a dozen cycles to<br>
        finalize. Yes, we *will* break the libweston API often, and we<br>
        have prepared for that, hopefully well enough.<br>
<br>
</span>If supporting external backends seems doable, we can perfectly well do<br>
it later. The primary focus of the current libweston work is to support<br>
the "my own window manager" developers, not people who enable new<br>
hardware platforms.<br>
<br>
Why not people who enable new hardware platforms? Because libweston is<br>
not the only driver-facing implementation out there, and it was never<br>
meant to be the only one. If you add platform-specific enablement to<br>
(lib)weston, it does not help Gnome or E, and likely not KDE either.<br>
So you'd be missing most of the desktop users.<br>
<br>
Proper new hardware platform enablement belongs in the kernel drivers<br>
and EGL and GL implementations. (I'm looking forward to the day when<br>
the drm-backend with gl-renderer just works on Raspberry Pi, so we can<br>
nuke the rpi backend and renderer from Weston.)<br>
<br>
<br>
If you can propose a better interface for things you don't like in<br>
Giulio's libweston patch series, please do! But I don't think "this is<br>
not perfect" or even "this is not very good" are enough reason to block<br>
that series, because we can work things out over time. It is quite<br>
different from, say, protocol design.<br>
<br></blockquote><div><br></div><div>If you and Giulio felt like that, that is my fault. </div><div>Actually, I didn't know about libweston and plan regarding it when I create this patch. I'm true newbie :-)</div><div>I just hope that my patch work could little help for this good project.</div><div><br></div><div>Thanks again for kind explanation.</div><div>JC</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div></div>