Hi David, On Thu, Feb 14, 2013 at 8:05 AM, David Henningsson <david.henningsson at canonical.com> wrote: > On 02/13/2013 02:48 PM, Mikel Astiz wrote: >> >> From: Mikel Astiz <mikel.astiz at bmw-carit.de> >> >> It has been recently discussed how ports should be used in the Bluetooth >> card module, whether they should be merged or not, and how the >> bluetooth-related information is exposed to both external components (i.e. >> UI) and internal policy modules. >> >> In a nutshell, the problem is as follows: the internal policies are >> interested in profile-specific information (HSP/HFP vs A2DP) while the ports >> should ideally be associated to physical entities (and the Bluetooth profile >> should make no difference). >> >> A natural way to solve this problem is by adding a new flag to the card >> profiles, representing the availability of each profile. This is similar to >> port-availability but with different semantics, representing the state of >> each invidivual Bluetooth profile. >> >> This patchset extends the core with such a flag, which sounds useful even >> beyond the scope of this specific problem (a UI could use this information >> to gray out profiles). >> >> If the core adopted such a flag, the merge of the Bluetooth ports would be >> straightforward, as implemented in patch v0 5/5. > > > Just trying to understand it: > > if (state == PA_BLUETOOTH_TRANSPORT_STATE_DISCONNECTED) > return PA_PROFILE_AVAILABLE_NO; > else if (state >= PA_BLUETOOTH_TRANSPORT_STATE_PLAYING) > return PA_PROFILE_AVAILABLE_YES; > else > return PA_PROFILE_AVAILABLE_UNKNOWN; > > If the state is "disconnected", why is there a card at all at that point? A card can have multiple transports, one per Bluetooth profile and role. These map to card profiles in module-bluetooth-device, with the exception of profile "off". Roughly speaking, the modules gets loaded when at least one profile gets connected, but there is no guarantee about the state of the rest. That's why PA_PROFILE_AVAILABLE_NO provides valuable information, exactly as PA_PORT_AVAILABLE_NO did before (assuming the ports are not merged). > > And if there isn't, then it's just showing whether it's playing back or not, > which can be retrieved by just checking the actual sink/source state? The sink/sources do not exist unless the profile is active. As an example, if the card is set to profile "a2dp", the only place where we expose whether HSP/HFP is actually streaming audio is: (a) before this patchset -> in the availability of "hsp-input" (which we were not able to merge with port "a2dp-input"), and (b) after this patchset -> in the availability of profile "hsp". Cheers, Mikel
