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. -- João Paulo Rechi Vita http://about.me/jprvita _______________________________________________ pulseaudio-discuss mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
