Hi João Paulo, On Thu, May 2, 2013 at 10:05 PM, João Paulo Rechi Vita <[email protected]> wrote: > On Thu, May 2, 2013 at 4:17 AM, Mikel Astiz <[email protected]> wrote: >> 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. >> > > 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 _______________________________________________ pulseaudio-discuss mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
