<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-06-24 2:49 GMT+09:00 Giulio Camuffo <span dir="ltr"><<a href="mailto:giuliocamuffo@gmail.com" target="_blank">giuliocamuffo@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"><span class="">2015-06-23 20:40 GMT+03:00 JoonCheol Park <<a href="mailto:jooncheol@gmail.com">jooncheol@gmail.com</a>>:<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>
> 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 in<br>
> the scope of libweston, I believe my proposal is not the opposite idea to<br>
> 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></blockquote><div><br></div><div><br></div><div><div style="font-size:14px">Which branch should I see on your repository? libweston ? libweston-v2 ?</div><div style="font-size:14px">I found that you mentioned structure in branch "libweston-v2". (right ?)</div></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"><span class="">
</span>Well, but you are adding weston specific stuff into the backends code,<br>
that is the options handling. </blockquote><div><br></div><div><div style="font-size:14px">backend plugin (and option handling) is the *weston* compositor specific.  so this is not the problem I think. </div><div><br></div><span class="im" style="font-size:14px"></span></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">In libweston the backends do not parse<br>
the command line or the config file, so all the backend options are<br>
weston specific.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><div style="font-size:14px">In your code (src/weston.c, branch libweston-v2), as you explained, the weston (compositor main) have the code for parse options for all known backend plugin before init it. But, there are many hard code option outputs for only known backend plugins. In this case, we don't have to load plugin file dynamically. </div><div style="font-size:14px"><br></div><div style="font-size:14px">And it use the "weston_compositor_init_backend" of the libweston.so which has hard coded backend list.  </div><div style="font-size:14px">I think this function should not be included in the libweston.so if its goal is to be reused for other compositor. Since the "weston_compositor_init_backend" is for weston specific backend plugin initialization, it is not necessary function for others.</div></div><div><br></div><div><br></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"><div class=""><div class="h5">
><br>
><br>
>><br>
>> > 2015-06-23 13:29 GMT+03:00 JoonCheol Park <<a href="mailto:jooncheol@gmail.com">jooncheol@gmail.com</a>>:<br>
>> > > Instead of adding available backends and usage outputs at build time,<br>
>> > > this patch finds all available backend plugins in MODULEDIR and prints<br>
>> > > them. It also prints usage output for selected backend by calling<br>
>> > > "backend_usage()" in the plugin.<br>
>> > ><br>
>> > > By this patch, we can remove all hardcode for backends from<br>
>> > > compositor.<br>
>> > > 3rd party backend plugin can be listed in help output. Backend<br>
>> > > developer<br>
>> > > can freely add additional description for backend.<br>
>> > ><br>
>> > > Signed-off-by: JoonCheol Park <<a href="mailto:jooncheol@gmail.com">jooncheol@gmail.com</a>><br>
>> > > ---<br>
>> > >  src/compositor-drm.c      |  11 ++++<br>
>> > >  src/compositor-fbdev.c    |   9 +++<br>
>> > >  src/compositor-headless.c |  11 ++++<br>
>> > >  src/compositor-rdp.c      |  15 +++++<br>
>> > >  src/compositor-rpi.c      |  12 ++++<br>
>> > >  src/compositor-wayland.c  |  14 +++++<br>
>> > >  src/compositor-x11.c      |  13 +++++<br>
>> > >  src/compositor.c          | 141<br>
>> > > ++++++++++++----------------------------------<br>
>> > >  src/compositor.h          |   3 +<br>
>> > >  9 files changed, 125 insertions(+), 104 deletions(-)<br>
>><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>
> When I tried to add new options for backend plugin, I had to add option<br>
> outputs for my backend into main compositor code. not in the plugin itself.<br>
> Since it is kind of hardcode, I thought it doesn't look good. I think that<br>
> plugin should have such information of itself and compositor should load<br>
> such information from plugin file.<br>
><br>
> (similar case: In case of NPAPI, Web browser can show plugin's information<br>
> by getting/calling "NP_GetMIMEDescription()" from each plugin .so file. e.g<br>
> - about:config in Mozilla)<br>
><br>
> So, I created this patch for better (weston specific) backend plugin<br>
> management structure.<br>
><br>
>><br>
>> 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>
> 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>
><br>
>> We are going in the direction of backends becoming libweston internal<br>
>> details, not something you can plug and switch arbitrarily, at least<br>
>> for the middle-term.<br>
>><br>
>><br>
>><br>
>><br>
>> Thanks,<br>
>> pq<br>
><br>
><br>
</div></div></blockquote></div><br></div></div>