Bluetooth adapter configuration issue (ID 0a12:0001)
There are several versions of this device with the same USB ID. According to some are these fake, but I suspect these are only newer models of the chip.
There are a couple of quirks needed to get the chip to work and one needs to patch the kernel code responsible for enabling these quirks to test for these newer models:
--- drivers/bluetooth/btusb.c.old 2020-03-31 19:14:11.765239911 +0100
+++ drivers/bluetooth/btusb.c 2020-03-31 19:22:17.035003199 +0100
@@ -1643,4 +1643,6 @@
/* Detect controllers which aren't real CSR ones. */
if (le16_to_cpu(rp->manufacturer) != 10 ||
+ le16_to_cpu(rp->lmp_subver) == 0x0811 ||
+ le16_to_cpu(rp->lmp_subver) == 0x0812 ||
le16_to_cpu(rp->lmp_subver) == 0x0c5c) {
/* Clear the reset quirk since this is not an actual
@@ -3873,5 +3875,5 @@
/* Fake CSR devices with broken commands */
- if (bcdDevice <= 0x100 || bcdDevice == 0x134)
+ if (bcdDevice <= 0x100 || bcdDevice == 0x134 || bcdDevice == 0x8891)
hdev->setup = btusb_setup_csr;
I don't give a guarantee that this fixes the issue for all newer models and it may need additional tests to include more LMP sub versions and bcdDevice numbers. However, the above does work for some users who have been using the newer Bluetooth 4.0 models and for myself, using a Bluetooth 5.0 model.
It brings up the device as shown here:
# hciconfig
hci0: Type: Primary Bus: USB
BD Address: 00:1A:7D:DA:71:11 ACL MTU: 679:9 SCO MTU: 48:16
UP RUNNING
RX bytes:56724 acl:29 sco:0 events:7890 errors:0
TX bytes:4782028 acl:7788 sco:0 commands:84 errors:0
This was tested with kernel 5.5.13 and a cheap Bluetooth 5.0 dongle from AliExpress, and it now lets me connected to a Bluetooth 5.0 headset.
The dongle works just fine under Windows 10 by the way.
Addition: Turning Off USB Auto-Suspend
The auto-suspension of USB ports can interfere with Bluetooth USB dongles. While auto-suspend helps to save power and the devices should wake up quickly on their own can this fail and so degrade the Bluetooth connectivity. By default does the kernel suspend USB ports after 2 seconds. This can be disabled either for all USB ports or only for individual ones, and the Bluetooth USB driver has got a parameter, which specifically controls this for USB-attached Bluetooth dongles. For example, to see the current status:
# lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 062a:3633 MosArt Semiconductor Corp. Full-Speed Mouse
Bus 004 Device 002: ID 1b1c:1b39 Corsair Corsair Gaming K65 RGB RAPIDFIRE Keyboard
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
# grep . /sys/bus/usb/devices/[0-9]*/power/control
/sys/bus/usb/devices/4-1/power/control:on
/sys/bus/usb/devices/4-2/power/control:on
/sys/bus/usb/devices/5-5/power/control:auto
Here mouse and keyboard are always powered on, but the CSR Bluetooth USB dongle is set to auto-suspend. If auto-suspend is enabled and it is causing trouble then one can test it by temporarily disabling it:
# echo on > /sys/bus/usb/devices/5-5/power/control
# cat /sys/bus/usb/devices/5-5/power/control
on
When this helps then one should disable it permanently and there are several ways to do this:
When you are already recompiling the kernel then it is likely best to disable it with the Bluetooth USB kernel module by setting the configuration parameter CONFIG_BT_HCIBTUSB_AUTOSUSPEND to N or by commenting it out in the kernel config file. This will cause the Bluetooth USB driver to disable auto-suspend by default for every port it finds a matching device on, and leaves all other USB devices as they were.
Without recompiling the kernel and where the Bluetooth USB module is compiled into the kernel does one need to do this with a boot parameter. For GRUB edit /etc/default/grub and append the kernel command line with btusb.enable_autosuspend=n. Then update the grub configuration by running update-grub and reboot.
File: /etc/default/grub
...
GRUB_CMDLINE_LINUX_DEFAULT="... btusb.enable_autosuspend=n"
...
- Without recompiling the kernel and where the Bluetooth USB module is loadable should one create a file in /etc/modprobe.d/ to pass the parameter. Then either reboot, or, unplug the dongle and remove the kernel module with rmmod btusb and restart the module service with service systemd-modules-load restart before plugging the dongle back in again.
File: /etc/modprobe.d/bluetooth-usb.conf
options btusb enable_autosuspend=n
Addition: Enabling The Fast Connectable Setting
Another method for improving Bluetooth connectivity is to enable the FastConnectable setting of the bluetoothd daemon. The setting can be found in /etc/bluetooth/main.conf.
File: /etc/bluetooth/main.conf
...
# Permanently enables the Fast Connectable setting for adapters that
# support it. When enabled other devices can connect faster to us,
# however the tradeoff is increased power consumptions. This feature
# will fully work only on kernel version 4.1 and newer. Defaults to
# 'false'.
FastConnectable = true
...
I have this dongle - it's several years old so I can't comment on whether it's a fake or whether modern dongles with this USB ID can be fake.
Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
I'm using it with a really old Acer TravelMate 2420 laptop using (out of necessity) the i386 release of Ubuntu 18.04 LTS. (Current kernel as of the time of writing is 4.15.0-106-generic. (No need to feel sympathy. This is just an old spare computer I keep in the bedroom and use occasionally.)
Bluetooth worked for me, but wasn't very reliable. I would get frequent disconnections of my Bluetooth mouse (Microsoft Bluetooth Notebook Mouse 5000).
I solved the problems completely a couple of weeks ago with the following changes in /etc/default/tlp
:
# Exclude listed devices...
USB_BLACKLIST="0a12:0001"
# Bluetooth devices are excluded...
USB_BLACKLIST_BTUSB=1
(Find the appropriate lines and add the first and edit the second accordingly.)
It is likely that I don't need the specific ID-based USB_BLACKLIST
command (I've not tested this) but thought I'd leave it in for safety. The second (USB_BLACKLIST_BTUSB) defaults to 0 on my system and I suspect this is the key configuration to change.
You may need to install the tlp
package specifically, if it's not already installed. Don't forget to restart it after reconfiguring it.
I hope this helps.