Skip to content

bluez5: probe adapter msbc capability via hci commands

P V requested to merge pvir/pipewire:fix-msbc-probe into master

Using a probe connection to determine adapter msbc capability causes problems on some adapters (ff8c3d20, 84bc0490, 71700433, #2030 (closed)) 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.)

Pulseaudio and oFono ignore this issue. I guess we can also do that if BlueZ & kernel deprecate the direct HCI access.

Just to be on the safe side, remove MSBC profile if we get EOPNOTSUPP from connect(). Automatic switching to CVSD would be nice here, but seems to require cooperation from session manager, so currently it'll switch to highest-priority profile instead.

Fixes #2030 (closed)

Initial transport volume was being set incorrectly to max for new transports. This is usually masked by route restore, but not always.

Edited by P V

Merge request reports