| Age | Commit message (Collapse) | Author |
|---|
|
distro_features_check is deprecated in dunfell, use features_check instead
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
|
|
Update the mali userspace receipe to fetch the updated binary from
rel-v2020.1 branch.
Signed-off-by: Madhurkiran Harikrishnan <madhurkiran.harikrishnan@xilinx.com>
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
|
|
This reverts commit 7b930600decc08da3c14ff428f9c4bf70342af5e.
This was the incorrect fix for the issues.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
The virtual provides should be handled via PREFERRED_PROVIDER setting in
the MACHINE and/or DISTRO configuration files. Setting them in the
recipe ends up making them unconditional in some cases leading to
incorrect dependencies for the users.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
Using the defaults will ensure that a machine or soc can override the
default version.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
This reverts commit 9c2708913ab24d2697124b05bcb9d541a4903547.
Mali EGL headers have dependencies on KHR headers and this should be
coming from EGL provider rather than mesa. Because EGL application
which have dependencies on EGL header, do not pull gl headers.
Signed-off-by: Madhurkiran Harikrishnan <madhurkiran.harikrishnan@xilinx.com>
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
|
|
libmali-xlnx provides multiple shared libraries to support the update
alternatives mechanism. For this, shared libraries with different
backends are installed to the target and softlinked to libmali-xlnx.so.
When do_package task runs,
1. It creates a pkgdata/libmali-xlnx file that generates a list of
packages. In this case:
PACKAGES: libmali-xlnx-src libmali-xlnx-dbg libmali-xlnx-staticdev
libmali-xlnx-dev libmali-xlnx-doc libmali-xlnx-locale libmali-xlnx
libmali-xlnx-x11 libmali-xlnx-fbdev libmali-xlnx-wayland
libmali-xlnx-headless
2. It also tries to identify what are the shlibs files and creates a
pkgdata/shlibs2/libmali-xlnx.list file.
- The .list file contains a list of all shared object files
being provided by a package.
- This list is created by looking at list of packages from above
one by one.
- It creates a list of available .so files for target os and
then uses objdump -p to get more info(NEEDED and SONAME) about
the object files
- Writes to .list file with list of .so files and the paths
installed.
- This is generated by only looking at the .so files in each
package and not the defaiult backend being used in the recipe.
In Zeus, with this commit f7d46843e93f1acb4872bd5bcc12ed734de5168b on
package.bbclass, multiple shlib_providers for the same file error. Hence
when packages like cairo, qtbase build they error out with the following
error:
Multiple shlib providers for libMali.so.9: libmali-xlnx,
libmali-xlnx,libmali-xlnx, libmali-xlnx
Why this error generates for packages using libmali-xlnx:
When cairo/qtbase packages run do_package task, bitbake generates a
shlibs_provider_map list containing information (soname,ldir,ver) for
the given package using shlibs2/*.list files copied to pkgdata-sysroots.
libmali-xlnx.list contains list of all .so files installed inspite
default MALI_BACKEND_DEFAULT provider. Since the shlibs_provider_map
contains more than one provider, bitbake generates the above error and
fails.
To fix the above issue, append to the do_package task to update
the libmali-xlnx.list to specify only the MALI_BACKEND_DEFAULT provider
shlib and discard the remaining unused shlibs.
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
|
|
Normally, when the colon ':' separator is on the right, the assignment
is meant to be prepended to the variable. Using the _append override
with both colon and spaces is an incoherent use of the FILESEXTRAPATH
variable:
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-FILESEXTRAPATHS
Also removed the r9p0... path as it doesn't exist.
Signed-off-by: Jean-Francois Dagenais <jeff.dagenais@gmail.com>
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Upgrade the Mali-400 userspace driver to r9p0.
Key features:
-Minor bug fixes
-Add user space support of GBM for MESA 17.3
-Supports Wayland > 1.15
Signed-off-by: Madhurkiran Harikrishnan <madhurkiran.harikrishnan@xilinx.com>
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Mesa-GL provides the KHR headers since 87c156183 (mesa)
even if egl is not selected, assuming opengl is.
This creates a conflict since when something DEPENDS
on virtual/libgl and virtual/gles1, both dependencies
will provide the same file.
Dont provide KHR headers to avoid this conflict.
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Create a variable for monolithic library as it will be easy to call/make
changes for future revision upgrade.
Signed-off-by: Madhurkiran Harikrishnan <madhurkiran.harikrishnan@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Since we cant rely on the fact that apps will use pkgconfig correctly we
need to set the x11 headers accordingly (depending on DISTRO_FEATURES),
e.g. qtbase, or libepoxy
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Be less strict with dependencies, if a user doesnt want a certain
backend dont use or install dependencies for that backend.
While switching alternatives at runtime would technically work,
specifically speaking, the link to the selected alternative would be
created correctly, the backend itself wouldnt necessarly work for
obvious reasons, unless the user has the correct DISTRO_FEATURES enabled
in their DISTRO configuration, which would pull all the necessary
runtime dependencies for that backend.
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Use ANY_OF_DISTRO_FEATURES instead of REQUIRED_DISTRO_FEATURES
to avoid pulling unnecessary dependencies for users.
If a user wants to use a different backend, they should
modify their own conf to add the required DISTRO_FEATURE.
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Application binary interface are made consistent for all backends. GBM
API support is now available for any libMali monolithic library.
Signed-off-by: Madhurkiran Harikrishnan <madhurkiran.harikrishnan@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@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
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.
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.
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Starting from 1.15 wayland, wayland-egl implementations are wired from
wayland source code. EGL providers need not provide symbols/library.
Applications will hence be linked to the one provided by the wayland.
Signed-off-by: Madhurkiran Harikrishnan <madhurkiran.harikrishnan@xilinx.com>
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Upgrade MALI recipe and going forward from Wayland 1.15 the
implementation for wayland-egl comes from wayland, EGL providers can
leverage that and need not provide a separate implementation.
Signed-off-by: Madhurkiran Harikrishnan <madhurkiran.harikrishnan@xilinx.com>
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Package arch for libmali cannot be soc_variant specific since it will
cause the same library to be packaged differently between 'eg' and 'ev'
devices. This has to be soc_family specfic package which applies to
'zynqmp' family.
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Along with X11 and fbdev, MALI will now have wayland support as well.
Signed-off-by: Madhurkiran Harikrishnan <madhurkiran.harikrishnan@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
This recipe allows user to fetch the MALI 400 binaries from xilinx.com
manually and use it with compatible machines based on UltraScale+ for
libgles1/libgles2 and egl libraries.
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
Sai Hari Chandana Kalluri
Madhurkiran Harikrishnan
Mark Hatle
Jean-Francois Dagenais
Alejandro Enedino Hernandez Samaniego
Manjukumar Matha