On Wed, 2013-03-27 at 12:54 -0300, Jo?o Paulo Rechi Vita wrote:
> 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).
I'll comment on module-bluetooth-ofono specifically. I'd prefer not to
have that, at least if it's something that's expected to be put in
default.pa (as opposed to auto-loading by module-bluetooth-discover).
module-bluetooth-discover should auto-detect the backend(s) that the
system uses at runtime. If someone is bothered by the performance
penalty of doing auto-detection, there can be configuration options
(and/or perhaps compile-time options) to select the backends.
I don't have so much opinions about how the source files are divided.
I'll say just that ideally, module-bluetooth-device would be completely
backend-agnostic, as Jo?o suggested.
--
Tanu
