Re: [meta-intel] [meta-intel PATCH] xf86-video-mga: upgrade and fix build

On 29 November 2012 23:37, Tom Zanussi tom.zanu...@intel.com wrote: OK, no problem, looks like the below should fix it. I'll test it and pull both in once I've verified... XAA has been dropped, so we need to drop the xaa module. The driver AFAICS is using the EXA module now, so you'll want

Re: [meta-intel] [PATCH 1/1] Revert emgd-driver-bin: add xorg-abi-video- dependency

On 2 December 2012 23:19, tom.zanu...@intel.com wrote: There's no explanation of what the actual problem was that this commit fixes - likely it was in response to the packaging problems causing YOCTO #3501 and YOCTO #3502. In any case, nothing should cause a regression like this since

Re: [meta-intel] BSP for Intel Atom N270 based system

On 27 February 2013 14:10, Peter Bergin peter.ber...@qmatic.com wrote: I will start a project based on Yocto project 1.3 and the target system is a board with a Intel Atom N270 processor together with Intel 945GSE ICH7M system chipset. Looking into meta-intel I can not find any MACHINE that

Re: [meta-intel] [PATCH 0/2] upgrade libva libva-intel-driver

On 7 March 2013 12:57, Laurentiu Palcu laurentiu.pa...@intel.com wrote: Hmmm, it seems that libva-egl package is not built because, in the new version, the check for egl availability is done using pkg-config. And the emgd-driver-bin does not provide an egl.pc file... There are 4 solutions to

Re: [meta-intel] [PATCH] emgd-driver-bin: add pkgconfig files

On 18 March 2013 22:53, Kamble, Nitin A nitin.a.kam...@intel.com wrote: I am also seeing build errors: | eglut.c: In function '_eglutDestroyWindow':eglut.c: In function '_eglutDestroyWindow': | | eglut.c:55:32: error: 'EGL_SCREEN_BIT_MESA' undeclared (first use in this

Re: [meta-intel] emgd-driver-dev and libgl-mesa-dev packaging conflict

On 19 April 2013 08:59, Laurentiu Palcu laurentiu.pa...@intel.com wrote: Is libva the only known package that needs the .pc files? Laurentiu, care to comment as this was your patch we're considering reverting? Yes, libva is the package needing the gl.pc file (libva-egl to be more specific).

Re: [meta-intel] emgd-driver-dev and libgl-mesa-dev packaging conflict

On 19 April 2013 22:33, Kamble, Nitin A nitin.a.kam...@intel.com wrote: This is issue with EMGD bsps only. So we will need to test only sdk images for EMGD BSPs with ipk packaging. Rest of the BSPs would not get affected if we just revert the .pc commit for the emgd recipe. Please don't revert

Re: [meta-intel] emgd-driver-dev and libgl-mesa-dev packaging conflict

On 21 April 2013 17:52, Kamble, Nitin A nitin.a.kam...@intel.com wrote: Hi Ross, As per Laurentiu's email as seen bellow he is proposing a different fix to the issue, so let's revert the commit and fix the issue properly when it will be needed. And as per Laurentiu's other email, he

Re: [meta-intel] [PATCH 0/2] Package upgrades

On 10 July 2013 16:23, Laurentiu Palcu laurentiu.pa...@intel.com wrote: The packages were compiled for sugarbay and also a core-image-sato image has been built. No issues encountered. Not tested on real HW though. Any help would be appreciated. My normal test for this is to do a gst-launch on

Re: [meta-intel] [PATCH 0/4] misc meta-intel Fixes

On 14 August 2013 20:46, nitin.a.kam...@intel.com wrote: Recently an issue was observed and fixed on meta-minnow, which was breaking builds when DISTRO is not poky. The same issue also exist on the crownbay, emenlow, fri2 sys940x BSPs. Here are the commits to fix the issue for these BSPs.

Re: [meta-intel] [PATCH 0/4] misc meta-intel Fixes

On 14 August 2013 21:49, Darren Hart darren.h...@intel.com wrote: So the correct way to build from oe-core without meta-yocto would be to append these values to DISTRO_FEATURES in local.conf? That or define our own DISTRO... which is basically what including meta-yocto does with poky. I did

Re: [meta-intel] [PATCH 1/1] emgd-driver-bin: mark opengl as a required distro feature

On 27 August 2013 18:57, nitin.a.kam...@intel.com wrote: +inherit distro_features_check +REQUIRED_DISTRO_FEATURES = opengl + Looks good. Acked-By: Ross Burton ross.bur...@intel.com Ross ___ meta-intel mailing list meta-intel@yoctoproject.org

Re: [meta-intel] [PATCH 4/5] xf86-video-intel: mark opengl as a required distro feature

On 5 September 2013 04:38, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com This recipe needs 'opengl' distro feature enabled. Otherwise build fails with this error: | intel.h:66:18: fatal error: dri2.h: No such file or directory Several things. 1) why does

