[PATCH weston v3] drm: port the drm backend to the new init api

[Benoit Gschwind]

Le 09/02/2016 11:38, Pekka Paalanen a écrit :
> On Tue, 9 Feb 2016 01:11:48 +0100
> Benoit Gschwind <gschwind at gnu-log.net> wrote:
>
>> Hello,
>>
>> while I developing the option 2. I raise few questions because this
>> option explicit the fact that back-ends does not share the same API (at
>> less for the configuration). To resolve the issue I found the following
>> options:
>>
>>    1. find a common configuration API (use key/value)
>>
>>    2. have the following split:
>>      - libweston: every thing that is not in back-ends.
>>      - libbackendx, libbackendy, ... : back end implementation of
>> configuration stuff, that you must link with libweston (this is the
>> uncommon API parts of back-ends
>>      - backendx.so, backendy.so, ... : the loadable (common API) part of
>> backends.
>>
>>    3. have the following split:
>>     - libweston: every thing that is not in backends.
>>     - libbackendx, libbackendy, ... : back end are not more loadable, and
>> are linked at build, developer can drop useless back-ends.
>
> Hi,
>
> I understand option 2, but I do not understand how option 3 could work.
>
> I suppose option 3 means that a compositor would be built to run just a
> single backend, and you cannot choose it at runtime? We certainly do
> not want to pose that kind of a limitation.

no, I didn't thinked that design, you can have several backend in the 
option3 with :
  - banckend_handler * load_aaa_bakcend (provided by libbackendaaa)
  - banckend_handler * load_bbb_bakcend (provided by libbackendbbb)

you can link both and select the desired backend, I did this kind of 
thing in my proposed patch.

>
> We also do not want to load more than one backend at a time to the
> compositor process, because different backends pull in different
> libraries and sometimes those are a significant burden. It would be sad
> if a compositor that supported both DRM and X11 backends would *always*
> load libX11 regardless of which it is using. It would be useless work
> at start-up, and also make the dependencies of the compositor too much:
> you cannot choose to install it with libs for DRM only. That would be
> awkward for distributions.
>
> About distributions, you can see the explanation on how Weston project
> will be intended to be split into binary packages in a distribution in
> Weston's readme.

Ok, I was not aware of this direction, now it's clear and I agree, I 
found a compromise between option 2 and 3, I leave you to check my 
submitted patch.

>
>> Maybe you have better idea, from my point of view I will prefer the
>> third one. it's not optimal in term of loading and memory because we
>> need to load all available back-ends but it's cleaner.
>
> For the above reasons, I believe option 3 is not acceptable.
>
>> Maybe in the option 3 we can hide the option 2 inside, that load a
>> backend.so only once it's used to save memory and loading time.
>>
>> This is something I didn't foresee in my previous e-mail.
>
> Right, so you propose we add yet another bunch of libraries, one per
> backend, to be linked to by the compositor program at build time. The
> benefit is that libweston.so would not export any backend-specific
> symbols.
>
> I think that is the only benefit, and the amount of code inside these
> libraries would be quite small. Therefore to me the trade-off compared
> to libweston.so just exporting those symbols itself is not worth it.
>
> The summary in your previous email on the possible design choises is
> still accurate in my opinion, this new idea here is just bringing more
> complexity that it is worth.
>
>
> Thanks,
> pq
>