From: Mikel Astiz <mikel.astiz@xxxxxxxxxxxx>
d->hfgw_state is just another profile that should be considered exactly
as the rest inside device_audio_is_ready(), which is being used to
decide if the discovery hook gets triggered.
Therefore, there seems to be no reason to make an exception for this
profile and skip checking if the condition d->audio_state !=
PA_BT_AUDIO_STATE_INVALID holds true.
This change makes no practical difference but delaying the load of the
module also for HFGW until Audio.State is received. The benefit is
that the behavior and the code are more consistent across profiles.
---
src/modules/bluetooth/bluetooth-util.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/modules/bluetooth/bluetooth-util.c b/src/modules/bluetooth/bluetooth-util.c
index e09e170..21ce34e 100644
--- a/src/modules/bluetooth/bluetooth-util.c
+++ b/src/modules/bluetooth/bluetooth-util.c
@@ -192,11 +192,11 @@ static pa_bool_t device_is_audio_ready(const pa_bluetooth_device *d) {
pa_assert(d);
return
- d->device_info_valid && (d->hfgw_state != PA_BT_AUDIO_STATE_INVALID ||
- (d->audio_state != PA_BT_AUDIO_STATE_INVALID &&
- (d->audio_sink_state != PA_BT_AUDIO_STATE_INVALID ||
- d->audio_source_state != PA_BT_AUDIO_STATE_INVALID ||
- d->headset_state != PA_BT_AUDIO_STATE_INVALID)));
+ d->device_info_valid && d->audio_state != PA_BT_AUDIO_STATE_INVALID &&
+ (d->audio_sink_state != PA_BT_AUDIO_STATE_INVALID ||
+ d->audio_source_state != PA_BT_AUDIO_STATE_INVALID ||
+ d->headset_state != PA_BT_AUDIO_STATE_INVALID ||
+ d->hfgw_state != PA_BT_AUDIO_STATE_INVALID);
}
static const char *check_variant_property(DBusMessageIter *i) {
--
1.7.11.7