Re: [meta-intel] [PATCH 4/5] xf86-video-intel: mark opengl as a required distro feature

On 5 September 2013 18:42, Darren Hart dvh...@linux.intel.com wrote: 2) configure has a --disable-dri option, did you see if this works? Glancing at the source there might actually be a hard dependency on DRI headers, but that can be something we can fix in the X server. Why do you want to

Re: [meta-intel] [OE-core] [Patch-v2 1/1] mesa: avoid unnecessary rerunning of tasks

On 5 September 2013 09:33, Richard Purdie richard.pur...@linuxfoundation.org wrote: I'd also appreciate someone (Ross maybe?) confirming that if we build application A against mesa, then change over to a machine that uses emgd and swizzle the libs around in the sysroot, do we need to recompile

Re: [meta-intel] [PATCH 4/5] xf86-video-intel: mark opengl as a required distro feature

On 6 September 2013 17:00, Kamble, Nitin A nitin.a.kam...@intel.com wrote: Even though it is technically possible, it will be crippling the Intel graphics driver. Do we have to do it? Is the other, non-crippling option of requesting opengl distro feature so bad? Feel free to put a comment

Re: [meta-intel] [PATCH] xf86-video-mga: respect opengl DISTRO_FEATURE

On 12 September 2013 21:57, Darren Hart dvh...@linux.intel.com wrote: So... if DISTRO_FEATURES does contain opengl and dri, how do we ensure glproto, virtuial/libgl, etc. are built prior to this recipe? That's why they were in DEPENDS right? No idea why they were in depends, as they're not

Re: [meta-intel] [PATCH] xserver-xf86-config: remove redundant files, clean up broken ones

On 19 September 2013 00:31, Darren Hart dvh...@linux.intel.com wrote: On Wed, 2013-09-18 at 23:23 +0100, Ross Burton wrote: Most BSPs appear to be derived from what appears to be a stale copy of the atom-pc xorg.conf which was either repeating defaults (the screen configuration), pointlessly

Re: [meta-intel] [PATCH] xserver-xf86-config: remove redundant files, clean up broken ones

On 19 September 2013 00:43, Burton, Ross ross.bur...@intel.com wrote: Typically we do changes like with one patch per BSP to help keep things a bit more flexible in the face of regressions. I started doing that but then got rapidly bored with copy-paste... I can split it up though. The same

Re: [meta-intel] [PATCH 1/4] crownbay, crownbay-noemgd: fix xorg.conf

On 1 October 2013 19:35, nitin.a.kam...@intel.com wrote: +OptionDontZap 0 This is the default, so you won't need this. I'd also love to see some xorg logs to understand why turning off hotplug makes input work - maybe the udev environment is broken. Ross

Re: [meta-intel] [PATCH 0/1] mesa.bbappend: sync version with oecore

From what I can tell the bbappend isn't being used anymore (thanks to mesa-gl) so we can just delete it. Ross On Monday, 4 November 2013, Laurentiu Palcu wrote: Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com javascript:; --- .../{mesa_9.1.6.bbappend = mesa_9.2.2.bbappend} |0

Re: [meta-intel] [PATCH 0/4] mesa build warning fixes

On 14 November 2013 22:15, tom.zanu...@intel.com wrote: From: Tom Zanussi tom.zanu...@intel.com While build-testing, I found a bunch of BSPs that didn't prefer the a matching mesa version, resulting in lots of warning spewage. There's only one version of Mesa in oe-core *and* mesa isn't used

Re: [meta-intel] [PATCH 2/2] xf86-video-ast: Enable ASPEED Tech Graphic Card

On 18 November 2013 07:57, boon.leong@intel.com wrote: +DEPENDS += virtual/libx11 drm xf86driproto glproto virtual/libgl libpciaccess The configure script doesn't appear to check for GL or DRM but does check for Xv which you've not listed. Please start from an empty DEPENDS and add

Re: [meta-intel] [minnowboard] EMGD and Wayland/Weston on minnowboard

