Re: [meta-intel] [PATCH] xf86-video-mga: upgrade 1.6.4 -> 1.6.5

[Jussi Kukkonen]

On 13 August 2017 at 21:22,  wrote:

> From: sweeaun 
>
> Upgrade xf86-video-mga version to 1.6.5. Adapt block/wakeupHandler
> signature for ABI 23 patch has been removed as the change already
> available from Upstream 1.6.5.
>
> Signed-off-by: sweeaun 
> ---
>  .../xorg-driver/{xf86-video-mga_1.6.4.bb => xf86-video-mga_1.6.5.bb} | 5
> ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>  rename common/recipes-graphics/xorg-driver/{xf86-video-mga_1.6.4.bb =>
> xf86-video-mga_1.6.5.bb} (74%)
>
> diff --git a/common/recipes-graphics/xorg-driver/xf86-video-mga_1.6.4.bb
> b/common/recipes-graphics/xorg-driver/xf86-video-mga_1.6.5.bb
> similarity index 74%
> rename from common/recipes-graphics/xorg-driver/xf86-video-mga_1.6.4.bb
> rename to common/recipes-graphics/xorg-driver/xf86-video-mga_1.6.5.bb
> index 61b2d3c..de98239 100644
> --- a/common/recipes-graphics/xorg-driver/xf86-video-mga_1.6.4.bb
> +++ b/common/recipes-graphics/xorg-driver/xf86-video-mga_1.6.5.bb
> @@ -7,7 +7,6 @@ DESCRIPTION = "mga is an Xorg driver for Matrox video
> cards"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=bc1395d2cd32dfc5d6c57d2d8f83d3fc"
>
>  SRC_URI += "file://checkfile.patch \
> -file://0001-Adapt-Block-WakeupHandler-signature-for-ABI-23.patch
> \
>

You should remove the actual patch too.

Thanks,
  Jussi


 "
>
>  DEPENDS += "virtual/libx11 libpciaccess"
> @@ -16,8 +15,8 @@ PR = "r1"
>
>  COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'
>
> -SRC_URI[md5sum] = "cd3db8370caa3e607614ea4e74d4c350"
> -SRC_URI[sha256sum] = "48c6690b6751c76f53de64f8dbeaa9
> d6c62dbcfe890c768fd87167951247d44f"
> +SRC_URI[md5sum] = "3ee2549247e01de3e7bce52c27483118"
> +SRC_URI[sha256sum] = "b663cd8e6364f7c4e2637b9fcab986
> 1d0e3971518c73b00d213f6545a1289422"
>
>  PACKAGECONFIG ?= "${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
> 'dri', '', d)}"
>  PACKAGECONFIG[dri] = "--enable-dri,--disable-dri,drm
> xf86driproto,xserver-xorg-extension-dri"
> --
> 2.7.4
>
> --
> ___
> 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] iucode-tool: upgrade to 2.1.2

[Jussi Kukkonen]

Hi,

Can you turn rename detection on in your git config? The patch should be
much smaller then.

Something like this in .gitconfig:
---
[diff]
renames = copy
---

Thanks,
  Jussi


On 9 June 2017 at 03:38,  wrote:

> From: sweeaun 
>
> Signed-off-by: sweeaun 
> ---
>  common/recipes-core/microcode/iucode-tool_2.1.1.bb | 33
> --
>  common/recipes-core/microcode/iucode-tool_2.1.2.bb | 33
> ++
>  2 files changed, 33 insertions(+), 33 deletions(-)
>  delete mode 100644 common/recipes-core/microcode/iucode-tool_2.1.1.bb
>  create mode 100644 common/recipes-core/microcode/iucode-tool_2.1.2.bb
>
> diff --git a/common/recipes-core/microcode/iucode-tool_2.1.1.bb
> b/common/recipes-core/microcode/iucode-tool_2.1.1.bb
> deleted file mode 100644
> index 66cb0f9..000
> --- a/common/recipes-core/microcode/iucode-tool_2.1.1.bb
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -SUMMARY = "Update Intel CPU microcode"
> -
> -DESCRIPTION = "iucode_tool is a program to manipulate Intel i686 and
> X86-64\
> - processor microcode update collections, and to use the kernel facilities
> to\
> - update the microcode on Intel system processors.  It can load microcode
> data\
> - files in text and binary format, sort, list and filter the microcode
> updates\
> - contained in these files, write selected microcode updates to a new file
> in\
> - binary format, or upload them to the kernel. \
> - It operates on microcode data downloaded directly from Intel:\
> - http://feeds.downloadcenter.intel.com/rss/?p=2371\
> -"
> -HOMEPAGE = "https://gitlab.com/iucode-tool/;
> -BUGTRACKER = "https://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=
> normal;archive=0;src=iucode-tool;repeatmerged=0"
> -
> -LICENSE = "GPLv2+"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
> -file://iucode_tool.c;beginline=1;endline=15;md5=
> 5d8e3639c3b6a80e7d5e0e073933da16"
> -
> -DEPENDS_append_libc-musl = " argp-standalone"
> -
> -SRC_URI = "https://gitlab.com/iucode-tool/releases/raw/master/
> iucode-tool_${PV}.tar.xz"
> -SRC_URI_append_libc-musl = " file://0001-Makefile.am-Add-
> arg-parse-library-for-MUSL-support.patch"
> -
> -SRC_URI[md5sum] = "306d20b43da847812af4bf973f46045d"
> -SRC_URI[sha256sum] = "8f94ec73f5d4d1a6801aaa894fa1c6
> 544d9b27aec16e1a00e18e8241c7e0f6ba"
> -
> -inherit autotools
> -
> -BBCLASSEXTEND = "native"
> -
> -COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
> -
> -UPSTREAM_CHECK_URI = "https://gitlab.com/iucode-tool/releases;
> diff --git a/common/recipes-core/microcode/iucode-tool_2.1.2.bb
> b/common/recipes-core/microcode/iucode-tool_2.1.2.bb
> new file mode 100644
> index 000..e1fb56f
> --- /dev/null
> +++ b/common/recipes-core/microcode/iucode-tool_2.1.2.bb
> @@ -0,0 +1,33 @@
> +SUMMARY = "Update Intel CPU microcode"
> +
> +DESCRIPTION = "iucode_tool is a program to manipulate Intel i686 and
> X86-64\
> + processor microcode update collections, and to use the kernel facilities
> to\
> + update the microcode on Intel system processors.  It can load microcode
> data\
> + files in text and binary format, sort, list and filter the microcode
> updates\
> + contained in these files, write selected microcode updates to a new file
> in\
> + binary format, or upload them to the kernel. \
> + It operates on microcode data downloaded directly from Intel:\
> + http://feeds.downloadcenter.intel.com/rss/?p=2371\
> +"
> +HOMEPAGE = "https://gitlab.com/iucode-tool/;
> +BUGTRACKER = "https://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=
> normal;archive=0;src=iucode-tool;repeatmerged=0"
> +
> +LICENSE = "GPLv2+"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
> +file://iucode_tool.c;beginline=1;endline=15;md5=
> 5d8e3639c3b6a80e7d5e0e073933da16"
> +
> +DEPENDS_append_libc-musl = " argp-standalone"
> +
> +SRC_URI = "https://gitlab.com/iucode-tool/releases/raw/master/
> iucode-tool_${PV}.tar.xz"
> +SRC_URI_append_libc-musl = " file://0001-Makefile.am-Add-
> arg-parse-library-for-MUSL-support.patch"
> +
> +SRC_URI[md5sum] = "c6f131a0b69443f5498782a2335973fa"
> +SRC_URI[sha256sum] = "01f1c02ba6935e0ac8440fb594c2ef
> 57ce4437fcbce539e3ef329f55a6fd71ab"
> +
> +inherit autotools
> +
> +BBCLASSEXTEND = "native"
> +
> +COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
> +
> +UPSTREAM_CHECK_URI = "https://gitlab.com/iucode-tool/releases;
> --
> 2.7.4
>
> --
> ___
> 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

