bluetooth: Fix condition to load module

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.
This commit is contained in:
Mikel Astiz 2012-12-05 17:23:11 +01:00 committed by Tanu Kaskinen
parent f9beb8e867
commit 3f41a4a538

View file

@ -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) {