On 20 November 2013 16:13, Behrens, Holger holger.behr...@windriver.com wrote: Currently the EMDG relnotes states Note: MeeGo 1.2 with Wayland feature is mainly for evaluation and testing purposes; it is not for production usage. any plans to extend the Wayland/Weston (eval.

Re: [meta-intel] [minnowboard] EMGD and Wayland/Weston on minnowboard

On 21 November 2013 08:00, Behrens, Holger holger.behr...@windriver.com wrote: Thank you for the update. Will have to go with an ARM based board instead then. Or anything based on Bay Trail for Atom, or obviously anything not-Atom. Alternatively speak to the EMGD team if you can demonstrate a

Re: [meta-intel] Enable Wayland in an image - Intel baytaril platform

On 29 November 2013 08:06, Somasekhar Reddy Mallireddigari -ERS, HCL Tech somasekha...@hcl.com wrote: We are trying to enable the Weston in image. We are building the “baytrail32-noemgd” image. We followed https://wiki.yoctoproject.org/wiki/Wayland When we try to launch Weston. We are

Re: [meta-intel] Enable Wayland in an image - Intel baytaril platform

On 2 December 2013 06:09, Somasekhar Reddy Mallireddigari -ERS, HCL Tech somasekha...@hcl.com wrote: [06:37:12,675] Loading modules '/usr/lib/weston/x11-backend.so' [06:37:12,680] initializing x11 backend libEGL warning: DRI2: failed to authenticate libEGL warning: DRI2: failed to open

Re: [meta-intel] [meta-fri] Graphics broken?

On 5 December 2013 11:31, Andrei Gherzan and...@gherzan.ro wrote: Testing xbmc on this, seems like hw accel is not working. Videos are very slow and I get this output: libva: Trying to open /usr/lib/dri/emgd_drv_video.so libva: va_openDriver() returns -1 Try using low-level tools such as

Re: [meta-intel] [meta-fri] Graphics broken?

On 5 December 2013 12:51, Andrei Gherzan and...@gherzan.ro wrote: Yes. I used that too. Nothing more than: libva: VA-API version 0.32.1 libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/dri/emgd_drv_video.so libva: va_openDriver() returns -1 vaInitialize failed with error

Re: [meta-intel] Enable Wayland in an image - Intel baytaril platform

On 9 December 2013 10:56, Somasekhar Reddy Mallireddigari -ERS, HCL Tech somasekha...@hcl.com wrote: [14:34:50,497] fatal: failed to create compositorte ioctl for device I've never seen that error when starting Weston, but I've not used that BSP (nor can I look at it) and I've not got that

Re: [meta-intel] [PATCH 1/7] xf86-video-ast: new recipe for ASPEED Technology Card

On 2 April 2014 12:45, boon.leong@intel.com wrote: +DEPENDS += virtual/libx11 libpciaccess Drivers shouldn't be linking to client libraries so you should be able to drop libx11 from here. +PR = r0 No need for this, remove. +COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)' Does this

Re: [meta-intel] [PATCH 1/7] xf86-video-ast: new recipe for ASPEED Technology Card

On 2 April 2014 16:30, Ong, Boon Leong boon.leong@intel.com wrote: Does this driver really only work on x86 hardware? I only validate it on x86 hardware. Since this goes under meta-intel, I suppose that is fine? Or, should I just remove that line entirely? I was referencing recipe written

Re: [meta-intel] [PATCH 0/5] Clean up corpus recipes

As per Nitin's comments, I've just re-pushed this branch (ross/canterbury) with extra inline comments. Ross -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 09/10] core-image-minimal-initramfs: extend to support early microcode loading

Hi, I've been having a quick look at the image generation code and am wondering if appending supplementary cpio blobs to an initramfs is something that is actually common and we should add support for that directly to the initramfs generation. Alternatively, using IMAGE_POSTPROCESS_COMMAND in

Re: [meta-intel] Supporting multiple GL providers

On 5 July 2014 00:51, Ash Charles ashchar...@gmail.com wrote: This seems like generally useful feature any time there are multiple GL providers for the same arch---is this assessment reasonable? Yes, it is. Ross -- ___ meta-intel mailing list

Re: [meta-intel] [PATCH 1/3] meta-intel/common: Initial Intel DPDK recipe under recipes-extended

On 8 July 2014 08:00, wei.sern.c...@intel.com wrote: +# Recipe Ingredients (source, patch, etc) +# Package Run-time dependency No need to add comments explaining what variables are for. +S = ${WORKDIR}/dpdk-${PV} This is the default, remove it. +export INSTALL_PATH = /opt/dpdk Why does

Re: [meta-intel] [PATCH 3/3] meta-romley: add Intel DPDK v1.6.0r2 support Romley machine config

