[pulseaudio-discuss] [RFC 04/24] bluetooth: Track org.ofono service

[João Paulo Rechi Vita]

Hello Mikel,

On Wed, Mar 27, 2013 at 5:15 AM, Mikel Astiz <mikel.astiz.oss at gmail.com> wrote:
> Hi João Paulo,
>
> On Wed, Mar 27, 2013 at 6:16 AM,  <jprvita at gmail.com> wrote:
>> From: João Paulo Rechi Vita <jprvita at openbossa.org>
>>
>> ---
>>  src/modules/bluetooth/bluetooth-util.c | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/src/modules/bluetooth/bluetooth-util.c b/src/modules/bluetooth/bluetooth-util.c
>> index 7ae12fc..fb202c1 100644
>> --- a/src/modules/bluetooth/bluetooth-util.c
>> +++ b/src/modules/bluetooth/bluetooth-util.c
>> @@ -1325,7 +1325,18 @@ static DBusHandlerResult filter_cb(DBusConnection *bus, DBusMessage *m, void *us
>>              }
>>          }
>>
>> +        if (pa_streq(name, "org.ofono")) {
>> +            if (old_owner && *old_owner) {
>> +                pa_log_debug("oFono disappeared");
>> +            }
>> +
>> +            if (new_owner && *new_owner) {
>> +                pa_log_debug("oFono appeared");
>> +            }
>> +        }
>> +
>>          return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
>> +
>>      } else if (dbus_message_is_signal(m, "org.bluez.MediaTransport", "PropertyChanged")) {
>>          pa_bluetooth_transport *t;
>>          DBusMessageIter arg_i;
>> @@ -2169,6 +2180,8 @@ pa_bluetooth_discovery* pa_bluetooth_discovery_get(pa_core *c) {
>>                  ",arg0='org.bluez.Device1'",
>>                  "type='signal',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged'"
>>                  ",arg0='org.bluez.MediaTransport1'",
>> +                "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',"
>> +                "arg0='org.ofono'",
>>                  NULL) < 0) {
>>          pa_log("Failed to add D-Bus matches: %s", err.message);
>>          goto fail;
>> @@ -2244,6 +2257,8 @@ void pa_bluetooth_discovery_unref(pa_bluetooth_discovery *y) {
>>              "type='signal',sender='org.bluez',interface='org.bluez.MediaTransport',member='PropertyChanged'",
>>              "type='signal',sender='org.bluez',interface='org.freedesktop.DBus.ObjectManager',member='InterfacesAdded'",
>>              "type='signal',sender='org.bluez',interface='org.freedesktop.DBus.ObjectManager',member='InterfacesRemoved'",
>> +            "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',"
>> +            "arg0='org.ofono'",
>>              NULL);
>>
>>          if (y->filter_added)
>> --
>> 1.7.11.7
>>
>
> As discussed in IRC, I' suggest we avoid oFono dependencies from
> bluetooth-util, based on the following reasons:
> 1. Code will be more readable if oFono's D-Bus details are wrapped
> inside ofono-util or similar, outside bluetooth-util.
> 2. Version tracking will be easier, since oFono and BlueZ have
> independent release cycles.
> 3. We shouldn't limit the PA Bluetooth module to oFono, no matter how
> much we like the project.
>
> I would be fine relaxing point 3 based on the fact that oFono is the
> first telephony stack integrating with PulseAudio, but only if we
> agree that adding a generic infrastructure is overkill, which I'm not
> convinced about.
>
> The way I see an ideal scenario is that we wrap all oFono-specific
> code into ofono-util and module-bluetooth-ofono. The tricky part
> consists of merging everything into one single card per Bluetooth
> device, while avoiding a direct dependency between
> module-bluetooth-device and the oFono code.
>

For the IRC discussion we had the other day, I had understood we had
came to a decision to make things work first and later re-factor the
code to make more modular. Did I get it wrong? I agree with the 3
points you've raised, and I also would like to have a way enable
support for Bluetooth audio profile's roles individually (A2DP sink,
A2DP source, HFP Audio Gateway, HFP Handsfree unit, HSP Audio Gateway,
HSP Headset unit), since they have different sets of dependency, with
some intersections.

Still, all of this is Bluetooth-related code, and since we want to be
able to switch profiles on the same card, I think it would be very
unpractical not to have a common point, that in my opinion would be
module-bluetooth-device. It would indeed be nice to have some callback
scheme or an API that we could abstract transport backends (BlueZ,
oFono and what may come) out of module-bluetooth-device, but I think
we will have a better idea to design this after making the oFono
support work and getting rid of some legacy code (pré media API
stuff).

--
João Paulo Rechi Vita
http://about.me/jprvita