[pulseaudio-discuss] [RFC next v4 00/16] bluetooth: BlueZ 5 development patches

[Mikel Astiz]

Hi João Paulo,

On Thu, May 2, 2013 at 10:05 PM, João Paulo Rechi Vita
<jprvita at gmail.com> wrote:
> On Thu, May 2, 2013 at 4:17 AM, Mikel Astiz <mikel.astiz.oss at gmail.com> wrote:
>> Hi João Paulo,
>>
>> On Tue, Apr 30, 2013 at 9:13 PM, João Paulo Rechi Vita
>> <jprvita at gmail.com> wrote:
>>> On Tue, Apr 30, 2013 at 7:20 AM, Luiz Augusto von Dentz
>>> <luiz.dentz at gmail.com> wrote:
>>>> Hi Mikel,
>>>>
>>>> On Mon, Apr 29, 2013 at 7:27 PM, Mikel Astiz <mikel.astiz.oss at gmail.com> wrote:
>>>>> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
>>>>>
>>>>> Resending v3 with a small change in patch 3/16, where the "Name" property of org.bluez.Device1 is now considered as optional.
>>>>>
>>>>> This version is intended for the next branch since it depends on module-bluetooth-device not making use of device->name, which could now be potentially NULL.
>>>>>
>>>>> Note that the last 5 patches are somewhat controversial (see below) and it might therefore be desireable to keep them on hold.
>>>>>
>>>>> From previous cover-letter:
>>>>>
>>>>> The discussion raised by João Paulo is whether the HSP/HFP endpoint should be registered or not, and the few associated features implemented. Luiz suggested it'd be good in any case to have the patches for reference, so I'm sending the full patchset (including the HSP/HFP part) reworked in a way that such code is grouped in the end (starting with v3 12/16).
>>>>>
>>>>> Mikel Astiz (15):
>>>>>   bluetooth: Detect BlueZ 5
>>>>>   bluetooth: Parse the tree returned by ObjectManager
>>>>>   bluetooth: Support ObjectManager interface add/remove
>>>>>   bluetooth: Support Properties.PropertiesChanged signal
>>>>>   bluetooth: BlueZ 5 interface rename to org.bluez.MediaEndpoint1
>>>>>   bluetooth: BlueZ 5 interface rename to org.bluez.Media1
>>>>>   bluetooth: BlueZ 5 interface rename to org.bluez.MediaTransport1
>>>>>   bluetooth: Parse media transport's properties
>>>>>   bluetooth: Support media transport's State property
>>>>>   bluetooth: Update to new BlueZ 5 transport acquire/release API
>>>>>   bluetooth: Support transport auto-release
>>>>>   bluetooth: Register HSP/HFP endpoints in BlueZ 5 Media API
>>>>>   bluetooth: Handle transports configured before UUID received
>>>>>   bluetooth: Update to new property setter API in BlueZ 5
>>>>>   bluetooth: Update to volume control in BlueZ 5
>>>>>
>>>>> Vinicius Costa Gomes (1):
>>>>>   bluetooth: Add HFP 1.6 codec ID
>>>>>
>>>>>  src/modules/bluetooth/bluetooth-util.c          | 568 ++++++++++++++++++++++--
>>>>>  src/modules/bluetooth/module-bluetooth-device.c |   8 +-
>>>>>  2 files changed, 521 insertions(+), 55 deletions(-)
>>>>>
>>>>> --
>>>>> 1.8.1.4
>>>>
>>>> Ack from my side.
>>>>
>>>>
>>>
>>> As I mentioned before, if we want to split transport backends BlueZ 4
>>> and BlueZ 5 should be implemented as backends as well. I don't see the
>>> point of having only oFono as a separate backend.
>>
>> The point is just practical: this patchset has been around for quite a
>> while a several people have reviewed and tested it.
>>
>> I agree that the backend-specific code of both BlueZ 4 and 5 could be
>> moved somewhere outside bluetooth-util, but I don't find it critical.
>> It's definitely not comparable to the need to separate the oFono
>> backend. In a similar way, we shouldn't necessarily separate the oFono
>> backend from ofono-util, which could potentially support other
>> functionality beyond the backend itself (e.g. call-state tracking).
>>
>> So being pragmatic and in order to avoid more delays, I insist on
>> merging this patchset first and then discussing further steps.
>>
>
> If so I think we should treat the oFono patches in the same way, merge
> it first and separate it later, which was what I preferred in the
> first place.

I disagree with this as pointed out several times. bluetooth-util
already has a dependecy to BlueZ as opposed to oFono which makes a big
difference. I see no strong argument to merge oFono code before having
a nice split of backends.

Besides, I already proposed a first approach to add the backend
infrastructure so I believe we should be able to have progress quickly
once the BlueZ 5 patchset gets merged.

Cheers,
Mikel