On 02/14/2013 08:50 AM, Mikel Astiz wrote: > 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". After some discussion on IRC I can't say that I fully understand the entire object model of BlueZ and how that correlates to different PA objects; but adding a profile availability doesn't seem to cause any significant problems in itself, so if it solves your problem, go ahead! :-) -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
