bluez5: probe adapter msbc capability via hci commands

Using a probe connection to determine adapter msbc capability causes
problems on some adapters (ff8c3d2, 84bc0490a5, 717004334b,
pipewire#2030) and seems to be a bad idea.

Go back to probing for transparent msbc transport capability via HCI
commands. bluetooth/hci.h may be deprecated later, but for now it's
better to go back to using it.  (In practice, adapters not supporting
esco appear to be fairly rare; kernel commit in 2013 refers to "older
devices", so if we can't use HCI, assume the adapter supports the
necessary modes.)
This commit is contained in:
Pauli Virtanen 2022-01-20 22:39:51 +02:00
parent 483831e514
commit 1da23145df
4 changed files with 120 additions and 42 deletions

View file

@ -332,11 +332,13 @@ struct spa_bt_adapter {
uint32_t bluetooth_class;
uint32_t profiles;
int powered;
unsigned int has_msbc:1;
unsigned int msbc_probed:1;
unsigned int endpoints_registered:1;
unsigned int application_registered:1;
unsigned int player_registered:1;
unsigned int has_battery_provider;
unsigned int battery_provider_unavailable;
unsigned int has_battery_provider:1;
unsigned int battery_provider_unavailable:1;
};
enum spa_bt_form_factor {
@ -696,6 +698,8 @@ int spa_bt_quirks_get_features(const struct spa_bt_quirks *quirks,
uint32_t *features);
void spa_bt_quirks_destroy(struct spa_bt_quirks *quirks);
int spa_bt_adapter_has_msbc(struct spa_bt_adapter *adapter);
struct spa_bt_backend_implementation {
#define SPA_VERSION_BT_BACKEND_IMPLEMENTATION 0
uint32_t version;