Hi,
On 14/03/19 14:20, Jean-Francois Dagenais wrote:
> Hi guys,
>
> Thanks for your work on this...
>
>> On Mar 13, 2019, at 14:26, Manjukumar Matha
>> <manjukumar.harthikote-ma...@xilinx.com> wrote:
>>
>> From: Alejandro Enedino Hernandez Samaniego <aleja...@xilinx.com>
>>
>> libmali provides GL backends based on x11, fbdev and wayland,
>> we should be able to switch between them at runtime since it is
>> the same ABI, it should only be a matter of loading the correct
>> shared library by the interpreter (dynamic linker).
>>
>> Use the update-alternatives class, to provide a way for the user
>> to choose the desired backend at runtime, do this by setting
>> priorities, the package with the highest priority will be chosen
>> as default at build time, but it can easily be changed at runtime
>> afterwards.
>> This change implies that the libmali package will install all
>
> Nitpicking: missing line between above paragraph separation.
>
>> backends regardless of which one was chosen, but it will only use
>> one as default.
>>
>> Use the x11 backend by default at build time; given that it is
>> the same ABI, applications which depend on libmali, can build
>> regardless of the chosen backend at build time.
>
> Mh. Since it doesn't make a difference at build time, perhaps using the
> "headless" backend would be the better, lowest dependency, choice.
>
>>
>> Update-alternatives uses a set of commands on the postinst
>> scripts when creating the root filesystem, which basically create
>> the soft link between the chosen alternative and the binary/library.
>> This usually works seamlessly (for binaries), but it does not in the
>> case of libraries, because ldconfig is run at the end of the
>> do_rootfs task, and it removes the link that was just created,
>> it is important to note that this is simply normal ldconfig behavior
>> and its not something we can fix, so we defer execution of
>> update-alternatives until the first boot, hence avoiding the link
>> removal by ldconfig.
>>
>> Switching backends at build time will also help to avoid longer
>> build times, since it will only invalidate the do_package task,
>> rebuilding an image after switching a backend (at build time)
>> should only execute the do_package task along with the do_rootfs
>> task.
>
> Hooray!
>
>>
>> Signed-off-by: Alejandro Enedino Hernandez Samaniego <aleja...@xilinx.com>
>> Signed-off-by: Manjukumar Matha <manjukumar.harthikote-ma...@xilinx.com>
>> ---
>> .../recipes-graphics/libgles/libmali-xlnx.bb | 101
>> ++++++++++++++-------
>> 1 file changed, 67 insertions(+), 34 deletions(-)
>>
>> diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
>> b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
>> index 504ea6d..7191c25 100644
>> --- a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
>> +++ b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
>> @@ -4,9 +4,9 @@ LICENSE = "Proprietary"
>> LICENSE_FLAGS = "xilinx"
>> LIC_FILES_CHKSUM = "file://README.md;md5=d5750ae6496dd931669b454b5aaae2cd"
>>
>> -inherit distro_features_check
>> +inherit distro_features_check update-alternatives
>>
>> -ANY_OF_DISTRO_FEATURES = "fbdev x11"
>> +REQUIRED_DISTRO_FEATURES = "x11 fbdev wayland"
>>
>> PROVIDES += "virtual/libgles1 virtual/libgles2 virtual/egl virtual/libgbm"
>>
>> @@ -40,22 +40,14 @@ PACKAGE_ARCH = "${SOC_FAMILY}"
>>
>> S = "${WORKDIR}/git"
>>
>> -X11RDEPENDS = "libxdamage libxext libx11 libdrm libxfixes"
>> -X11DEPENDS = "libxdamage libxext virtual/libx11 libdrm libxfixes"
>> +# If were switching at runtime, we need all RDEPENDS needed for all
>> backends available
>> +RDEPENDS_${PN} = " kernel-module-mali libxdamage libxext libx11 libdrm
>> libxfixes"
>
> I believe this will install x11 libs in images even if one doesn't have "x11"
> in
> DISTRO_FEATURES. This is my case and I would not use the recipe like this.
I completely agree with Jean-Francois. I need only one backend in my
embedded system, I don't want to build lots of unneeded packages. Having
them on the target is not even considered.
--
Luca
--
_______________________________________________
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
