When we tried to build the meta-multimedia-image, we faced the
compilation issue with faad component.
Since faad component has commercial license, we could not able
to build with multimedia image. So we have modified the faad
component to be included when commercial licenese is supported.
Signed-off-by: Madhavan Krishnan <madhavan.krishnan@linaro.org>
No virtual/egl provider is available in the default setup with
vc4graphics enabled and neither opengl nor vulkan in DISTRO_FEATURES:
$ bitbake -e virtual/egl | tee env.egl
ERROR: Nothing PROVIDES 'virtual/egl'
vc-graphics-hardfp PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics-hardfp
vc-graphics PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics
$ bitbake -e userland 2>&1 | tee env.userland
ERROR: Nothing RPROVIDES 'libegl-mesa' (but /jenkins/mjansa/build-ros/ros2-dashing-warrior/meta-raspberrypi/recipes-graphics/userland/userland_git.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'libegl-mesa' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['libegl-mesa']
ERROR: Required build target 'userland' has no buildable providers.
Missing or unbuildable dependency chain was: ['userland', 'libegl-mesa']
$ bitbake -e mesa 2>&1 | tee env.mesa
ERROR: Nothing PROVIDES 'mesa'
mesa was skipped: one of 'vulkan opengl' needs to be in DISTRO_FEATURES
$ bitbake -e vc-graphics-hardfp 2>&1 | tee env.vc-graphics-hardfp
ERROR: Nothing PROVIDES 'vc-graphics-hardfp'
vc-graphics-hardfp was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics-hardfp
There is unbuildable dependency on virtual/egl from gstreamer1.0-plugins-base because:
1) gstreamer1.0-plugins-base depends on virtual/egl because of "egl" PACKAGECONFIG
2) "egl" PACKAGECONFIG is enabled by
meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend
PACKAGECONFIG_GL_rpi = "egl gles2"
without respecting the "opengl" in DISTRO_FEATURES like the recipe in oe-core does
openembedded-core/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.14.4.bb:
PACKAGECONFIG_GL ?= "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'gles2 egl', '', d)}"
3) virtual/egl is provided either by:
- userland (only without vc4graphics in MACHINE_FEATURES):
meta-raspberrypi/recipes-graphics/userland/userland_git.bb:PROVIDES += "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "", "virtual/libgles2 virtual/egl", d)}"
- mesa (selected with vc4graphics in MACHINE_FEATURES)
meta-raspberrypi/conf/machine/include/rpi-default-providers.inc:PREFERRED_PROVIDER_virtual/egl ?= "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "userland", d)}"
- vc-graphics(-hardfp)
meta-raspberrypirecipes-graphics/vc-graphics/vc-graphics.inc:PROVIDES = "virtual/libgles2 virtual/egl"
4) vc-graphics(-hardfp) recipe are skipped in default setup, because with vc4graphics being
in MACHINE_FEATURES by default since:
690bdca574
the PREFERRED_PROVIDER_virtual/libgles2 is set to mesa in:
conf/machine/include/rpi-default-providers.inc:PREFERRED_PROVIDER_virtual/libgles2 ?= "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "userland", d)}"
resulting in skipping the other virtual/libgles2 providers:
vc-graphics-hardfp PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics-hardfp
vc-graphics PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics
5) mesa is skipped when neither opengl nor vulkan are in DISTRO_FEATURES
6) userland doesn't provide virtual/egl because we have the default vc4graphics
meta-raspberrypi/recipes-graphics/userland/userland_git.bb:PROVIDES += "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "", "virtual/libgles2 virtual/egl", d)}"
and it cannot be built anyway, because with the default vc4graphics it depends on libegl-mesa:
meta-raspberrypi/recipes-graphics/userland/userland_git.bb:RDEPENDS_${PN} += "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "libegl-mesa", "", d)}"
and libegl-mesa is provided only by mesa recipe from oe-core which in turn
requires either "opengl" or "vulkan" to be in DISTRO_FEATURES
This causes a lot of unresolved dependencies in default setup with vc4graphics but without opengl.
- with Yocto 2.6 Thud and older it worked, because vc4graphics wasn't enabled by default before:
690bdca574
To build gstreamer1.0-plugins-base with egl PACKAGECONFIG enabled you have 2 options:
A) Just add "opengl" to DISTRO_FEATURES and use the default vc4graphics with mesa providing virtual/egl
B) Use DISABLE_VC4GRAPHICS added in
96c8459c93
to explicitly disable vc4graphics and use userland to provide virtual/egl
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Bump revision to fix playback errors on RPi 4 (https://github.com/popcornmix/omxplayer/issues/733)
and update patches accordingly.
Update the license hash because of the change in FSF mailing address.
Signed-off-by: Kirill Goncharov <kdgoncharov@gmail.com>
- Upgrade to latest omxplayer with ffmpeg 4.x
- drop backported patches which are not needed
- Make vc4 support patch conditionally apply only when vc4graphics is used
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Control the installs via MACHINE_FEATURES and avoid almost duplicate
recipe
Adjust other recipes to depend on userland now
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* Update to latest from upstream
* Backport OpenSSL 1.1.x related patches for ffmpeg
* Pass --cpu based on machine, instead of hardcoding it to arm1176jzf-s
* Make --cc, --cxx and --ld be used from environment, helps building
with clang
* It requires userland graphics driver to build to encode that in
COMPATIBLE_HOST
Signed-off-by: Khem Raj <raj.khem@gmail.com>
1.14 does not support this option
Fixes
QA Issue: gstreamer1.0-plugins-bad: configure was passed unrecognised options: --disable-dispmanx [unknown-configure-option]
Signed-off-by: Khem Raj <raj.khem@gmail.com>
fixes:
WARNING: gstreamer1.0-omx-1.12.4-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.htmlhttps://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch 0001-config-files-path.patch
patching file config/bellagio/gstomx.conf
Hunk #1 succeeded at 1 with fuzz 2.
Hunk #2 succeeded at 9 with fuzz 2.
patching file config/rpi/gstomx.conf
Hunk #8 succeeded at 63 with fuzz 2.
Hunk #10 succeeded at 82 with fuzz 2.
Hunk #11 succeeded at 92 with fuzz 2.
Now at patch 0001-config-files-path.patch
deleted obsolete `gstreamer1.0-omx` directory with duplicated patches that are also in `gstreamer1.0-omx-1.12`.
made file naming for `gstreamer1.0-omx_%.bbappend` consistent with the rest of the layer recipes.
Signed-off-by: Hugo Hromic <hhromic@gmail.com>
Remove the following unused patches:
1. 0002-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
2. 0003-fix-decoder-flushing.patch
Signed-off-by: Maxin B. John <maxin.john@intel.com>
* samba depends on libpam and it might be useful to disable support
for it in DISTROs without pam in DISTRO_FEATURES
* disable it by default
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
This used to work in the past because this machine was based on raspberrypi
one. Now that they are separate, we need a configuration for it too otherwise:
| common/arm/quant-a.S: Assembler messages:
| common/arm/quant-a.S:362: Error: selected processor does not support `rbit
r1,r1' in ARM mode
| common/arm/quant-a.S:363: Error: selected processor does not support `rbit
r1,r1' in ARM mode
Signed-off-by: Andrei Gherzan <andrei@gherzan.com>
* Update the recipe and patch the Makefile to not require internet access during
do_compile. Unfortunately, the upstream Makefile wants to access a web service
hosted on Heroku and to "git clone" ffmpeg with no fixed commit hash.
* Patch Makefile.ffmpeg to avoid a potential race condition between the
configure & compile stages.
Signed-off-by: Paul Barker <pbarker@toganlabs.com>
quant-a.S uses rbit thumb instruction unconditionally even though only
from ARMV6T2 this is available (which is not the case for RPI1, RPI0
etc). Avoid this by disabling asm.
Signed-off-by: Andrei Gherzan <andrei@resin.io>
Internal ffmpeg configure uses pr which is provided by coreutils-native:
| ./configure: line 471: pr: command not found
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
OE-Core rev: aa06a18d59eb391d1a7ace9daa0681bdf8daf17f
removed gstreamer1.0-omx_1.2.0 recipe.
OE-Core removed all gst git recipes as well
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Restructure the bbappends such that common portions
can be put in a common bbappend and version specific
bbappend then only do the patching
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Specifying -isystem${STAGING_DIR_HOST}/usr/include in INCLUDES gives:
In file included from utils/PCMRemap.cpp:26:0:
.../build/tmp/sysroots/raspberrypi2/usr/include/c++/6.1.1/cstdlib:75:25: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
^
compilation terminated.
Makefile:44: recipe for target 'utils/PCMRemap.o' failed
To resolve this, /usr/include shouldn't be specified as it is already a
default include path relative to the sysroot.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129.
Signed-off-by: Jonathan Liu <net147@gmail.com>
Fixes linking error due to missing vchostif library dependency.
Rebased patches and removed patches already merged upstream.
Signed-off-by: Jonathan Liu <net147@gmail.com>
Add a patch to fix the pkg-config mechanism in ffmpeg.
Change-Id: Ib506bb4e26a8a0c5c294ed55da0a0da8dc67a2d7
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
