<div dir="ltr">Hi <span style="font-size:14px">Giulio, pq!</span><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-23 20:57 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"><span class="">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>
</span>We want libweston.<br></blockquote><div><br></div><div><div><span style="font-size:14px">I just quick review the libweston on the github (</span><a href="https://github.com/giucam/weston/">https://github.com/giucam/weston/</a>). When it will be applied to mainstream ?<br></div><div><br></div><div>My understanding about libweston is for reuse the x11/drm related code for other compositor project (like libinput). Yes, It is everyone want :-)</div><div>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. </div></div><div>(In your repository, my proposal may change the src/weston.c to remove hardcoded backend option outputs. It is not part of libweston library. )</div><div><br></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">
<span class=""><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 compositor.<br>
> > 3rd party backend plugin can be listed in help output. Backend 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>
> >  src/compositor.h          |   3 +<br>
> >  9 files changed, 125 insertions(+), 104 deletions(-)<br>
<br>
</span>JoonCheol, any particular reason you are proposing this?<br>
Are you building external backends?<br></blockquote><div><div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">Yeap, I'm trying to make some fun experiments based on headless backend code.</span></div><div><span style="font-size:14px">When I tried to add new options for backend plugin, I had to add option outputs for my backend into main compositor code. not in the plugin itself. Since it is kind of hardcode, I thought it doesn't look good. I think that plugin should have such information of itself and compositor should load such information from plugin file.</span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">(similar case: In case of NPAPI, Web browser can show plugin's information by getting/calling "</span>NP_GetMIMEDescription()" from each plugin .so file. e.g - about:config in Mozilla)</div></div></div><div><br></div><div>So, I created this patch for better (weston specific) backend plugin management structure. </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>
AFAIK the Weston SDK (the installed headers) for external plugins never<br>
supported external backends, so I'm curious.<br>
<br></blockquote><div><br></div><div>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?? </div><div>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)</div><div><br></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">
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.</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"> <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">
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div></div>