[meta-intel] [PATCHv2] libyami: Add PACKAGECONFIG for x11

[Jussi Kukkonen]

Without this the recipe fails to build without x11, breaking world build.

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---

Changes since v1:
 * Rebase on current master (conflicted with Patricks "support distro
   without OpenGL")

 common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb 
b/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb
index fcd28f8..b069628 100755
--- a/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb
+++ b/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb
@@ -21,3 +21,10 @@ EXTRA_OECONF = " --enable-tests-gles --disable-md5"
 inherit autotools pkgconfig distro_features_check
 
 REQUIRED_DISTRO_FEATURES = "opengl"
+
+PACKAGECONFIG = "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
+
+# --enable-x11 needs libva-x11
+# gles-tests fail to build without x11: see 
https://github.com/01org/libyami-utils/issues/91
+PACKAGECONFIG[x11] = "--enable-x11 --enable-tests-gles,--disable-x11 
--disable-tests-gles, virtual/libx11"
+
-- 
2.1.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH] libyami: Add PACKAGECONFIG for x11

[Jussi Kukkonen]

Without this the recipe fails to build without x11, breaking world build.

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb 
b/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb
index c61fec8..64f8850 100755
--- a/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb
+++ b/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb
@@ -18,4 +18,10 @@ DEPENDS = "libva libyami"
 
 EXTRA_OECONF = " --enable-tests-gles --disable-md5"
 
+PACKAGECONFIG = "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
+
+# --enable-x11 needs libva-x11
+# gles-tests fail to build without x11: see 
https://github.com/01org/libyami-utils/issues/91
+PACKAGECONFIG[x11] = "--enable-x11 --enable-tests-gles,--disable-x11 
--disable-tests-gles, virtual/libx11"
+
 inherit autotools pkgconfig
-- 
2.1.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] Why libva-egl1 request x11 in a Wayland configuration

[Jussi Kukkonen]

On 2 December 2016 at 18:30, Dominig Ar Foll 
wrote:

> Hello,
>
> I am activating libva in AGL distribution which is based on Yocto 2.1
> (krogoth).
>
> Adding in the local.conf the request fro libva, va-instal and
> gstreamer-vaapi seems to do the trick for an image.
> IMAGE_INSTALL_append += " \
>libva \
>va-intel \
>gstreamer-vaapi-1.0 "
>
> My issue comes when I try to build the SDK. Then I get the following error:
>Computing transaction...warning: Can't install
> libva-dev-1.7.0-r0@corei7_64: Can't install
> libva-egl1-1.7.0-r0@corei7_64: no package provides libva-x11
> warning: Can't install gstreamer-vaapi-1.0-dev-0.7.0-r0@corei7_64:
> unable to install provider for libva-dev:
>
> When I look in libva-egl1 I can see that it call for x11 as well as
> Wayland .But I do not understand why ?
>
>
I suspect this is incorrect in the recipe:
RDEPENDS_${PN}-egl =+ "${PN}-x11"
or does something actually link with libx11?

- Jussi


