On Mon, Jul 22, 2013 at 11:56 AM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> On Fri, 2013-07-12 at 15:06 -0300, jprvita at gmail.com wrote:
>> From: Jo?o Paulo Rechi Vita <jprvita at openbossa.org>
>>
>> Get the remote device information stored in pa_bluetooth_discovery. This
>> also creates the mandatory parameter 'path' for module-bluez5-device,
>> which is used to inform the object path of the remote device in BlueZ on
>> the module load.
>> ---
>> src/modules/bluetooth/module-bluez5-device.c | 65 ++++++++++++++++++++++++++++
>> 1 file changed, 65 insertions(+)
>>
>> diff --git a/src/modules/bluetooth/module-bluez5-device.c b/src/modules/bluetooth/module-bluez5-device.c
>> index 890f7e4..c1c3477 100644
>> --- a/src/modules/bluetooth/module-bluez5-device.c
>> +++ b/src/modules/bluetooth/module-bluez5-device.c
>> @@ -25,6 +25,7 @@
>> #endif
>>
>> #include <pulsecore/module.h>
>> +#include <pulsecore/modargs.h>
>>
>> #include "bluez5-util.h"
>>
>> @@ -34,10 +35,74 @@ PA_MODULE_AUTHOR("Jo?o Paulo Rechi Vita");
>> PA_MODULE_DESCRIPTION("BlueZ 5 Bluetooth audio sink and source");
>> PA_MODULE_VERSION(PACKAGE_VERSION);
>> PA_MODULE_LOAD_ONCE(false);
>> +PA_MODULE_USAGE("path=<device object path>");
>> +
>> +static const char* const valid_modargs[] = {
>> + "path",
>> + NULL
>> +};
>> +
>> +struct userdata {
>> + pa_module *module;
>> + pa_core *core;
>> + pa_modargs *modargs;
>> +
>> + pa_bluetooth_discovery *discovery;
>> + pa_bluetooth_device *device;
>> +};
>>
>> int pa__init(pa_module* m) {
>> + struct userdata *u;
>> + pa_modargs *ma;
>> + const char *path;
>> +
>> + pa_assert(m);
>> +
>> + if (!(ma = pa_modargs_new(m->argument, valid_modargs))) {
>> + pa_log_error("Failed to parse module arguments");
>> + goto fail;
>> + }
>> +
>> + if (!(path = pa_modargs_get_value(ma, "path", NULL))) {
>> + pa_log_error("Failed to get device path from module arguments");
>> + goto fail;
>> + }
>> +
>> + m->userdata = u = pa_xnew0(struct userdata, 1);
>> + u->module = m;
>> + u->core = m->core;
>> + u->modargs = ma;
>> +
>> + if (!(u->discovery = pa_bluetooth_discovery_get(m->core)))
>> + goto fail;
>> +
>> + if (!(u->device = pa_bluetooth_discovery_get_device_by_path(u->discovery, path))) {
>> + pa_log_error("%s is unknown", path);
>> + goto fail;
>> + }
>
> If the discovery object was just created, the devices haven't been
> enumerated yet, so module-bluez5-device doesn't work without loading
> module-bluez5-discover first. This is nothing new - it looks like the
> old code did the same thing. I wonder why we even bother to have a
> separate device module, if it can't be used without the discovery
> module.
>
Bringing the discussion to where it belongs, as I said on 40/56,
manually loading the device module doesn't work anymore. I don't know
when it stopped working, but I was never something we cared much
about, so perhaps we should explicitly not support manually loading
it. Is there a way to enforce this via PulseAudio's module-loading
system?
IIRC was Lennart's suggestion to have this architecture, back in 2008,
which is similar to how module-detect/module-udev-detect loads audio
drivers. Even not supporting loading module-bluez5-device without
loading module-bluez5-discover, it seems to me that there is a better
separation to have one module for each I/O thread and Bluetooth card
than having all cards/threads being handled by one module.
--
Jo?o Paulo Rechi Vita
http://about.me/jprvita
