On Wed, Mar 26, 2014 at 7:51 AM, Martin Jansa <martin.ja...@gmail.com>wrote:
> On Wed, Mar 26, 2014 at 09:27:54AM -0500, Lauren Post wrote: > > This group of patches support the change of hardcoded bluez4 to > > virtual/bluez so that the upgrade to bluez5 is easier. > > > > This group of patches must be applied together. Bluez4 is still > > default provider but it will be easier to override and provide bluez5 > > support in future. > > > > Note there is one related patch for openobex in meta-oe. > > virtual/* still doesn't work correctly in runtime variables, use > VIRTUAL-RUNTIME_bluez variable. > > Last time I've asked for bluez4->bluez5 upgrade path fix on target I was > told that it's not supported and bluez5 isn't drop-in replacement for > bluez4 (yet), did that change already? Afaik libbluetooth is API compatible, but the dbus api isn't. I haven't done much runtime testing, though. So I don't think virtual/bluez is an appropriate name given they aren't 100% compatible bluetooth implmentations across the board. In meta-mentor, we moved to a combination of two virtual-runtimes (for flexibility, to facilitate replacement not just with bluez5, but also potentially with a third party implementation, two virtual-runtimes, one for hardware support, one for the userland bluetooth stack, (and potentially others in the future)) with a virtual/libbluetooth build virtual, and then you need to ensure obexd/hcidump are left out of the build, since they were merged into bluez5. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core