Red Hat Bugzilla – Bug 836881
bluez-hid2hci missing in default install, causes bluetooth to be disabled
Last modified: 2012-11-21 05:41:48 EST
Description of problem:
In a default install of Fedora 17 on my MacBook4,1, bluez-hid2hci is not present. This causes bluetooth to be disabled, and it's not obvious to an average end user that the way to enable it is to install bluez-hid2hci.
Version-Release number of selected component (if applicable):
Fedora 17 x86_64 Live Desktop
How reproducible: Always
Steps to Reproduce:
1. Boot F17 from the x86_64 Gnome Live Desktop CD on a MacBook4,1
2. Observe that the Gnome panel does not contain a bluetooth icon
3. Open the System Settings and go to the Bluetooth pane. Observe that bluetooth is forced off
Bluetooth settings claims no adapter is detected. Once bluez-hid2hci is installed, bluetooth is immediately detected and works fine.
Bluetooth should be working from first boot.
The solution to not include bluez-hid2hci by default is the correct way to do it. hid2hci shouldn't be activated by default, because this doesn't work if your devices aren't paired, which is especially the case with fresh installs.
See bug #635244 for further explanation.
Thanks for looking at this, I understand the reasoning now at least. I'm still not sure it's the correct decision, though. Other OSes (Mac OS X, Windows and many distros such as Ubuntu) all automatically switch to HCI mode, for what it's worth.
If Fedora does stick with leaving hid2hci off by default, I think there should at least be some indication that this is happening. As things stand now, a typical user who has never heard of hid2hci will never be able to figure out why Fedora reports that their system has no Bluetooth adapter. They're likely to conclude that Fedora doesn't support BT on their computer.
If you search the web, you'll find many suggestions to change hiddev to hidraw in the udev rule too (to enable keyboards and mice). The reason is that this change just disables the udev-rule for hid2hci so the devices work (again) in HID mode and the authors of those suggestions just didn't realize that.
So the same problem exists vice versa too. And only not enabling it by default is correct because of the necessary link keys (and teaching people about the integrated intelligence of their dongles ;) )
A real solution would be something which would fetch the link keys from the dongles (which are needed for HID too, so the keys must be already somewhere in the dongles) into the bluez-db. Unfortunately hid2hci can't do that and I don't know if there even exists a standardized command to fetch those keys from the dongle.
Marcel Holtmann, the maintainer of bluez, once has "mumbled" (in an email to me) something about that there might be a possibility to fetch the keys from dongles, but I don't know if such a possiblity is standardized and so would be really usable with every of those HID-aware dongles out in the wild. And even if that is really possible, there might be security implications one has to think about. E.g. what happens if the key in dongle is different than the key in the bluez-db?
Hmm, that's an interesting idea. I have no idea if it's possible!
I was thinking a good workaround would be to add some indirection. Instead of having udev directly call hid2hci, have it call some script that only actually calls hid2hci under certain conditions, based on a config file. In the default case, including first boot, hid2hci will not be called, so users with dongles will be fine. But if the user explicitly attempts to turn on BT in System Settings, it can set a flag in the config file, and now hid2hci will be called. Wouldn't this satisfy both our use cases?
That's how it was done in older Fedora releases. The rule for udev has checked if an environment variable was set to enable hid2hic. But if you have to change such an environment variable through a config file or if you have to install a package doesn't make much difference. In both cases the HCI mode has to be disabled by default. The only difference would be that people would have to know which config file they have to change instead of installing a packet.
And if people doesn't know that they have to install hid2hci, they wouldn't know that they have to enable it too got get bluetooth functionality. So not much that different.
Mentioning the requirement to install bluez-hid2hci in the confing for bluez (e.g. in the example main.conf of bluez's git) might be a solution. This way other distributions would realize the requirement to disable HCI by default too and the whole confuscation about that topic across distributions maybe would disappear. ;)
1) There's no code to read the link keys from the various adapters we support
2) It's already documented in the FAQ section. Might do with updating.