On 8 July 2014 08:00, wei.sern.c...@intel.com wrote: +PREFERRED_PROVIDER_virtual/extended ?= dpdk What does this do? +PREFERRED_VERSION_dpdk ?= 1.6.0r2% There's only one version, so you don't need a preferred version. Ross -- ___ meta-intel

Re: [meta-intel] [PATCHv2 2/2] meta-romley: add Intel DPDK v1.6.0r2 support Romley machine config

On 10 July 2014 09:40, wei.sern.c...@intel.com wrote: Added MACHINE_EXTRA_RRECOMMENDS to include dpdk for romley machine configuration so that building on Romley will automatically pick up Intel DPDK. As far as I'm aware DPDK on it's own doesn't serve any purpose - it's a development

Re: [meta-intel] [PATCHv2 1/2] meta-intel/common: Initial Intel DPDK recipe under recipes-extended

On 10 July 2014 09:40, wei.sern.c...@intel.com wrote: +++ b/common/recipes-extended/dpdk/dpdk/dpdk-1.6.0r2-app-test-fix-build-switches-to-enable-cmdline-tests.patch @@ -0,0 +1,49 @@ +From cf953d2bfa7df9aa67459b333db4d4d8a9e72fd6 Mon Sep 17 00:00:00 2001 +From: Thomas Monjalon

Re: [meta-intel] [PATCHv2 1/2] meta-intel/common: Initial Intel DPDK recipe under recipes-extended

On 10 July 2014 09:40, wei.sern.c...@intel.com wrote: This is an initial version of Intel Data Plane Development Kits (DPDK) recipe support. This recipe is targetting on Intel DPDK v1.6.0r2. This recipe is created under meta-intel/common because Intel DPDK can be commonly used several Intel

Re: [meta-intel] [Patch v4 4/6] image-ucode.bbclass: a new bbclass for initramfs images

On 19 July 2014 01:18, nitin.a.kam...@intel.com wrote: +IMAGE_TYPES += cpio.gz.ucode +COMPRESSIONTYPES += gz.ucode +COMPRESS_CMD_gz.ucode = ${COMPRESS_CMD_gz}; cat ${EARLY_UCODE_CPIO} ${IMAGE_NAME}.rootfs.${type}.gz ${IMAGE_NAME}.rootfs.${type}.gz.ucode +COMPRESS_DEPENDS_gz.ucode =

Re: [meta-intel] [Patch v4 3/6] intel-microcode: a recipe for Intel microcode datafile

On 25 July 2014 17:49, Kamble, Nitin A nitin.a.kam...@intel.com wrote: Maybe we can wait for the intel microcode to go intoe linux-firmware, then this recipe will not be needed at all. But for that to happen intel-microcode needs to show up in the linux-firmware repo, and I will push on that

Re: [meta-intel] [Patch v5 5/5] use the INITRD list mechanism for early microcode loading

On 29 August 2014 18:22, nitin.a.kam...@intel.com wrote: # if enabled, include user space intel microcode loading support in the generated images. MACHINE_EXTRA_RRECOMMENDS = intel-microcode iucode-tool + +# if enabled, use the microcode added initrd I don't see any conditional tests for

Re: [meta-intel] [PATCH V2 3/3] meta-romley: DPDK v1.7.0 support for Romley machine config

On 17 September 2014 15:20, sreeju.armughanx.selva...@intel.com wrote: Added MACHINE_EXTRA_RRECOMMENDS to include dpdk v1.7.0 support for romley machiine, so that dpdk will be enabled by default for Romley. Also included the dpdk example package, so that user can use example apps to exercise

Re: [meta-intel] [PATCH 2/2] meta-intel.inc: allow disabling of Intel microcode

On 17 September 2014 20:44, nitin.a.kam...@intel.com wrote: As per request from Tom, allow disabling of the Intel microcode feature for meta-intel BSPs. If one adds this line to local.conf while build a meta-intel BSP, the microcode feature will be disabled for the build target.

Re: [meta-intel] (no subject)

On 16 September 2014 12:35, Stuart Weaver stuart.wea...@datapath.co.uk wrote: I've just made a fresh Yocto/meta-intel repository and created an image based on core-image-sato for valleyisland-32. What release or git revision of poky/yocto/oe-core are you using? The microcode support in git

Re: [meta-intel] [PATCH V2 3/3] meta-romley: DPDK v1.7.0 support for Romley machine config

On 18 September 2014 03:21, Ong, Boon Leong boon.leong@intel.com wrote: On their own, the DPDK packages are useless as the user needs to compile their application with them. What you're basically doing is forcing a library onto *every* image for that machine, even ones that don't want to

