This commit makes the code cleaner, avoiding unnecessary line breaks. It
also changes the debug message elements order, to make it look more
natural ("path, interface, member" instead of "interface, path,
member").
If BlueZ crashes exactly while PulseAudio waits for the GetProperties reply, the
device has already been removed from the hashmap and therefore an assertion
failure is experienced.
The solution consists of ignoring the reply in these cases.
The problem can be observed in the following traces:
D: [pulseaudio] bluetooth-util.c: Bluetooth daemon appeared.
D: [pulseaudio] bluetooth-util.c: dbus: interface=org.bluez.Manager, path=/, member=AdapterAdded
D: [pulseaudio] bluetooth-util.c: Adapter /org/bluez/497/hci1 created
D: [pulseaudio] bluetooth-util.c: Registering /MediaEndpoint/HFPAG on adapter /org/bluez/497/hci1.
D: [pulseaudio] bluetooth-util.c: Registering /MediaEndpoint/HFPHS on adapter /org/bluez/497/hci1.
D: [pulseaudio] bluetooth-util.c: Registering /MediaEndpoint/A2DPSource on adapter /org/bluez/497/hci1.
D: [pulseaudio] bluetooth-util.c: Registering /MediaEndpoint/A2DPSink on adapter /org/bluez/497/hci1.
D: [pulseaudio] bluetooth-util.c: dbus: interface=org.bluez.Adapter, path=/org/bluez/497/hci1, member=DeviceCreated
D: [pulseaudio] bluetooth-util.c: Device /org/bluez/497/hci1/dev_90_84_0D_B2_C7_04 created
D: [pulseaudio] bluetooth-util.c: dbus: interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, member=NameOwnerChanged
D: [pulseaudio] bluetooth-util.c: Bluetooth daemon disappeared.
E: [pulseaudio] bluetooth-util.c: Assertion 'p->call_data == d' failed at modules/bluetooth/bluetooth-util.c:685, function get_properties_reply(). Aborting.
A transport should be considered connected only after the connection
procedure is complete, as expressed in audio_state_to_transport_state().
module-bluetooth-device should be loaded only after at least one
transport is not only created (during configuration), but also
connected.
This fixes the issue of premature acquire attempts sometimes experienced
when a headset is connected (issue not present in v3.0 though).
The previous patch removed module-gconf's dependency on the userdata
pointer of the free callback, and that was the only place where the
userdata pointer of pa_free2_cb_t was used, so now there's no need for
pa_free2_cb_t in pa_hashmap_free(). Using pa_free_cb_t instead allows
removing a significant amount of repetitive code.
Make sure the reply to SetConfiguration() is sent before the internal
hook is fired. This is important because the hook could have side
effects including D-Bus interfactions (i.e. transport Acquire() being
called during module startup).
As pointed out by Tanu, checking both error conditions is redundant and
raises the question whether it's possible that one of the conditions is
true while the other is false.
Therefore, simplify the condition by just checking one part of the
disjunction.
The function was used to check whether the basic properties of the
Bluetooth device have been received. This can be simplified by just
checking d->device_info_valid, since the state of the audio interface
is only relevant inside pa_bluetooth_device_any_audio_connected(), which
is used to trigger the discovery callback.
While checking device_info_valid, special care must be taken with all
three possible values: when set to -1, it means some error was triggered
while getting the device properties. Therefore, these devices can also
be ignored outside bluetooth-util.
Besides that, the patch slightly modifies the behavior of the internal
API affecting pa_bluetooth_discovery_get_by_address() and
pa_bluetooth_discovery_get_by_path(), since they will return the device
no matter the state of the audio interface. This however makes sense and
should have no influence in the current codebase given that the modules
make use of devices only after the discovery hook has been triggered.
The function is used to make sure some basic information has already
been gathered before the device is being used. At this point profile
states can be ignored, since their initial value will be
PA_BT_AUDIO_STATE_INVALID and thus effectively similar to
PA_BT_AUDIO_STATE_DISCONNECTED due to audio_state_to_transport_state().
The change should make no difference given that the behavior of
pa_bluetooth_device_any_audio_connected() doesn't change: by the time
TRUE is returned, a transport needs to exist. This means a profile
will exist in CONNECTING or CONNECTED state and thus the old
implementation of device_audio_is_ready() would also have returned TRUE.
Trivially fix some style issues affecting line wrap (128 chars max with
the exception of multi-line comments, which are limited to 80),
indentation and unnecessary parentheses.
pa_bluetooth_discovery_sync() waited until all pending method calls
had completed. I don't understand what the benefit of that could be,
so I removed the function. We should avoid blocking as much as
possible, and the code that used pa_bluetooth_discovery_sync() didn't
look like it really needed to wait for anything.
In addition to moving the freeing a bit later, unnecessary checks for
t->device are removed. t->device is initialized to a non-NULL value
when the transport is created, and it's never changed.
The transport state also reflects the state of the audio interface. The
state redundancy can thus be minimized by always using the first one,
and avoiding the use of profile-specific states with the exception of
finding out the initial state of a transport.
The state of this interface is needed for one single reason: we need to
wait until all profiles have been connected (or more precisely, until
are connection attempts are finished). This can be made more explicit in
the code by just checking the CONNECTING state (and not loading
module-bluetooth-device during that state), but otherwise treating all
transport types equally.
Ideally, audio_state should be completely removed but it's left there to
avoid an issue with module-card-restore, as documented in the source
code's comments.
Transports can be acquired with different access rights, but in practice
"rw" was always used inside module-bluetooth-device. In addition, this
feature is removed in BlueZ 5.0 and therefore it is convenient to
abstract all this inside bluetooth-util.
Use transport state to calculate the corresponding port availability,
and while doing so use bluetooth-util to receive profile state updates
instead of directly parsing D-Bus PropertyChanged signals.
Move the function to the utility library where the enum is defined. At
same time avoid using the default clause in order to make sure the
compiler will complain if the enum type gets extended.
Similarly to the microphone gain, the speaker gain can be abstracted
inside the transport object, even though the actual D-Bus interface in
BlueZ differs.
The microphone gain represents the volume of the incoming audio stream
from the headset. This can be nicely abstracted inside the transport
object in bluetooth-util, so the modules don't have to take care about
the D-Bus details.
Add the transport-handling hooks to the centralized list of hooks in
pa_bluetooth_hook_t. These are intended to replace the now deprecated
transport-specific hook list in pa_bluetooth_transport_hook_t.
Transport objects have an associated state even though it's not
explicitly exposed in BlueZ's D-Bus API (prior to 5.0). Instead, the
state is implicitly represented in the profile-specific D-Bus interface
(i.e. org.bluez.Headset, org.bluez.AudioSink, etc.) but it can be
convenient that bluetooth-util would abstract this separation.
The old implementation is limited to parsing the profile state, but
the D-Bus API actually exposes many more properties that are currently
not being considered, specially within org.bluez.Headset.
Centralize the Bluetooth hooks in one single place, starting with
the device hooks, while removing the duplicated ones (in this case
PA_BLUETOOTH_DEVICE_HOOK_REMOVED).
Devices will have zero or one transports per profile, and besides the
typical lookup is also profile-based. Therefore, replace the old hashmap
(which used the transport path as key) with a simple array which holds
a transport pointer per profile.
Path-based transport lookups are required in a discovery basis, before
the associated device is known. Therefore, it makes more sense to
maintain a hashmap in the discovery structure itself, instead of
iterating all devices.
Transports always have an associated device, so add the pointer as a
member to the structure, and remove the discovery pointer since it
already exists in the device object.
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.
With BlueZ 5 it is possible to have profile registered by a third party
process which does not share the same bus id as bluetoothd so it is
necessary to store the sender of the transport to be able to talk to it.
Note that this is backward compatible.
