BlueZ 4 is no longer supported by BlueZ community for a long long time,
also by moving to BlueZ 5 it should make it even more clearer that
BlueZ 4 is no longer an option.
This removes the symdef header generation m4 magic in favour of a
simpler macro method, allowing us to skip one unnecessary build step
while moving to meson, and removing an 11 year old todo!
Some modules may only be loaded once, and trying to load them
twice from default.pa makes PulseAudio startup fail. While that could
be considered a user error, it's nicer to not be so strict. It's not
necessarily easy to figure what went wrong, if for example the user
plays with RAOP and adds module-raop-discover to default.pa, which first
works fine, but suddenly stops working when the user at some point
enables RAOP support in paprefs. Enabling RAOP in paprefs makes
module-gconf load the module too, so the module gets loaded twice.
This patch adds a way to differentiate module load errors, and
make cli-command ignore the error when the module is already
loaded.
A recent patch changed the MTU size from the default value of 48 to the value
returned by getsockopt(). This breaks HSP for some setups. To circumvent the
problem, this patch introduces a boolean parameter "autodetect_mtu" for
module-bluetooth-discover, module-bluez5-discover and module-bluez5-device to
make this use of getsockopt() configurable.
FSF addresses used in PA sources are no longer valid and rpmlint
generates numerous warnings during packaging because of this.
This patch changes all FSF addresses to FSF web page according to
the GPL how-to: https://www.gnu.org/licenses/gpl-howto.en.html
Done automatically by sed-ing through sources.
This patch adds a module argument "headset=ofono|native|auto" to
module-bluetooth-discover and module-bluez5-discover.
To make Arun's happy, the default is 'native' if compiled in, otherwise
'ofono'. 'Auto' will try to autoswitch depending on whether ofono is
running or not.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Previously module-bluez5-discover and module-bluez4-discover were being
tracked using their pa_module pointer. But during daemon shutdown these
modules are unloaded before module-bluetooth-discover, leaving stale
pointers in module-bluetooth-discover's userdata. To avoid this problem
this commit makes module-bluetooth-discover keep track of
module-bluez5-discover and module-bluez4-discovery by their indexes.
Create a wrapper module called module-bluetooth-discover to avoid
breaking backward-compatibility of default.pa. This wrapper may
eventually be dropped altoghether with BlueZ 4 support.
The current set of bluetooth modules only support up to BlueZ 4. Since
the BlueZ API when through a big change with the release of BlueZ 5 the
modules will be forked into a new set for BlueZ 5.
This commit also fixes the spelling of Bluetooth (it's a trademark which
should always be spelled with capital B) and the spelling of my name,
and also update the copyright note dates throughout the Bluetooth
modules.
Since the hashmap stores a pointer to the key provided at pa_hashmap_put()
time, it make sense to allow the hashmap to be given ownership of the key and
have it free it at pa_hashmap_remove/free time.
To do this cleanly, we now provide the key and value free functions at hashmap
creation time with a pa_hashmap_new_full. With this, we do away with the free
function that was provided at remove/free time for freeing the value.
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.
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.
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.
Let device module figure out the priority based on the state of the
profiles.
Note that most likely all profiles will be in PA_BT_AUDIO_STATE_CONNECTED
state so 'Off' will be the initial profile then it is up to the policy
module to switch to the most suitable profile.
The module module-bluetooth-device should never be given parameter
'profile' twice, even if both HFGW and A2DP are playing. This patch
proposed to consider HFGW first.
This patch will add the necessary quirks so that pulseaudio can register
an endpoint on the /MediaEndpoint/HFPHS path. This endpoint is to be
used for HFP Handsfree profile.
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).