Re: [meta-intel] [PATCH V2 1/3] meta-intel/common: Add include file for DPDK

On 26 September 2014 07:58, Selvaraj, Sreeju ArmughanX sreeju.armughanx.selva...@intel.com wrote: Is this patch fine ? Do you have any feedback on this. It seems reasonable to me. Ross -- ___ meta-intel mailing list meta-intel@yoctoproject.org

Re: [meta-intel] [PATCH V2 2/3] meta-inte/common: Upgrade DPDK to v1.7.0

On 26 September 2014 10:34, Selvaraj, Sreeju ArmughanX sreeju.armughanx.selva...@intel.com wrote: Is This patch fine ? I didn't look at this in detail, but the patches need to have both Signed-off-by and Upstream-Status tags

Re: [meta-intel] [Patch v2 00/11] machinesetuptool commits

On 10 October 2014 22:18, Darren Hart dvh...@linux.intel.com wrote: The primary issue with eliminating the defaults from intel-corei7-64 and providing the default via machinesetuptool, is we then make machinesetuptool a requirement for that BSP for basic functionality. That isn't acceptable in

Re: [meta-intel] State of GPU/QuickSync support without X11 on yocto

On 17 October 2014 12:04, Volker Vogelhuber v.vogelhu...@digitalendoscopy.de wrote: So the open source driver fully supports quick sync and opengl in hardware as well? If yes I guess using gstreamer and mesa packages, right? I'm heading into guesswork here... Intel QuickSync is basically

Re: [meta-intel] Packages needed for gstreamer h264 libva encoding

On 20 October 2014 16:25, Volker Vogelhuber v.vogelhu...@digitalendoscopy.de wrote: Currently I added gstreamer1.0, gstreamer-vaapi-1.0 and libva-intel-driver to the image recipe, but it does not seem to add any h264 encoder at all. The decoder is in your hardware, so there's nothing to

Re: [meta-intel] [PATCH] intel-gpu-tools: add missing build-dependencies

On 4 November 2014 16:53, Darren Hart dvh...@linux.intel.com wrote: Was this manifesting as a racy build failure? Nope, new QA warnings. Presumably it's gone unnoticed as only the autobuilder does world builds, and nobody bothers checking those for warnings. Ross --

Re: [meta-intel] [PATCH v2 0/1] DPDK update

On 6 November 2014 16:22, Tom Zanussi tom.zanu...@linux.intel.com wrote: As there hasn't been any action on the various problems plaguing the DPDK recipes and we're coming up on a release, move them out of common/, at minimum. v2: Add COMPATIBLE_MACHINE for romley|romley-ivb Acked. Ross

Re: [meta-intel] [MinnowBoard][PATCH] systemd: Conditionally add network file for systemd

On 19 November 2014 22:00, Darren Hart dvh...@linux.intel.com wrote: It seems to be a tricky one as the network interfaces are BSP-specific. This is a follow-on to: $ git show e3718d2 commit e3718d24e9d2bbdac00d6f1ebd8cbe2894981e4e Author: Sujith H sujith_harida...@mentor.com Date:

Re: [meta-intel] [PATCH 0/3] Upgrades for comply Intel Graphics Stack Release 2014Q3

On 22 December 2014 at 17:53, Aníbal Limón anibal.li...@linux.intel.com wrote: Any comment? These have all been merged into master already. Ross -- ___ meta-intel mailing list meta-intel@yoctoproject.org

Re: [meta-intel] [PATCH 0/3] Upgrades for comply Intel Graphics Stack Release 2014Q3

On 22 December 2014 at 23:51, Aníbal Limón anibal.li...@linux.intel.com wrote: I think these confusion is related to the same subject in the email, sorry about it. Yeah, that caused gmail to merge them together for me, thanks google! Sometimes GMail really isn't great for patch review, sorry

Re: [meta-intel] GStreamer 1.0 and VAAPI

On 9 January 2015 at 20:58, Chris Tapp opensou...@keylevel.com wrote: I think I've got it working (well, building and in the image!), but it looks like GStreamer doesn't like my pipeline for a DVB-T stream (mpegts) as this starts with a few empty frames which causes libva to terminate the

Re: [meta-intel] GStreamer 1.0 and VAAPI

On 7 January 2015 at 17:43, Chris Tapp opensou...@keylevel.com wrote: Ignore gst-va-intel, all you need is gstreamer-vaapi-1.0 to get GStreamer 1.0 to do VAAPI. Thanks. What about va-intel and libva-intel-driver - looks like I need these? Erm, yeah, libva-intel-driver might be useful if

