On Mon, Jul 29, 2013 at 8:49 AM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> On Thu, 2013-07-25 at 21:11 -0300, Jo?o Paulo Rechi Vita wrote:
>> On Mon, Jul 22, 2013 at 11:36 AM, Tanu Kaskinen
>> <tanu.kaskinen at linux.intel.com> wrote:
>> > On Fri, 2013-07-12 at 15:06 -0300, jprvita at gmail.com wrote:
>> >> @@ -50,10 +99,15 @@ int pa__init(pa_module* m) {
>> >> m->userdata = u = pa_xnew0(struct userdata, 1);
>> >> u->module = m;
>> >> u->core = m->core;
>> >> + u->device_modules = pa_hashmap_new(pa_idxset_string_hash_func, pa_idxset_string_compare_func);
>> >>
>> >> if (!(u->discovery = pa_bluetooth_discovery_get(u->core)))
>> >> goto fail;
>> >>
>> >> + u->device_connection_changed_slot =
>> >> + pa_hook_connect(pa_bluetooth_discovery_hook(u->discovery, PA_BLUETOOTH_HOOK_DEVICE_CONNECTION_CHANGED),
>> >> + PA_HOOK_NORMAL, (pa_hook_cb_t) device_connection_changed_cb, u);
>> >
>> > If the discovery object already existed, and it contains devices,
>> > module-bluez5-discover should load module-bluez5-device modules for
>> > those devices. It's possible that the device modules are already loaded,
>> > though, so there needs to be some way of checking whether a device
>> > module actually needs to be loaded. pa_bluetooth_discovery could have a
>> > registry for loaded modules, perhaps. Or pa_bluetooth_device could have
>> > a module_loaded boolean field.
>> >
>>
>> The discovery object will only exist if a module-bluez5-device has
>> been loaded before module-bluez5-discover (I'm not considering the
>> possibility of clash between bluez4/bluez5 discovery objects, since
>> this is a different problem). And as you mentioned in the comments of
>> patch 41/56, manually loading the device module doesn't work anymore
>> (and I really don't remember if it ever worked). So perhaps we should
>> explicitly not support manually loading it, is there a way to enforce
>> this via PulseAudio's module-loading system?
>
> No, I don't think there's any way to forbid users from loading specific
> modules. If you don't want to drop module-bluez5-device altogether (and
> instead implement it as a part of the bluez5-util library), there could
> be a "loaded_by_discovery" module argument which would have to be passed
> to module-bluez5-device, otherwise the module would fail to load (with
> an informative error message).
>
When I was going to implement this approach I had a different idea: we
can simply rely on the presence of bluez5-discovery in the shared
hashmap of pulseaudio's core to tell if module-bluez5-discovery has
been loaded or not. In other words, we fail loading
module-bluez5-device if bluez5-discovery is not found.
--
Jo?o Paulo Rechi Vita
http://about.me/jprvita
