Re: viability of bluez5 in next OE development cycle?

["Peter A. Bigot" <pab@pabigot.com>]

On 10/20/2014 09:58 AM, Burton, Ross wrote:
> On 20 October 2014 15:50, Peter A. Bigot <pab@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