<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 26, 2014 at 7:51 AM, Martin Jansa <span dir="ltr"><<a href="mailto:martin.jansa@gmail.com" target="_blank">martin.jansa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Wed, Mar 26, 2014 at 09:27:54AM -0500, Lauren Post wrote:<br>
> This group of patches support the change of hardcoded bluez4 to<br>
> virtual/bluez so that the upgrade to bluez5 is easier.<br>
><br>
> This group of patches must be applied together. Bluez4 is still<br>
> default provider but it will be easier to override and provide bluez5<br>
> support in future.<br>
><br>
> Note there is one related patch for openobex in meta-oe.<br>
<br>
</div>virtual/* still doesn't work correctly in runtime variables, use<br>
VIRTUAL-RUNTIME_bluez variable.<br>
<br>
Last time I've asked for bluez4->bluez5 upgrade path fix on target I was<br>
told that it's not supported and bluez5 isn't drop-in replacement for<br>
bluez4 (yet), did that change already?</blockquote></div><br>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.<br>
-- <br>Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics
</div></div>