Re: [meta-intel] GStreamer 1.0 and VAAPI

On 2 January 2015 at 22:35, Chris Tapp opensou...@keylevel.com wrote: As I'm using GStreamer 1.0, I'm pulling gstreamer-vaapi-1.0 in to my image. How does gst-va-intel relate to this? I've tried adding this to my image as well, but that results in GStreamer 0.10 being pulled in, resulting in

Re: [meta-intel] The gma500_gfx driver, X server, OpenGL

On 17 March 2015 at 00:56, Erik Bolton ebol...@agjunction.com wrote: 2) Does the gma500_gfx driver support OpenGL/GLX at all? My assumption was that Intel wouldn’t drop the EMGD from the yocto BSPs that use this GPU if the new kernel driver didn’t have SOME 3D acceleration support, but

Re: [meta-intel] Core i5-4460S H81 machine

On 26 March 2015 at 01:12, Lai Eddy eddy.lai...@gmail.com wrote: I have a Core i5-4460S board with H81 chipset what MACHINE should I set in local.conf? intel-corei7-64? or genericx86-64 , intel-corei7-64. Ross -- ___ meta-intel mailing list

Re: [meta-intel] [PATCH 1/2] libva: Update to 1.5.0

On 27 February 2015 at 17:23, Darren Hart dvh...@linux.intel.com wrote: They are under test on wrath now. Will be on the AB shortly. What I should have mentioned is that I needed to upgrade libva libva-intel-driver and gstreamer-vaapi before video playback started to work again. Its like it

Re: [meta-intel] [PATCH 1/2] libva: Update to 1.5.0

On 27 February 2015 at 16:40, Darren Hart dvh...@linux.intel.com wrote: Whenever submitting a patch, please provide a commit message. Even if it's trivial, there is something to be said. Why should we do the update? Does it support new hardware? A particularly relevant feature? If not,

Re: [meta-intel] [PATCH] xf86-video-mga: Upgrade 1.6.2 - 1.6.4

On 11 May 2015 at 19:20, Saul Wold s...@linux.intel.com wrote: I think that this is probably in prep for the 1.17 upgrade. We are currently at 1.16.3 so we would not see the issue he is seeing. I think that we should take this patch. That's right. Ross --

Re: [meta-intel] Why meta-intel never specify the Intel-SNA as a primary Xorg driver in common folder ?

On 16 April 2015 at 12:48, Ong, Boon Leong boon.leong@intel.com wrote: Yes, some CID platform which is address data-center processor/chipset uses external PCIe VESA graphic card. And there's a number of Atom platforms that use GMA500/600 graphics and so need the modesettings driver. Ross

Re: [meta-intel] Why does libva-egl RDEPEND on libva-x11

On 1 July 2015 at 00:46, Tobias Olausson tobias.olaus...@pelagicore.com wrote: 1) Is there a reference system commonly used to verify changes? I built core-image-weston for corei7-64 with meta-intel on top of poky, would that be fitting? That would be a suitable build test, but actually

Re: [meta-intel] [PATCH v3] intel-gpu-tools: upgrade to version 1.11

On 12 August 2015 at 16:17, Saul Wold s...@linux.intel.com wrote: If you are running on a system with bash the /bin/sh will point to bash so there is no real change, the real test is to install these tools on a system without Bash and ensure they work. Or run checkbashisms, or just read the

Re: [meta-intel] [PATCH][RFC] Deprecate older Platform specific BSPs

On 23 August 2015 at 01:18, Saul Wold s...@linux.intel.com wrote: The intel-core* BSPs supercede these older BSPs therefore it's time to remove these older platform specific bsps. Deprecate isn't the word I'd use for deleting them, but I agree with deleting them entirely. Ross --

Re: [meta-intel] Why does libva-egl RDEPEND on libva-x11

On 29 June 2015 at 23:32, Tobias Olausson tobias.olaus...@pelagicore.com wrote: libva [1] includes libva-x11, libva-glx, libva-egl, libva-wayland etc. What I cannot understand is why libva-egl depends on libva-x11. Looking at configure.ac in the git repo for libva [2] it makes even less sense,

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)?

Re: [meta-intel] CrownBay EMGD acceleration for Daisy 1.6.3

On 13 August 2015 at 17:49, Chad Bishop chad.a.bis...@gmail.com wrote: The EMGD documentation for v1.18 of the driver speaks to EMGD support for Wayland / Weston. However the details are specific to Meego. I am writing to inquire as to whether the meta-intel CrownBay BSP provided for daisy

Re: [meta-intel] [PATCH] bsps: update meta SRCREVs

