Hi João Paulo,

On Tue, Apr 30, 2013 at 9:13 PM, João Paulo Rechi Vita
<[email protected]> wrote:
> On Tue, Apr 30, 2013 at 7:20 AM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi Mikel,
>>
>> On Mon, Apr 29, 2013 at 7:27 PM, Mikel Astiz <[email protected]> 
>> wrote:
>>> From: Mikel Astiz <[email protected]>
>>>
>>> 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.

Cheers,
Mikel
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Reply via email to