Re: [meta-intel] [OE-core] [PATCH] tune-i586-nlp.inc: drop tuning file for Intel Quark/X1000 CPU
Someone (maybe me??) needs to create a meta-intel-community in which to
capture these sorts of things. Just because Intel, officially, doesn't
support it, doesn't mean all the existing Galileos (and I think there's
another devboard that uses the Quark?) out there should lose support.
On Thu, May 31, 2018 at 7:10 PM, Andre McCurdy wrote:
> The Quark machine was EOL'ed at the end of 2017 and all support for
> it has now been removed from meta-intel. Drop the associated tuning
> file from oe-core.
>
> http://git.yoctoproject.org/cgit.cgi/meta-intel/commit/?id=
> 5dbc69e339588834317b632119717996584b0d6c
>
> Signed-off-by: Andre McCurdy
> ---
> meta/conf/machine/include/tune-i586-nlp.inc | 19 ---
> 1 file changed, 19 deletions(-)
> delete mode 100644 meta/conf/machine/include/tune-i586-nlp.inc
>
> diff --git a/meta/conf/machine/include/tune-i586-nlp.inc
> b/meta/conf/machine/include/tune-i586-nlp.inc
> deleted file mode 100644
> index 88e5903..000
> --- a/meta/conf/machine/include/tune-i586-nlp.inc
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -# Settings for the GCC(1) cpu-type "quark":
> -#
> -#
> -#
> -DEFAULTTUNE ?= "i586-nlp-32"
> -
> -# Include the previous tune to pull in PACKAGE_EXTRA_ARCHS
> -require conf/machine/include/x86/arch-x86.inc
> -
> -# x86 with no lock prefix
> -TUNEVALID[i586-nlp] = "IA32 with Lock Prefix omitted"
> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'i586-nlp', '
> -march=i586 -Wa,-momit-lock-prefix=yes', '', d)}"
> -
> -# Quark tune feature
> -AVAILTUNES = "i586-nlp-32"
> -TUNE_FEATURES_tune-i586-nlp-32 = "${TUNE_FEATURES_tune-x86} i586-nlp"
> -BASE_LIB_tune-i586-nlp-32 = "lib"
> -TUNE_PKGARCH_tune-i586-nlp-32 = "i586-nlp-32"
> -PACKAGE_EXTRA_ARCHS_tune-i586-nlp-32 = "i586-nlp-32"
> --
> 1.9.1
>
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] galileo
Hi, I realize that the Galileo board has been completely abandoned; I'm not looking for "official" information, but I'm hoping someone would be willing to provide some anecdotal information... perhaps offline? I thought it would be a fun exercise to investigate updating the Linux image and arduino-IDE-toolchain for my Galileo Gen2 board. Unfortunately I've hit some walls and was looking for some ideas. With its LOCKing problem[*1], projects like Yocto and Buildroot are natural homes for Galileo support. It looks as though Galileo support was added to The Yocto Project somewhere around Dylan [1.4] with https://github.com/intel/Galileo-Runtime.git. Using the sub-repositories found there and a virtual machine I'm able to build a working toolchain which I can install in my Arduino 1.8.5 IDE to build, upload, and run Blink. I can also build a rootfs image, but there isn't much in the way of guidance on how to get the resulting artifacts cobbled together onto an SDcard. But if I leave the SDcard slot empty, I can boot the default flash image that was shipped with the board (which is based on Dylan), and the IDE and sketches all work[*2]. After Dylan, Galileo-Runtime.git appears to have been abandoned (it's still stuck at Dylan) and meta-intel-quark and meta-intel-galileo appear... for Daisy [1.6]. Building with these layers (with everything setup for Daisy) doesn't work out-of-the-box due to some complaining about circular dependencies of initscripts on initscripts. I've tried several different things and combinations, but I can't successfully build an image or toolchain using these layers. These layers also have Dizzy [1.7] branches, so I gave those a whirl too without any success either. After Dizzy, meta-intel-quark and meta-intel-galileo appear to have been abandoned and Quark/Galileo support migrated to meta-intel (and was subsequently removed after Rocko [2.4]). Along that path, the bootloader moved from grub0 to gummiboot to systemd-boot. The out-of-tree binutils -mquark-strip-lock patch was upstreamed as the -momit-lock-prefix option. The meta-intel layer included wic support making it dead-simple to create an SDcard from the build artifacts (yay!). Uclibc support died with Krogoth [2.1] (boo). And the suggested kernel for Quark moved from upstream linux-3.8 with about two dozen patches, to linux-intel-4.9 (as-is)... and this is where I'm stuck. In the early days it doesn't seem like there was much distinction between Quark and Galileo, they were mostly synonymous. But by the time we get to Rocko, we find that the linux-intel kernel has support for Quark, but nothing for Galileo. When I boot the factory-installed Dylan image, I find loads of stuff under /sys/class/gpio, /sys/class/pwm, and /sys/class/platform which are what the Arduino code uses for identification and interaction with the Arduino headers. When I run linux-intel[*3] I have a /sys/class/gpio that only claims 8 gpios are available for use, none of which appear to relate to the Arduino headers. Was the Galileo support never "upstreamed"? Not even in Intel's own kernel fork? With Rocko I can build a bootable image (yay!!) but without proper kernel support for Galileo the Arduino code stops quite abruptly when it finds it can't find /sys/class/platform/GalileoGen2. At this point I started looking at mraa/upm as a replacement for the Arduino libraries, but they have a similar problem. When trying to run the "blink_onboard.c" example program (the mraa equivalent to Arduino's Blink program) it fails because it wants to use GPIO13 and 31, but the kernel says there are only 8 GPIOs available. In summary: - I can build a toolchain using Galileo-Runtime.git and Poky Dylan in a VM that I can install in place of the Arduino toolchain, but this doesn't gain me much since the default Arduino toolchain is based on these same layers/versions[*4] - I can build, but can't assemble a working rootfs for my Galileo from Dylan - I can't build a toolchain nor assemble a working rootfs from anything until I get to Rocko - with Rocko I can build a bootable rootfs for my Galileo and a working toolchain for Arduino and/or I can use mraa/upm; however none of these programs work because although Rocko supports Quark (to some extent) support for Galileo seems to have stopped back in Dylan Thank you for reading to the end. I'm curious to know if anyone would like to comment on my findings and perhaps correct any historical inaccuracies or confirm what I've found. I'm also hoping someone might know of a repository somewhere out there with a more recent linux kernel with Quark+Galileo support that will work with Rocko. It's too bad there isn't a meta-intel-community layer out there where support for non-supported things could live on. Best regards, Trevor [*1] https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug [*2] the galileo arduino libraries are found at https://github.com/01org/corelibs-galileo [*3] which, by the way, is not even setup for Quark;
Re: [meta-intel] [PATCH] vaapi: remove as recipes moved to oe-core
Yes, this works great. Thanks! Build Configuration: BB_VERSION= "1.32.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "opensuse-42.2" TARGET_SYS= "x86_64-oe-linux" MACHINE = "intel-corei7-64" DISTRO= "nodistro" DISTRO_VERSION= "nodistro.0" TUNE_FEATURES = "m64 corei7" TARGET_FPU= "" meta = "master:91f856426c7523e1ebdf6d6f93f5fa7e509d6e49" meta-intel= "contrib/rburton/vaapi:705f10c57422035c2e5a80da86ce7dfb0f73f738" meta-oe meta-gnome= "master:e6c7a66eb4f3944059bd4fff4103f8a9fdcb167c" meta-browser = "master:3f4fc6dd50650417a0b966c4157f3ad7f3697633" meta-nodejs = "master:7d63ea2e056e96a617a6281613afff6fe7762619" meta-realtime = "master:c7807efaaa9933f45a68576c56a2ff2f9bd24203" NOTE: Tasks Summary: Attempted 5824 tasks of which 5751 didn't need to be rerun and all succeeded. -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 1/2] linux-yocto/4.4: Bump SRCREVs from v4.4.18 to v4.4.20
On Mon 2016-09-12 @ 02:38:04 PM, California Sullivan wrote:
> From linux-yocto-4.4:
>
> ---
> common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 4 ++--
> common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 4 ++--
> common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
> b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
> index f0dd1e0..b228941 100644
> --- a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
> +++ b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
> @@ -1,8 +1,8 @@
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> LINUX_VERSION_INTEL_COMMON = "4.4.18"
The above, and subsequent, need to be:
LINUX_VERSION_INTEL_COMMON = "4.4.20"
otherwise:
ERROR: linux-yocto-rt-4.4.18+gitAUTOINC+59290c5f61_b5e21aa988-r0
do_kernel_version_sanity_check: Package Version
(4.4.18+gitAUTOINC+59290c5f61_b5e21aa988) does not match of kernel being built
(4.4.20). Please update the PV variable to match the kernel source.
ERROR: linux-yocto-rt-4.4.18+gitAUTOINC+59290c5f61_b5e21aa988-r0
do_kernel_version_sanity_check: Function failed: do_kernel_version_sanity_check
(log file is located at
/z/layerindex-master/minnowmax/tmp/work/corei7-64-intel-common-fortress-linux/linux-yocto-rt/4.4.18+gitAUTOINC+59290c5f61_b5e21aa988-r0/temp/log.do_kernel_version_sanity_check.20430)
ERROR: Logfile of failure stored in:
/z/layerindex-master/minnowmax/tmp/work/corei7-64-intel-common-fortress-linux/linux-yocto-rt/4.4.18+gitAUTOINC+59290c5f61_b5e21aa988-r0/temp/log.do_kernel_version_sanity_check.20430
ERROR: Task
(/z/layerindex-master/layers/openembedded-core/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb:do_kernel_version_sanity_check)
failed with exit code '1'
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2
Hi Ross, On Wed 2016-07-27 @ 06:09:06 PM, Trevor Woerner wrote: > Thanks for continuing to help out :-) +1 > I've saved the entire contents of the following in ~/tmp/gst/no-opengl and > ~/tmp/gst/opengl (as appropriate): > > tmp/work/corei7-64--linux/gstreamer1.0-plugins-bad/1.8.2-r0/ > > $ diff -ur --brief no-opengl/image/ opengl/image/ | sort > [remove all "Files ... and ... differ" lines] > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstbluez.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstbluez.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstbz2.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstbz2.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstcurl.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstcurl.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstdashdemux.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstdashdemux.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstdtls.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstdtls.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgsthls.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgsthls.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstneonhttpsrc.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstneonhttpsrc.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstrsvg.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstrsvg.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstsbc.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstsbc.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: > libgstsmoothstreaming.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: > libgstsmoothstreaming.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstsndfile.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstsndfile.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstuvch264.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstuvch264.so > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstwebp.la > Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstwebp.so > Only in opengl/image/usr/include/gstreamer-1.0/gst: gl > Only in opengl/image/usr/lib/girepository-1.0: GstGL-1.0.typelib > Only in opengl/image/usr/lib/gstreamer-1.0: include > Only in opengl/image/usr/lib/gstreamer-1.0: libgstopengl.la > Only in opengl/image/usr/lib/gstreamer-1.0: libgstopengl.so > Only in opengl/image/usr/lib: libgstgl-1.0.la > Only in opengl/image/usr/lib: libgstgl-1.0.so > Only in opengl/image/usr/lib: libgstgl-1.0.so.0 > Only in opengl/image/usr/lib: libgstgl-1.0.so.0.802.0 > Only in opengl/image/usr/lib/pkgconfig: gstreamer-gl-1.0.pc > Only in opengl/image/usr/share/gir-1.0: GstGL-1.0.gir Even when I was sending this email I had a hard time explaining why there was such a difference between no adjustment to PACAKGECONFIG and "adding" opengl; it was odd that there were so many libraries "Only in no-opengl" :-) With the append: $ diff -ur --brief no-opengl/image/ append-opengl/image/ | sort Only in append-opengl/image/usr/include/gstreamer-1.0/gst: gl Only in append-opengl/image/usr/lib/girepository-1.0: GstGL-1.0.typelib Only in append-opengl/image/usr/lib/gstreamer-1.0: include Only in append-opengl/image/usr/lib/gstreamer-1.0: libgstopengl.la Only in append-opengl/image/usr/lib/gstreamer-1.0: libgstopengl.so Only in append-opengl/image/usr/lib: libgstgl-1.0.la Only in append-opengl/image/usr/lib: libgstgl-1.0.so Only in append-opengl/image/usr/lib: libgstgl-1.0.so.0 Only in append-opengl/image/usr/lib: libgstgl-1.0.so.0.802.0 Only in append-opengl/image/usr/lib/pkgconfig: gstreamer-gl-1.0.pc Only in append-opengl/image/usr/share/gir-1.0: GstGL-1.0.gir And this makes perfect sense (I didn't even have to remove any "Files ... and ... differ" lines). But what's odd is that you say that by default your build already had the opengl stuff :-( -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2
On Thu 2016-07-28 @ 10:21:35 AM, Burton, Ross wrote: > On 27 July 2016 at 23:09, Trevor Woerner <twoer...@gmail.com> wrote: > > > PACKAGECONFIG_pn-gstreamer1.0-plugins-bad = "opengl" > > > > You meant to put _append in there, as there's a large default value that > you're overriding. Good point! I did so: PACKAGECONFIG_pn-gstreamer1.0-plugins-bad_append = " opengl" and, using "-e", I get: # $PACKAGECONFIG_pn-gstreamer1.0-plugins-bad PACKAGECONFIG_pn-gstreamer1.0-plugins-bad=" opengl" That seems fishy since the others (like drm) aren't listed. I'll have to look into this... -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2
Hi Ross,
Thanks for continuing to help out :-)
On Wed 2016-07-27 @ 05:49:01 PM, Burton, Ross wrote:
> Hi Trevor,
>
> On 26 July 2016 at 19:24, Trevor Woerner <twoer...@gmail.com> wrote:
>
> > It seems as though adding:
> >
> > PACKAGECONFIG_pn-gstreamer1.0-plugins-bad = "opengl"
> >
> > to local.conf fixes the issue. But my distro does contain opengl as part of
> > its DISTRO_FEATURES. So I'm not entirely sure why this configuration option
> > wouldn't turn itself on by default :-(
> >
>
> Going back to this, it appears that for me at least with the standard
> configuration gstreamer-gl is always built, and enabling opengl simply adds
> more pieces to the gstreamer-gl library: out of the box it builds a
> gstreamer-gl which links to GLES.
Odd. I've done two builds
$ bitbake gstreamer1.0-plugins-bad
before each build I do
$ bitbake -c cleansstate gstreamer1.0-plugins-bad
for one of the builds I have the following line in conf/local.conf; for the
other, I don't:
PACKAGECONFIG_pn-gstreamer1.0-plugins-bad = "opengl"
I've saved the entire contents of the following in ~/tmp/gst/no-opengl and
~/tmp/gst/opengl (as appropriate):
tmp/work/corei7-64--linux/gstreamer1.0-plugins-bad/1.8.2-r0/
$ diff -ur --brief no-opengl/image/ opengl/image/ | sort
[remove all "Files ... and ... differ" lines]
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstbluez.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstbluez.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstbz2.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstbz2.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstcurl.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstcurl.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstdashdemux.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstdashdemux.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstdtls.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstdtls.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgsthls.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgsthls.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstneonhttpsrc.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstneonhttpsrc.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstrsvg.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstrsvg.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstsbc.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstsbc.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstsmoothstreaming.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstsmoothstreaming.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstsndfile.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstsndfile.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstuvch264.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstuvch264.so
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstwebp.la
Only in no-opengl/image/usr/lib/gstreamer-1.0: libgstwebp.so
Only in opengl/image/usr/include/gstreamer-1.0/gst: gl
Only in opengl/image/usr/lib/girepository-1.0: GstGL-1.0.typelib
Only in opengl/image/usr/lib/gstreamer-1.0: include
Only in opengl/image/usr/lib/gstreamer-1.0: libgstopengl.la
Only in opengl/image/usr/lib/gstreamer-1.0: libgstopengl.so
Only in opengl/image/usr/lib: libgstgl-1.0.la
Only in opengl/image/usr/lib: libgstgl-1.0.so
Only in opengl/image/usr/lib: libgstgl-1.0.so.0
Only in opengl/image/usr/lib: libgstgl-1.0.so.0.802.0
Only in opengl/image/usr/lib/pkgconfig: gstreamer-gl-1.0.pc
Only in opengl/image/usr/share/gir-1.0: GstGL-1.0.gir
I believe the libgstgl is what the gstreamer-vaapi build wants, and in my case
it only exists in the opengl build.
> Do you have some local/distro configuration which is fiddling the
> PACKAGECONFIG for gstreamer-plugins-bad, or does your DISTRO_FEATURES not
> contain opengl?
I don't think so. The only packageconfig I have is for my chromium build:
# $PACKAGECONFIG_pn-chromium-x11
PACKAGECONFIG_pn-chromium-x11="disable-api-keys-info-bar
ignore-lost-context impl-side-painting kiosk-mode"
# $PACKAGECONFIG [4 operations]
PACKAGECONFIG=""
# Handle PACKAGECONFIG
# PACKAGECONFIG ??= ""
# PACKAGECONFIG[foo] =
"--enable-foo,--disable-foo,foo_depends,foo_runtime_depends"
pkgconfigflags = d.getVarFlags("PACKAGECONFIG") or {}
pkgconfig = (d.getVar('PACKAGECONFIG', True) or "").split()
Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2
On Tue 2016-07-26 @ 10:53:34 PM, Burton, Ross wrote:
> On 26 July 2016 at 21:55, Trevor Woerner <twoer...@gmail.com> wrote:
>
> > To be honest, it's the comment that's confusing me:
> >
> > # opengl packageconfig factored out to make it easy for distros
> > # and BSP layers to pick either (desktop) opengl, gles2, or no GL
> >
> > In any case, I've sent a patch. If it's wrong, I'm sure someone will point
> > it
> > out:
> >
> > https://patchwork.openembedded.org/patch/127991/
> >
Let me start by saying that I'm a bit out of my depth here; I've never quite,
100%, fully understood the whole opengl - x11 - gles - gles2 - mesa - drm -
... dance. But I do appreciate your explanation.
> Ah, interesting. I didn't actually look at the recipe... :/
>
> GLES is the more universal option, and GL is definitely only specific to
> certain pieces of hardware, so I can see why the recipe takes this approach.
>
> The alternative would be to see if gst-vaapi can be told to use GLES
> instead of GL out of the box, as that will run on far more hardware without
> modification.
The vaapi recipe doesn't have a PACKAGECONFIG for gles, but its ./configure
script does look for, find, and use(?) gles2 and gles3.
This recipe does contain the line:
${@bb.utils.contains("DISTRO_FEATURES", "opengl x11", "glx", "", d)}
[Does that work? What if "opengl" and "x11" aren't beside each other with one
space between them in $DISTRO_FEATURES?]
In any case, in my build, the "glx" PACKAGECONFIG flag gets turned on which:
PACKAGECONFIG[glx] = "--enable-glx,--disable-glx,virtual/mesa"
But even if I explicitly disable-glx in my configuration, configuring vaapi
still fails looking for gstreamer-gl-1.0 (as before). In fact, even if I turn
off all the PACKAGECONFIG options (i.e. --disable-) the configure
step of vaapi still fails.
Given your explanation, my patch from yesterday should be rejected. But I
don't know how to fix this, other than to add a PACKAGECONFIG for
gstreamer1.0-plugins-bad to add "opengl" in either my DISTRO or local.conf.
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2
On Tue 2016-07-26 @ 09:36:31 PM, Burton, Ross wrote: > On 26 July 2016 at 20:55, Trevor Woerner <twoer...@gmail.com> wrote: > > > Okay, I'm looking into what needs to get done. > > > > It's just a matter of using base_contains() on DISTRO_FEATURES in the > PACKAGECONFIG assignment in oe-core, there's plenty of examples across the > layer. To be honest, it's the comment that's confusing me: # opengl packageconfig factored out to make it easy for distros # and BSP layers to pick either (desktop) opengl, gles2, or no GL In any case, I've sent a patch. If it's wrong, I'm sure someone will point it out: https://patchwork.openembedded.org/patch/127991/ -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2
On Tue 2016-07-26 @ 08:15:10 PM, Burton, Ross wrote: > On 26 July 2016 at 19:24, Trevor Woerner <twoer...@gmail.com> wrote: > > > It seems as though adding: > > > > PACKAGECONFIG_pn-gstreamer1.0-plugins-bad = "opengl" > > > > to local.conf fixes the issue. But my distro does contain opengl as part of > > its DISTRO_FEATURES. So I'm not entirely sure why this configuration option > > wouldn't turn itself on by default :-( > > > > So a quick patch to make that automatically add itself when opengl is in > DISTRO_FEATURES is required. Can you send this? Okay, I'm looking into what needs to get done. -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2
On Tue 2016-07-26 @ 10:20:28 AM, Scott D Phillips wrote: > On Tue, Jul 26, 2016 at 01:09:21PM -0400, Trevor Woerner wrote: > > This commit is causing the following error in my builds: > > > > | checking for GST_VIDEO... yes > > | checking for GST_PBUTILS... yes > > | checking for GST_CODEC_PARSERS... yes > > | checking for GST_GL... configure: error: Package requirements > > (gstreamer-gl-1.0 >= 1.8.0) were not met: > > | > > | No package 'gstreamer-gl-1.0' found > > | > > | Consider adjusting the PKG_CONFIG_PATH environment variable if you > > | installed software in a non-standard prefix. > > | > > | Alternatively, you may set the environment variables GST_GL_CFLAGS > > | and GST_GL_LIBS to avoid the need to call pkg-config. > > | See the pkg-config man page for more details. > > | > > | WARNING: > > /z/layerindex-master/minnowmax/tmp/work/corei7-64-fortress-linux/gstreamer-vaapi-1.0/1.8.2-r0/temp/run.do_configure.31940:1 > > exit 1 from 'exit 1' > > | ERROR: Function failed: do_configure (log file is located at > > /z/layerindex-master/minnowmax/tmp/work/corei7-64-fortress-linux/gstreamer-vaapi-1.0/1.8.2-r0/temp/log.do_configure.31940) > > ERROR: Task > > /z/layerindex-master/layers/meta-intel/common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_1.8.2.bb:do_configure > > > > (/z/layerindex-master/layers/meta-intel/common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_1.8.2.bb:do_configure) > > failed with exit code '1' > > > > It appears that if you want to update gstreamer-vaapi you also need to > > provide > > a gstreamer-gl or enable some build flag to not want it. > > > > gstreamer-gl-1.0 is one of a few libraries provided by > gstreamer1.0-plugins-bad and I think it is properly stated as a > dependency of the gstreamer-vaapi build. True, gstreamer-gl seems to be build as part of gstreamer-bad: find . -name "*gstreamer-gl*" -print ./gstreamer1.0-plugins-bad/1.8.2-r0/0001-gstreamer-gl.pc.in-don-t-append-GL_CFLAGS-to-CFLAGS.patch ./gstreamer1.0-plugins-bad/1.8.2-r0/build/pkgconfig/gstreamer-gl-uninstalled.pc ./gstreamer1.0-plugins-bad/1.8.2-r0/build/pkgconfig/gstreamer-gl.pc ./gstreamer1.0-plugins-bad/1.8.2-r0/gst-plugins-bad-1.8.2/.pc/0001-gstreamer-gl.pc.in-don-t-append-GL_CFLAGS-to-CFLAGS.patch ./gstreamer1.0-plugins-bad/1.8.2-r0/gst-plugins-bad-1.8.2/.pc/0001-gstreamer-gl.pc.in-don-t-append-GL_CFLAGS-to-CFLAGS.patch/pkgconfig/gstreamer-gl.pc.in ./gstreamer1.0-plugins-bad/1.8.2-r0/gst-plugins-bad-1.8.2/patches/0001-gstreamer-gl.pc.in-don-t-append-GL_CFLAGS-to-CFLAGS.patch ./gstreamer1.0-plugins-bad/1.8.2-r0/gst-plugins-bad-1.8.2/pkgconfig/gstreamer-gl.pc.in ./gstreamer1.0-plugins-bad/1.8.2-r0/gst-plugins-bad-1.8.2/pkgconfig/gstreamer-gl-uninstalled.pc.in but nothing seems to be packaging it up (i.e. not found in packages-split). > Do you have gstreamer1.0-plugins-bad_1.8.2.bb under > poky/meta/recipes-multimedia/gstreamer ? Yes I do (as part of openembedded-core). -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2
This commit is causing the following error in my builds: | checking for GST_VIDEO... yes | checking for GST_PBUTILS... yes | checking for GST_CODEC_PARSERS... yes | checking for GST_GL... configure: error: Package requirements (gstreamer-gl-1.0 >= 1.8.0) were not met: | | No package 'gstreamer-gl-1.0' found | | Consider adjusting the PKG_CONFIG_PATH environment variable if you | installed software in a non-standard prefix. | | Alternatively, you may set the environment variables GST_GL_CFLAGS | and GST_GL_LIBS to avoid the need to call pkg-config. | See the pkg-config man page for more details. | | WARNING: /z/layerindex-master/minnowmax/tmp/work/corei7-64-fortress-linux/gstreamer-vaapi-1.0/1.8.2-r0/temp/run.do_configure.31940:1 exit 1 from 'exit 1' | ERROR: Function failed: do_configure (log file is located at /z/layerindex-master/minnowmax/tmp/work/corei7-64-fortress-linux/gstreamer-vaapi-1.0/1.8.2-r0/temp/log.do_configure.31940) ERROR: Task /z/layerindex-master/layers/meta-intel/common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_1.8.2.bb:do_configure (/z/layerindex-master/layers/meta-intel/common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_1.8.2.bb:do_configure) failed with exit code '1' It appears that if you want to update gstreamer-vaapi you also need to provide a gstreamer-gl or enable some build flag to not want it. On Fri 2016-07-22 @ 04:16:20 PM, Scott D Phillips wrote: > gstreamer got updated from 1.6.x to 1.8.x back in May: > > > e9c85d5 gstreamer1.0: upgrade to version 1.8.1 > > With the 1.8.x series gstreamer-vaapi got integrated into the > maintainership of the greater GStreamer project. The old 0.7.0 > pre-upstream version of gstreamer-vaapi has never been verified > against 1.8.x so we need to update here. > > Also it's worth noting that the old github-homed version of > gstreamer-vaapi strove to support multiple release versions of > GStreamer. This is no longer the case with the upstreamed > gstreamer-vaapi, so we need to try to coordinate updates in > gstreamer and gstreamer-vaapi to not get any funky regressions. > > This update (vs 0.7.0) is known to be tested with new platforms > APL and KBL as well as contain bug fixes for SKL. It is also known > to correct a playback issue with VP9 on all platforms. > > Scott D Phillips (1): > gstreamer-vaapi: Update to upstream version 1.8.2 > > .../gstreamer/gstreamer-vaapi-1.0_0.7.0.bb | 8 -- > .../gstreamer/gstreamer-vaapi-1.0_1.8.2.bb | 6 + > .../gstreamer/gstreamer-vaapi.inc | 4 +-- > ...5-Fix-offset-calculation-in-codec_data-pa.patch | 31 > -- > 4 files changed, 7 insertions(+), 42 deletions(-) > delete mode 100644 > common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_0.7.0.bb > create mode 100644 > common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_1.8.2.bb > delete mode 100644 > common/recipes-multimedia/gstreamer/gstreamer-vaapi/0001-decoder-h265-Fix-offset-calculation-in-codec_data-pa.patch > > -- > 2.5.5 > > -- > ___ > meta-intel mailing list > meta-intel@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-intel -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] gma500_gfx: Avoid inserting gma500_gfx module for certain devices
On 02/24/16 09:18, Trevor Woerner wrote: This patch assumes git://git.yoctoproject.org/meta-yocto is included in bblayers , is this a requirement? -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] gma500_gfx: Avoid inserting gma500_gfx module for certain devices
This patch assumes git://git.yoctoproject.org/meta-yocto is included in bbappends, is this a requirement? I'm asking because up until this point I haven't been using meta-yocto since my DISTRO isn't poky but my builds seem to be working okay. Also, there's no mention of dependencies in the README. -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
