[pulseaudio-discuss] [RFC] bluetooth: Add support for org.bluez.Adapter and org.bluez.FMRadio.

[Tanu Kaskinen]

On Fri, 2011-12-09 at 13:37 +0200, Luiz Augusto von Dentz wrote:
> Hi Tanu,
> 
> On Thu, Dec 8, 2011 at 10:53 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > From: Tanu Kaskinen <tanu.kaskinen at digia.com>
> >
> > ---
> > Here is some unfinished work related to the upcoming module
> > called module-wl1273-support. The module will want to use
> > the org.bluez.FMRadio interface and get notifications when
> > the WL1273 chip appears and disappears in bluetoothd. The
> > module will know the "hciX" identifier of the chip, thus the
> > fmradios_by_adapter_name hashmap is very convenient for
> > looking up the right proxy object.
> >
> > I'd like to develop bluetooth-util to the direction that
> >  * it will hide D-Bus entirely from the modules (except for
> >   the async nature of function calls, which can't be
> >   hidden)
> >  * objects (like Transports and Devices) are directly
> >   available in the pa_bluetooth_core struct instead of
> >   through the IMO clumsy functions like
> >   pa_bluetooth_discover_get_transport()
> >  * hooks have very narrow and well-defined semantics,
> >   instead of the vague "discovery hook" that seems to be
> >   called in strange situations (like as part of error
> >   handling when receiving properties...)
> >  * objects have clear separation between "public" and
> >   "private" variables
> >  * things are documented :)
> >
> > Please comment if that plan doesn't please you...
> 
> Im fine with the changes except with this thing with
> org.bluez.FMRadio, IMO that should belong to the module that requires
> it

It's a valid argument that "special" stuff like the FMRadio interface
adds clutter in the generic bluetooth-util.h API. But if it's
implemented separately, either it will reimplement a lot of stuff
already done by bluetooth-util, or alternatively bluetooth-util.h will
need to provide an API for extending the functionality, and that would
add another kind of clutter. I believe the extension API would be worse
than having FMRadio directly in bluetooth-util.

Another argument is that having FMRadio in bluetooth-util causes
overhead in systems where the WL1273 chip isn't used. There is some
additional memory required, which I think is negligible, but there's
also useless D-Bus communication involved, which I think is a
significant drawback.

I propose that pa_bluetooth_discovery_get() shall take "coverage flags"
as an argument. The flags tell bluetooth-util which parts of the Bluez
API the caller will need, and if some parts aren't needed by anyone,
bluetooth-util can ignore those parts. In practice I think the coverage
flags could be interfaces. For example, module-wl1273-support could say
that "I need to access the org.bluez.FMRadio interface (which also
implies org.bluez.Adapter)". Bluetooth-util would then enumerate all
adapters and fmradios, get their properties and subscribe to their
signals. A more fine-grained approach would be to list each property and
signal that the module is interested in, but I think that would make
things more complicated and there probably wouldn't be much overhead
saved.

> beside I don't see us accepting this interface as part of the core
> daemon, so this probably need to be inside the maemo6 plugin which
> should only be loaded for its platform.

Yes, that makes sense (except that the FMRadio interface shouldn't be
tied to maemo6, since the hardware in question can be used with other
operating systems too). I don't think this has to be visible in
bluetooth-util.h, however.

> This way we also put pressure
> in having the hardware/driver exposing everything properly, otherwise
> it has to do its dirty work themselves.

Sorry, I didn't understand what you tried to say here.

-- 
Tanu