I have been debugging a regression where Bluetooth has stopped working on
some broadcom Wifi/BT chipsets. This is caused by the BT parts of these
chips not having a unique MAC programmed into them. Instead they all use
the same factory-default address. This used to work as long as only one
device with this factory-default address was in the room. But a while ago the
kernel learned to recognize the factory-default address and now it (rightly)
refuses to use this. Instead it expects userspace to configure a valid MAC
address.
Both checking if their are any adapters in the unconfigured state (these
are invisible in e.g. bluetoothctl) and setting their MAC address to make
them work requires the btmgmt util, so lets package it.
Note this is not a complete fix for this issue, but having btmgmt
available will at least allow users to work around the problem.
I've filed an upstream bluez issue for getting a workaround for this
in place inside bluez: https://github.com/bluez/bluez/issues/107
Drop the obsolete udev rule + systemd service to call btattach on BT-HCIs
connected via UART from userspace.
I added these a long time ago to make BT work on Broadcom HCIs connected
through an UART, but this has not been necessary for a long time.
The kernel now makes the connection between the UART and the HCI itself
and as part of this it no longer instantiates the platform-devices which
the udev rule triggers on, so these have been a no-op for a long time now.
The HCI emulator is useful for QA testing, beyond testing bluez itself.
Let's put it in the -devel subpackage, so that we don't clutter the main
package but also avoid creating a subpackage.
https://src.fedoraproject.org/rpms/bluez/pull-request/2
Backport loads of fixes from upstream, including:
dbus-broker support (#1711594)
a2dp codecs discovery
discoverability filter support (used in gnome-bluetooth, #1583442)
sixaxis pairing fixes
