Hi Tanu, >> module-bluetooth-discover already knows what profiles are connected >> and can hint module-bluetooth-device into what profile to use >> thus saving some ipc at loading. > > If module-bluetooth-discovery already knows that, I don't see why there > needs to be any extra ipc. The device information could be shared > between module-bluetooth-discovery and module-bluetooth-device.[1] At first, i thought some DBUS would be required at loading of module-bluetooth-device but in fact this is not needed : bluetooth-util.c contains some code that shares this information. See pa_bluetooth_discovery_get(u->core) > What do you mean by "loading/unloading and updating profiles"? The > profile list is static (at least currently), so your wording sounds > strange. Do you mean the task of deciding which profile should be active > at any given time? My english is what it is :) I meant loading and unloading module-bluetooth-device, and updating the active profile for each card upon particular events. >> module-bluetooth-device itself should only apply what is said to it. >> module-bluetooth-discover then could be able to manage profiles on >> several devices at a time for example if two headset are paired, switch >> the first to off and the second one to HSP for example. > > I think it's probably the right choice to make module-bluetooth-device > stupid and only act when told so. In absence of external control, > module-bluetooth-device should default to the "off" profile. > I doesn't sound like a good idea to make module-bluetooth-discover any > smarter either. It should just load module-bluetooth-device when any > profile is at least in the "connected" state, without specifying any > profile. That's because choosing the profiles is a territory for policy > modules. If there's a central policy daemon, it will probably want to > have full control over the profiles, so module-bluetooth-device > shouldn't pretend to know what's best for the user. > > Desktops probably won't have any centralized policy daemon, at least in > the near future, so some sane default policy for handling the bluetooth > profiles is needed. Since module-device-restore doesn't seem to > implement very useful policy in case of bluetooth, I think there should > be a separate policy module just for handling the bluetooth profiles. A few weeks ago I've read about a policy module on that list. So far I've seen any updates. I have nothing against handling the profile switch in a separate module as long as it is done. This offers an additional advantage : that could also be used to automate loading of module-loopback for HFP HF role and A2DP sink role. > [1] I've actually already started to implement a shared "daemon proxy" It is likely that a big part of what you need is already available in bluetooth-util.c. You just need to add a field to struct pa_bluetooth_discovery with the adapters, and a hook to call when an adapter is added (see found_adapter) and you're done. Regards, Fr?d?ric
