viability of bluez5 in next OE development cycle?
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.
Peter
Quoted 9 lines · Peter A. Bigot
There's this bugzilla entry:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5031I 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.
Quoted 6 lines
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.
Ross
Quoted 16 lines · Ross
Quoted 9 lines · Peter A. Bigot
There's this bugzilla entry:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5031I 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.
Quoted 6 lines
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.
Quoted 4 lines
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