[PATCH 42/56] bluetooth: Get BlueZ 5 device object

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux