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?
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?
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