Any hint would be very welcome.
>
> Dominig
>
>   dominig@dominig-t460:~/AGL/build> rpm -qpR
> ./tmp/work/corei7-64-agl-linux/libva/1.7.0-r0/deploy-
> rpms/corei7_64/libva-egl1-1.7.0-r0.corei7_64.rpm
> attention : ./tmp/work/corei7-64-agl-linux/libva/1.7.0-r0/deploy-
> rpms/corei7_64/libva-egl1-1.7.0-r0.corei7_64.rpm:
> Entête V4 DSA/SHA1 Signature, clé ID c
> da422ed: NOKEY
> libffi.so.6()(64bit)
> libegl-mesa >= 11.1.1
> libwayland-server.so.0()(64bit)
> libwayland-client.so.0()(64bit)
> libdrm.so.2()(64bit)
> libva.so.1()(64bit)
> libEGL.so.1()(64bit)
> libdl.so.2()(64bit)
> libffi6 >= 3.2.1
> libc.so.6(GLIBC_2.2.5)(64bit)
> libva-x11
> libva >= 1.7.0
> wayland >= 1.9.0
> librt.so.1()(64bit)
> libgbm1 >= 11.1.1
> libdrm2 >= 2.4.67
> libexpat.so.1()(64bit)
> libc6 >= 2.23
> libgbm.so.1()(64bit)
> libm.so.6()(64bit)
> rtld(GNU_HASH)
> libc.so.6()(64bit)
> libpthread.so.0()(64bit)
> libexpat1 >= 2.1.0
> libffi.so.6()(64bit)
> libegl-mesa >= 11.1.1
> libwayland-server.so.0()(64bit)
> libwayland-client.so.0()(64bit)
> libdrm.so.2()(64bit)
> libva.so.1()(64bit)
> libEGL.so.1()(64bit)
> libdl.so.2()(64bit)
> libffi6 >= 3.2.1
> libc.so.6(GLIBC_2.2.5)(64bit)
> libva-x11
> libva >= 1.7.0
> wayland >= 1.9.0
> librt.so.1()(64bit)
> libgbm1 >= 11.1.1
> libdrm2 >= 2.4.67
> libexpat.so.1()(64bit)
> libc6 >= 2.23
> libgbm.so.1()(64bit)
> libm.so.6()(64bit)
> rtld(GNU_HASH)
> libc.so.6()(64bit)
> libpthread.so.0()(64bit)
> libexpat1 >= 2.1.0
> /bin/sh
> dominig@dominig-t460:~/AGL/build>
>
> --
> Dominig ar Foll
> Senior Software Architect
> Intel Open Source Technology Centre
> --
> ___
> 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] canterbury-corpus: Use base_libdir in FILES

[Jussi Kukkonen]

On 23 May 2016 at 14:48, Burton, Ross <ross.bur...@intel.com> wrote:
>
> On 23 May 2016 at 12:41, Jussi Kukkonen <jussi.kukko...@intel.com> wrote:
>>
>> -FILES_${PN} = "/lib/firmware/*"
>> +FILES_${PN} = "${base_libdir}/firmware/*"
>
> If these files are being loaded by the kernel firmware loader then /lib is
> right and the rest of the recipe is wrong.

So I doubt they're loaded by the firmware loader (they are random data
files, a compression test corpus) but maybe they are being used in a
test inside the kernel and the firmware directory is hack to find
them?

I'm CCing some people who have touched the qat16 recipe lately (as it
seems to do similar things).

Rahul or Anuj: The issue is that canterbury-corpus fails to package if
$base_libdir != "/lib/".  Do you know whether the canterbury-corpus
recipe is actually used by something (I'm asking since qat16 seems to
install practically the same data itself)? If it is used, should the
files be installed into /lib/ ?

Jussi
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] canterbury-corpus: Use base_libdir in FILES

[Jussi Kukkonen]

On 23 May 2016 at 14:48, Burton, Ross <ross.bur...@intel.com> wrote:
>
> On 23 May 2016 at 12:41, Jussi Kukkonen <jussi.kukko...@intel.com> wrote:
>>
>> -FILES_${PN} = "/lib/firmware/*"
>> +FILES_${PN} = "${base_libdir}/firmware/*"
>
>
> If these files are being loaded by the kernel firmware loader then /lib is
> right and the rest of the recipe is wrong.

I see, I'll find out if that's the case and resend.

Thanks

> Ross
>
> -
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH] canterbury-corpus: Use base_libdir in FILES

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb 
b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
index db64e53..f54e87b 100644
--- a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
+++ b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
@@ -15,7 +15,7 @@ SRC_URI = 
"http://corpus.canterbury.ac.nz/resources/cantrbry.tar.gz;subdir=${BP}
 SRC_URI[md5sum] = "442e56cfffdf460d25b0b91650a55908"
 SRC_URI[sha256sum] = 
"f140e8a5b73d3f53198555a63bfb827889394a42f20825df33c810c3d5e3f8fb"
 
