From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 13C6EE002A6 for ; Wed, 18 Jul 2012 08:55:36 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 18 Jul 2012 08:55:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="169909322" Received: from unknown (HELO [10.255.12.204]) ([10.255.12.204]) by azsmga001.ch.intel.com with ESMTP; 18 Jul 2012 08:55:35 -0700 Message-ID: <5006DC77.8080600@linux.intel.com> Date: Wed, 18 Jul 2012 08:55:35 -0700 From: Joshua Lock User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: James Abernathy References: <5005BBEE.7000404@gmail.com> <1342563542.25833.10.camel@localhost.localdomain> In-Reply-To: Cc: yocto@yoctoproject.org Subject: Re: meta-baryon flexibility X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:55:36 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 18/07/12 04:40, James Abernathy wrote: > On Tue, Jul 17, 2012 at 6:19 PM, Joshua Lock > wrote: > > > On Tue, 2012-07-17 at 15:24 -0400, Jim Abernathy wrote: > > In an effort to explore how independent a layer could be to the > > underlying hardware, I took the meta-baryon NAS layer and got it > built > > from master using the n450 BSP. With that working I decided to > replace > > the n450 with sugarbay. While the n450 can support X11 and sato, > it was > > not generated by design in the baryon build. > > > > However, when I changed to sugarbay, the build stops because X11 is > > needed. To get around this I had to comment out some things in the > > conf/machine/sugarbay.conf file in the BSP. > > > > > > #XSERVER ?= "${XSERVER_IA32_BASE} \ > > # ${XSERVER_IA32_EXT} \ > > # ${XSERVER_IA32_I965} \ > > # " > > > > #VA_FEATURES ?= "gst-va-intel va-intel" > > > > #MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}" > > > > Why didn't I have to do this in the n450?? > > The key piece is the MACHINE_EXTRA_RRECOMMENDS, which is telling Poky to > recommend the gst-va-intel and va-intel recipes when building this > machine. > > RRECOMMENDS are automatically installed as a dependency (in this case, > of task-machine-base, see task-base.bbclass) but can be removed without > causing the package which pulled it in to be removed (see the Poky > reference manual glossary on *_RRECOMMENDS). > > http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html > > I'd suggest the RRECOMMENDS actually be added at a more granular level > than the machine. Perhaps you could file a bug against the BSP? > > So if I understand this, it would be better for one of the image.bb > files that focused on media to include this particular > RRECOMMENDS statement. That way others not interested in media and > graphic could still use the BSP unchanged. Arguably, yes. But (devil's advocate) what about image recipes which aren't part of the core? i.e. if you've been using a different board to develop a custom image and then switch to using the sugarbay wouldn't you want the accelerated video to "just work"? I'd suggest a possible solution would be to define an opt-in IMAGE_FEATURES[1][2] for multimedia which the sugarbay BSP can add these recipes to. Joshua 1. http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#var-IMAGE_FEATURES 2. http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-image -- Joshua Lock Yocto Project Intel Open Source Technology Centre