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.
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.
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.
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.
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.
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.
The new helper function makes it easier to check whether any audio
profiles are connected. That information is needed by the discovery
module for deciding whether a new device module should be loaded. The
device module should use this information too to unload itself at the
right time, but that's currently not implemented.
The Device.Connected was only used for tracking whether a device module
should be loaded, but that information is already included in the
individual profile state properties. The property can therefore be
completely ignored without any loss in functionality.
UUIDs might be announced at any time, so a hook is needed to notify any
interested module. In practice, the UUIDs are quite stable with the
exception of the pairing procedure, where the UUIDs are reported by
BlueZ as soon as they are discovered.
The internal API in bluetooth-util should not use the const qualifier
for operations involving a device object. After all, the structure
contains many pointers and thus the const qualifier provides no real
protection.
The internal API in bluetooth-util should not use the const qualifier
for operations modifying the transport object. This is specially useful
in order to use the available hooks.
PropertyChanged signal of org.BlueZ.MediaTransport is processed in
pa_bluetooth_transport_parse_property() which updates t->nrec.
This is called by :
- First by filter_cb() of bluetooth-util.c
- Then by filter_cb() of module-bluetooth-device.c which retrieve value
of t->nrec before calling parse function, then it checks if t->nrec
has changed before updating bluetooth.nrec property.
As t->nrec has alreday been changed during first process, property
update is never performed.
This patch creates a new hook in pa_bluetooth_transport called
PA_BLUETOOTH_TRANSPORT_HOOK_NREC_CHANGED.
The hook is fired by bluetooth-util.c when the transport's NREC
property changes.
module-bluetooth-device.c won't listen the PropertyChanged signal of
MediaTransport anymore. Instead, it will use the hook in
pa_bluetooth_transport to get a notification when the NREC property
changes, and update the sink or source proplist accordingly.
const qualifier for returned pointer of
pa_bluetooth_discovery_get_transport() is removed.
Allow module-bluetooth-device to listens to HandsfreeGateway state
changes using DBUS signals. When an handsfree connects, module-bluetooth-device
is loaded and goes to playing state. When the handsfree disconnect audio,
the card profile is set to "off". If the headset connects audio again after
that, the card profile should switch to "hfgw" again to match state of audio
connection.
It's perfectly normal for BlueZ to disable some endpoint types, so printing a
log message at error level isn't a good idea.
For facilitating an informative message in case some endpoint type is disabled,
the send_and_add_to_pending() function interface is also changed to be more
generic (the pa_bluetooth_device pointer is replaced with a void pointer).
NREC stands for Noise Reduction and Echo Cancelation, it can be changed
at any point by the headset.
When set to "1" indicates that those algorithms shall be enabled by
default and "0" means the headset probably have them active so they
should be disabled in PA side.
Acquire now return input and output MTU of the file descriptor so it is
no longer necessary to get those after acquiring the fd, which less round
trips and faster response time when switching profiles.
Create the 'Handsfree Gateway' profile for bluetooth cards and add
filters for 'org.bluez.HandsfreeGateway' to the discover module so
module-bluetooth-device is loaded with the correct profile when a
Handsfree Gateway connects to bluetoothd (in this case bluetoothd
is acting as the headset).