-FILES_${PN} = "/lib/firmware/*"
+FILES_${PN} = "${base_libdir}/firmware/*"
 
 do_install () {
# do_unpack creates this directory but we don't want to install it, so
-- 
2.1.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH] gstreamer-vaapi: Remove deprecated configure option

[Jussi Kukkonen]

0.6 removed support for GStreamer 0.10, and also removed
the configure option for selecting the supported api (it now
always autodetects the 1.x api).

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_0.6.1.bb | 2 --
 common/recipes-multimedia/gstreamer/gstreamer-vaapi.inc  | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_0.6.1.bb 
b/common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_0.6.1.bb
index 48cd6fd..9c07521 100644
--- a/common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_0.6.1.bb
+++ b/common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_0.6.1.bb
@@ -2,8 +2,6 @@ require gstreamer-vaapi.inc
 
 DEPENDS += "gstreamer1.0 gstreamer1.0-plugins-base gstreamer1.0-plugins-bad"
 
-GST_API_VERSION = "1.4"
-
 SRC_URI += "file://0001-libs-remove-unneeded-headers.patch"
 
 SRC_URI[md5sum] = "f01425481bd161f57334dab7ab4069d3"
diff --git a/common/recipes-multimedia/gstreamer/gstreamer-vaapi.inc 
b/common/recipes-multimedia/gstreamer/gstreamer-vaapi.inc
index 1d66124..6683a7b 100644
--- a/common/recipes-multimedia/gstreamer/gstreamer-vaapi.inc
+++ b/common/recipes-multimedia/gstreamer/gstreamer-vaapi.inc
@@ -20,7 +20,7 @@ inherit autotools pkgconfig gtk-doc
 
 PACKAGES =+ "${PN}-tests"
 
-EXTRA_OECONF += "--with-gstreamer-api=${GST_API_VERSION} 
--disable-builtin-libvpx"
+EXTRA_OECONF += "--disable-builtin-libvpx"
 
 PACKAGECONFIG ??= "drm \
${@base_contains("DISTRO_FEATURES", "opengl x11", "glx", 
"", d)} \
-- 
2.1.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] intel-gpu-tools fails to build with man pages

[Jussi Kukkonen]

Hi,

Current intel-gpu-tools seems to fail to build if rst2man program is
available:
 * man pages are only built if rst2man is found
 * the source file for a man page, intel_reg.rst, is apparently not
included in 1.11 tarball

Second issue seems to be fixed in 1.12. Would be nice to have reproducible
builds as well and fix the first one too. I don't know anything about
intel-gpu-tools (found this during "bitbake world") so didn't upgrade
myself, hoping someone picks up the ball...

| make[2]: *** No rule to make target 'intel_reg.1', needed by 'all-am'.
Stop.
| make[2]: *** Waiting for unfinished jobs
| make[2]: Leaving directory
'/home/jku/src/poky/build/tmp/work/corei7-64-poky-linux/intel-gpu-tools/1.11-r0/build/man'
| Makefile:501: recipe for target 'all-recursive' failed
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory
'/home/jku/src/poky/build/tmp/work/corei7-64-poky-linux/intel-gpu-tools/1.11-r0/build'
| Makefile:433: recipe for target 'all' failed
| make: *** [all] Error 2

Regards,
  Jussi
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] Current GStreamer base and VAAPI libraries in poky + meta-intel unable to support HEVC/H265 decoding due to outdated version ?

[Jussi Kukkonen]

On 14 September 2015 at 10:45, Ahmad, Mohd Azril  wrote:

> Hi all,
>
>
>
> I’m currently testing the HEVC/H265 decoding by using the GStreamer-VAAPI
> and from the latest master commit that I’ve pulled (from poky and
> meta-intel), it seems that these two layers still contained the old version
> of the video stack where I do tried on H265 decoding (with VAAPI) and seems
> that it doesn’t work on my side (I guess is not supported)  :
>
>
>
> GStreamer 1.4.5
>
> GStreamer-plugins-base 1.4.5
>
> GStreamer-plugins- 1.4.5
>
> GStreamer-VAAPI 0.5.10
>
> libVA 1.5.0
>
> Intel-VA-driver 1.5.0
>
>
>
> I’m wondering whether is there any plan/direction for poky and meta-intel
> to move to the latest version of video stack so that the new video’s
> feature can be supported ?
>

