On Tue, 2011-12-06 at 19:20 +0100, Dalleau, Frederic wrote: > Hi Tanu, > > > So, does this sound like correct behavior: > > > > module-bluetooth-discover loads module-bluetooth-device whenever > > anything is CONNECTED. module-bluetooth-discover never sets any > > particular profile explicitly. > > 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] That said, I don't think it's necessarily a very good idea to put the profile selection logic into module-bluetooth-device after all. Neither am I convinced that module-bluetooth-discover is the right place. > > If the "profile" module argument is not set, module-bluetooth-device > > activates a profile that is PLAYING at the time when the module is > > loaded. > see above > > However I agree that splitting profile decision over two modules is > not easy to deal with. I'd suggest that module-bluetooth-discover be > made responsible for loading/unloading and updating profiles for the > various instances of module-bluetooth-device. 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? > 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. [1] I've actually already started to implement a shared "daemon proxy" that provides a simple interface for any module for interacting with bluetoothd. Basically the daemon proxy stores the bluetoothd state in a local cache, which can be immediately accessed by modules, without having to touch D-Bus at all. I don't have concrete plans to adapt the existing bluetooth modules to the daemon proxy; the proxy will initially only be used by module-wl1273-support. If others see the proxy concept useful, it should be easy to extend the proxy to cover more stuff. module-wl1273-support only needs to access the list of adapters and the org.bluez.FMRadio interface, so the initial functionality will be rather limited. -- Tanu