On 23 July 2015 at 23:38, Bruce Ashfield bruce.ashfi...@windriver.com wrote: You need the patches that I sent to oe-core that split the meta data from the kernel repository (see zedd/kernel in poky-contrib). The revs must exist in the yocto-kernel-cache repository. It's a chicken and egg

Re: [meta-intel] [fido][PATCH 2/2] common/intel-gpu-tools: Modularize and make X11 dependency optional

On 20 October 2015 at 09:43, Joonas Lahtinen < joonas.lahti...@linux.intel.com> wrote: > +require intel-gpu-tools.inc > I'm a big fan of not having inc files unless there's a clear need. What sort of extending are you doing, and could they not be done with bbappends or distro PACKAGECONFIG

Re: [meta-intel] [PATCH] intel-core2-32: Fix-up SERIAL_CONSOLES list

On 30 September 2015 at 02:05, Saul Wold wrote: > -MACHINE_EXTRA_RRECOMMENDS += "linux-firmware" > +MACHINE_EXTRA_RRECOMMENDS += "linux-firmware \ > + gma500-gfx-fix \ > + " > Spurious hunk that shouldn't have been

Re: [meta-intel] Framebuffer support for Atom

On 18 June 2016 at 12:10, Jörg Wille wrote: > Does yocto support any graphics driver for Atom (E3845; HD Graphics - Bay > Trail) to use framebuffer driver with hardware acceleration OpenGL ES using > EGL? Also the standard open driver works, you don't need to use EMGD.

Re: [meta-intel] [PATCH] gstreamer-vaapi: Update 0.6.1-> 0.7.0

On 25 January 2016 at 22:48, Saul Wold wrote: > Please use git mv instead of deleting and creating update recipes, that > way we preserve the history. > Actually git doesn't track moves, only additions and deletions. What we want here is -M being passed to send-email or

Re: [meta-intel] RFC to migrate meta-intel/meta-isg -> meta-intel-isg

On 10 March 2016 at 17:48, Saul Wold wrote: > I would like to hear from the various users of meta-intel and meta- > intel/meta-isg about moving meta-isg into it's own repo that would be > named meta-intel-isg and meta-intel-isg-bsp to distinguish between the > sofware and

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

On 23 May 2016 at 12:41, Jussi Kukkonen 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. Ross --

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

On 26 July 2016 at 21:55, Trevor Woerner 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

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

On 26 July 2016 at 20:55, Trevor Woerner 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. Ross --

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

On 27 July 2016 at 15:44, Scott D Phillips wrote: > If I understand right you have 'opengl' in your DISTRO_FEATURES > and do not have 'gles2'. Is that right? I think in that case > 'opengl' should be set in the PACKAGECONFIG for plugins-bad > so that the gstgl

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

On 27 July 2016 at 23:09, Trevor Woerner 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. Ross -- ___ meta-intel

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

Hi Trevor, On 26 July 2016 at 19:24, Trevor Woerner 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

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