GStreamer 1.5.x is the development/unstable version and those are typically
not used in oe-core / yocto: The stable 1.6 should be released Any Day Now
though.

It's very unlikely that GStreamer 1.6 will make it to the Yocto 2.0 release
but it should appear in poky master at some point in the next cycle.

HTH,
 Jussi
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 3/3] libva-intel-driver: Update to 1.6.0

[Jussi Kukkonen]

On 13 August 2015 at 09:09, Lim, Siew Hoon siew.hoon@intel.com wrote:

 On 23 July 2015 at 10:46, Lim Siew Hoon siew.hoon@intel.com wrote:
 +Tested-by: Lim, Siew Hoon siew.hoon@intel.com
 +Signed-off-by: Zhao Yakui yakui.z...@intel.com

 Missing Upstream-Status: Backport.

 Sorry. Ok, I will add in.
 I'm now a bit confused. Which upstream status I should be using Backport or 
 Accepted?
 Read in www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

 Now I felt sound like the accepted should be using.
 Backport also correct as well, I really backport the fixed from upstream 
 master into this fixed version.

I don't think your choice here matters, the important thing is that a
future maintainer upgrading this recipe can see that this patch
might/should be included in a future release: either choice works for
that. FWIW, I think accepted is the next step from submitted: a
status update for a yocto/oe patch that was also sent to upstream
mailing list or issue tracker. backport on the other hand is a
commit already in upstream that was then backported to yocto/oe.

 Is this information status needed like below:

 Upstream-Status: Accepted
 - The code fixed already accepted in upstream, and expected to be in next 
 release.
 - Currently backport this code fixed from upstream into 1.6.0 fixed version.
 - Bugzilla status for this issue is closed fixed.
 - Expected version info? Can I put wait for next release or totally skip 
 first?
 (Because I'm really sure what is next release version in libva-intel-driver. 
 It could be 1.6.1 or 1.7.0. This really depends on next release from 
 libva-intel-driver.)

If you know the version number the commit is (or will be) in, please
include the version number. If the code is not committed upstream yet
and you have a bug URL, please include the URL.

HTH,
  Jussi



 Thanks.
 siewhoon
 --
 ___
 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 1/3] gstreamer-vaapi: upgrade to 0.6.0 (v2)

[Jussi Kukkonen]

On 11 August 2015 at 15:15, Lim, Siew Hoon siew.hoon@intel.com wrote:

 From: Burton, Ross [mailto:ross.bur...@intel.com]
 Sent: Tuesday, August 11, 2015 7:15 PM
 To: Lim, Siew Hoon
 Cc: meta-intel@yoctoproject.org; Ho, Nee Shen
 Subject: Re: [meta-intel] [PATCH 1/3] gstreamer-vaapi: upgrade to 0.6.0 (v2)


 On 11 August 2015 at 11:49, Lim Siew Hoon siew.hoon@intel.com wrote:
 +DEPENDS = libva libva-intel-driver

 Is that an actual build dependency?  If it's a runtime dependency then you 
 mean RDEPENDS, and isn't gstreamer-vaapi driver-agnostic (although mainly 
 tested against the Intel driver)?

 Based on experience, it is better build and install the gstreamer-vaapi after 
 libva and libva-intel-driver get install first.
 Sometime it will screw up (video playback with corruption or performance) if 
 we didn't follow the sequence this experience in others OS distribution.

How could the intel driver affect how gstreamer-vaapi is built? That
sounds like it would be a gstreamer-vaapi bug if true.

 - Jussi

 If you think don't need then I can take out. But I just want to make sure 
 gstreamer-vaapi is built after libva-intel-driver get install in yocto.
 Question how do I check the gstreamer-vaapi is built after libva-intel-driver?

 Build and install sequence: libva - libva-intel-driver - gstreamer-vaapi.

 Thanks.
 ...siewhoon


 Ross
 --
 ___
 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