[PATCH 40/56] bluetooth: Track devices in module-bluez5-discover

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

 



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).

-- 
Tanu



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

  Powered by Linux