On 28 July 2016 at 16:57, Trevor Woerner wrote: > PACKAGECONFIG_pn-gstreamer1.0-plugins-bad_append = " opengl" > You mean: PACKAGECONFIG_append_pn-gstreamer1.0-plugins-bad (I remember that append is 'a' so at the beginning of the alphabet, so at the beginning of

Re: [meta-intel] [PATCH] thermald: Add thermal daemon utility

On 7 July 2016 at 07:56, Yong Li wrote: > +SYSTEMD_AUTO_ENABLE_${PN} = "enable" > This is the default so you can remove it. > +COMPATIBLE_MACHINE = "intel-corei7-64|intel-core2-32|intel-quark|edison" > Instead of listing machines (which stops working the moment someone

Re: [meta-intel] [PATCH] dpdk: Update SRC_URI checksums

On 5 December 2016 at 23:26, Khem Raj wrote: > -SRC_URI[dpdk.md5sum] = "f51ffc862a4f57b0030ca5d7ff07fef0" > -SRC_URI[dpdk.sha256sum] = "8098b3542b4c78d28bde5f4eba57d4 > ee929fffaaa941b7afd2b881eae0b45c00" > +SRC_URI[dpdk.md5sum] = "24f057ec64c277fbb181ff29569f6844" >

Re: [meta-intel] [OE-core] [PATCH 2/2] gstreamer1.0-vaapi: Import from meta-intel

On 6 December 2016 at 09:57, Ylinen, Mikko wrote: > This suggests the versions should be kept in sync with the gstreamer > versions: > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id= > 3f51f61efe93c104ba7996f54f381c6c1a5e6546 > Khem sent a GStreamer

Re: [meta-intel] [PATCH] conf: set recipe maintainers

On 15 May 2017 at 00:53, Paul Eggleton wrote: > I haven't actually checked, but I think there may be a slight problem with > this in that include/require pick up things using BBPATH, so this file > having > the same name as the one in meta-poky might mask that one

Re: [meta-intel] [PATCH] turbostat: add the recipe of turbostat

Shouldn't the kernel recipe be building this? Ross On 16 May 2018 at 09:05, Hongzhi.Song wrote: > From: Hongzhi Song > > It is an efficient tool to reflect the status of X86 processors. > Turbostat reports processor topology, frequency,

Re: [meta-intel] [PATCH v3] intel-vaapi-driver: upgrade to 2.0.0

Did you also pick the oe-core updates? (not yet in master) Ross On 6 February 2018 at 21:43, Cal Sullivan wrote: > Getting a strange error when building for x32: > > | checking for pkg-config... >

Re: [meta-intel] Unable to build yocto for Intel Mohon Peak CRB

On 1 August 2018 at 15:13, Dhanasekar Jaganathan wrote: > OSError: [Errno 13] Permission denied: > '/home/server/Dhanasekar/Server-BIOS/yocto/poky/build/cache' For whatever reason you don't have permission to write to this folder, but the build can't even start without that. Check your

Re: [meta-intel] Bare minimum configuration

On 18 March 2018 at 22:56, Tim Jones wrote: > Hi Folks, > > I've now gotten a good feel for how Yocto puts things together, but I'm > running into a wall trying to find the package selections. What I'm > shooting for is a meta-intel build with the hardware as provided, but I

Re: [meta-intel] ac_nonexistent.h error in do_configure

On Wed, 3 Oct 2018 at 09:40, Anuj Mittal wrote: > This check is supposed to fail. This is a sanity test, that header isn't > supposed to exist and autoconf expects this compilation error. I don't > think this is the actual point of failure. What would be useful is the output of 'bitbake

Re: [meta-intel] ERROR: - package networkmanager-1.10.6-r0.aarch64 conflicts with connman provided by connman-1.35-r0.aarch64

You'll have to not install either connman or network manager. Ross On Tue, 15 Jan 2019 at 05:18, srinivasan wrote: > > Dear Yocto experts, > > I am seeing the below error when I am trying to integrate the > "fsl-image-validation-imx.bb" into my custom yocto build and trigger > the build using

Re: [meta-intel] D2800 Support w/NM10 chipset (Cedar Trail)

Unfortunately the PowerVR drivers for Cedar Trail are binary-only, so you'll be stuck with compatible kernels. If I were you I'd take the drivers and kernel from Danny. Ross On Mon, 21 Jan 2019 at 10:52, Enrico Pelò wrote: > > Hello to all, > > I need to build an image for support that old

Re: [meta-intel] D2800 Support w/NM10 chipset (Cedar Trail)

; advice? > > Best regards > Enrico > > On 21/01/2019, 12:09, "Burton, Ross" wrote: > > Unfortunately the PowerVR drivers for Cedar Trail are binary-only, so > you'll be stuck with compatible kernels. If I were you I'd take the > drivers and kern

Re: [meta-intel] Atom E3826 storage that survives over reboot

EFI variables should work? Ross On Tue, 22 Jan 2019 at 08:20, Teemu K wrote: > > Hi, > > Not exactly Yocto related, but was wondering if anyone have (new) ideas here. > > I have HW that has Congate TCA-3 board with Atom E3826 processor > running Linux and there is need to relay information from

Re: [meta-intel] [PATCH] ledmon: control hard disk led for RAID arrays

On Mon, 25 Mar 2019 at 05:24, Liwei Song wrote: > >> +EXTRA_OEMAKE = "CC='${CC}' LDFLAGS='${LDFLAGS}'" > > > > Are these needed, as they're exported. If we need to pass LDFLAGS > > like this, why not CFLAGS? > > This is used to fix an QA WARNING: > > WARNING: ledmon-0.90-git do_package_qa: QA

Re: [meta-intel] [PATCH 3/4] intel-graphics-compiler: add

On Fri, 5 Apr 2019 at 14:00, Anuj Mittal wrote: > +inherit cmake pythonnative Assuming it's using the standard Python checkers in cmake then this will probably work: EXTRA_OECMAKE = "-DPYTHON_EXECUTABLE=${HOSTTOOLS_DIR}/python3" (or maybe python2 if it needs Py2 and can't handle py3) Ross --

  1   2   >