[OE-core] viability of bluez5 in next OE development cycle?
Peter A. Bigot
pab at pabigot.com
Mon Oct 20 17:01:41 UTC 2014
On 10/20/2014 09:58 AM, Burton, Ross wrote:
> On 20 October 2014 15:50, Peter A. Bigot <pab at pabigot.com> wrote:
>> There's this bugzilla entry:
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5031
>>
>> I see a NAKd patch set from about 26 Mar 2014 which tried to add
>> virtual/bluez. The outcome was that a rework would be done and tested and
>> resubmitted latter. In the related discussion there was some concern that
>> dependent packages were still not ready to move even though the last bluez4
>> release was in June 2012.
>>
>> With a little local hacking I can get bluez5 working well enough for my BTLE
>> needs on beaglebone (mostly s/bluez4/bluez5/g and a PROVIDER for
>> bluez-hcidump). Does anybody have plans to work this during the early 1.8
>> development cycle? It looks pretty straightforward, but Idon't use BT in
>> enough variants and packages to be able to test the full set of required
>> patches.
> At the time the blocker was that some use cases (bluetooth headset, I
> think) was non-functional with BlueZ 5, because functionality needed
> to be added to PulseAudio and oFono. Yes, this needs to be revisited
> in 1.8.
In case it's related: the bluez plugin in gst-plugins-bad_1.4.1 does not
support bluez5, and gst-plugin-bluetooth was removed from bluez before
bluez5 was released. It's not clear to me how to disable the
gst-plugin-bluetooth recipe when bluez5 is selected other than a local
PNBLACKLIST.
Excepting that issue, the changes for virtual/bluez support are pretty
straightforward, but since I have no ability to test bluetooth headsets
I'll continue to leave virtual/bluez alone.
I have a couple small bluez5 patches that are not coupled to
virtual/bluez which I'll submit once dizzy's out and the backlog for
master starts draining.
Peter
More information about the Openembedded-core
mailing list