Then it happened. Ubuntu went up one release: Jaunty came to be and subsequently Bluetooth support died. Even now the Internet is teeming with Bluetooth bug reports, problems and forums are filled with questions such as ‘my keyboard is not being paired’. In fact, Debian seemed to be hit as well as some other distributions that leveled up.

What had happened?

Bluez changed is what happened

The developers of bluez, once the nice Bluetooth package everyone could live with, decided it was time for a major overhaul: they merged the packages bluez-libs and bluez-utils and then some. And with ‘and then some’ meaning completely changing the way Bluetooth devices are configured and thereby breaking backwards compatibility.

All of this shouldn’t really matter, except for one little detail: The Ubuntu dev team thought it was a good idea to drop the old Bluetooth support and go for the new version. They included bluez 4.0 and everybody broke in tears. That’s all there is to this little story, Bluetooth has been neglected since 2008 when Jaunty came about and things have not improved.

Why is that?

Bluez is a bunch of cowboy coders is why

Actually, I know nothing of the team except that it seemingly has about one active developer. Bluez arguably is an awesome team: they have these coders, stomping away on probably wireless keyboards to create utterly thorough Bluetooth support for Linux. They’re awesome right? Perhaps not.

Bluez doesn’t document anything. At all. It’s a widely acknowledged fact (Gentoo too?) they didn’t document the legacy Bluetooth support and they didn’t document the new support. If you read the bluez 4.0 release notes you still don’t know anything and you won’t either. Nobody will, because there is no documentation! Oh, they’ll completely overhaul Bluetooth support but they’ll never tell how it works now. That’s for you to find out. I’ve even glanced over the source code only to find out that they don’t like to comment their code either.

Definition of a Cowboy Coder
Although normally I couldn’t care less about some random piece of software, but if you include a significant framework in your operating system, there have got to be some kind of set of standards that includes documentation, right?

That’s why everyone is still dealing with the same problems it did in 2008: the old community documentation is still there, but it isn’t getting updated. That page is just one of hundreds ofcourse. Here’s the typical research process one goes through figuring out how to get Bluetooth working (notice how he’s constantly confronted with conflicting guides and ultimately didn’t find a solution). The problem again is that nobody can update those pages. If you are feeling particularly masochistic, try reading this thread (especially the last post where it says ‘SOLVED’).

Let’s discuss what must be one of the most encountered problem: ‘hcid.conf is missing!’. Old documentation will tell you how to configure your Bluetooth device in Ubuntu so that it connects when your pc boots. That is to say, how you need to edit a /etc/bluetooth/hcid.conf configuration file. Well, that file was removed by the bluez team in bluez 4.0. Reread the bluez 4.0 release notes:

With this new major version a lot of things have been changed:
– The main daemon is now called bluetoothd (instead of hcid)
– The main configuration file is /etc/bluetooth/main.conf and follows INI-style syntax

And indeed, scanning the source files reveal that the hcid.conf is no longer used, but other configuration files instead. It appears to me that hcid.conf has become main.conf, except that scanning the code doesn’t confirm this. Instead, main.conf and input.conf are only used to read the options already provided. Changing the names of configuration files ofcourse isn’t the only thing that changed, since just using main.conf or whatever doesn’t seem to magically do the trick. I still can’t figure out how to enumerate devices in the new configuration files, it’s not like you can’t just say, ‘Well, instead of hcid.conf just use blah.conf’. I did get a long way configuring my keyboard in rfcomm.conf, but since my keyboard doesn’t seem to support SMP (Session Multiplex Protocol, I got errors reporting this to me), I assume it is used mainly for pairing phones.

Even now, everyone still uses the deprecated but still supported hidd, primitive but effective bluetooth adapter tool. You can install it using the command sudo apt-get install bluez-compat and then use it they way I used it to connect my keyboard. You just can’t use it to reconnect devices with from reboot, wake up, or the device coming out of suspension. The hcid.conf was used for this, but now it is dead.

About hidd being deprecated anyway

If hidd has become deprecated, I wonder what replaced it. Searching the internet revealed nothing. Until I found this deeply hidden gem. In this Debian bug report, this guy ‘Phil’ mentions how a guy on the bluez mailing list mentioned that a wiki mentioned something about hidd being replaced with a more generic so called ‘”input service” over dbus‘ approach? Woh, have I just found a vague piece of information about how things changed? Let’s see this Wiki! Oh wait! IT DOESN’T EXIST! Sigh.

I had set up my bluetooth keyboard based on the instructions in /usr/share/doc/bluez-utils/README.Debian, i.e. starting hidd –server by enabling it in /etc/default/bluetooth, running hcitool scan, and then hidd –conect . This method is now deprecated; instead we should use something called the “input service” over dbus. See the following page, which contains examples of dbus-send commands to do this: http://wiki.bluez.org/wiki/HOWTO/InputDevices

Ofcourse I just *had* to know what was on that Wiki, so I turned to the ever so awesome Wayback Machine. Here’s what I found. Read it yourself. Hint: you won’t get anywhere, but here’s what I get from it. It seems the new approach is a more generic ultra obfuscated command that accepts an instruction class or identifier such as ‘org.bluez.input.Manager.RemoveDevice’. No manual and certainly nothing about configuring your connections for auto-connect during boot.

I don’t know why they took down the wiki, but from the looks of it, most of it was about the API anyway, useful for developers, not end-users using the command-line.

Also, there’s an interesting discussion on bluez 4.0 in Arch Linux I found, the first one I’ve encountered where the participants actually try to get the new ‘dbus’ way working. Nothing we can use in Ubuntu though. I’ve tried to get bluez talking to me using dbus, but I couldn’t get it to do anything but spout a range of errors.

Finally, a guide I found on using Bluetooth with bluez 3 and 4 not related to a particular Linux distribution. Unfortunately, the dbus keeps barfing up on everything I throw at it, so no dice for Ubuntu I guess.

Current state of Ubuntu’s Bluetooth support

Technically the title of this blog post is wrong: Ubuntu’s Bluetooth support is probably better now than it ever was, it’s just that nobody knows how to use it. To be fair, it’s not an entirely lost cause; people still get their devices to work properly after many people have tried to fix some variation of a given problem and people figured out how to connect a mouse or a phone using the new Bluetooth support for example, often with obscure workarounds. But a lot of people, including me, still can’t get a Bluetooth keyboard to connect and pair during boot.

Also there is a solution if you happen to use some desktop, using the Bluetooth Applet. It handles everything for you and reportedly it generally works. It’s no use to me however as I’m only running a server, but I might check out the applet’s source code to see how it works, hopefully using bluez’ command line API.

As of yet, there has been no answer from the dev team on the number one search result for ‘missing hcid.conf’ bug report: Bug 365779. Technically it’s not a bug, but the fact that it hasn’t been closed, deferred to another bug or had a dev on it since May 2009 indicates it either has no priority or nobody had the balls to fix it. Notice though there are literally hundreds of bluez related bug reports for numrous distro’s.

Also a search on the original writers of the last hcid.conf man page didn’t reveal a comment on how things changed and how things now work.

So what needs to be done to get some clarity on the matter? If you know, please shout out, because yes, I’m currently still looking to fix my keyboard under Ubuntu 10.04.

Meanwhile, try downgrading the bluez package to its previous version (note: I couldn’t get the bluetooth package to work with the older bluez packages in Ubuntu 10.04, good luck and have fun).

trackback

Originally, this whole workaround came from a post on ubuntuforums.org by Unkie, which I modified only slightly (I’m plantface there). This workaround revolves around hidd, which was removed in Ubuntu 9.04 which you can get back as follows:

sudo apt-get install bluez-compat

Hidd is a tool that works like a charm for scanning and connecting to bluetooth devices. It’s still used these days because the Ubuntu dev team somehow manages to kill bluetooth support every new version. There are so many tutorials and flavors floating around to get a bluetooth device working and apparently with so little success that hidd remains popular. With 9.04 they gave bluetooth an overhaul and deprecated hidd.

Anyway, here’s the shell script that keeps connecting your keyboard. There’s one catch though: I haven’t figured out how to let the keyboard sleep, awake and reconnect itself, so you’ll need to hit the reset button on the keyboard to reveal itself to the bluetooth adapter looking for it. Reconnecting this way requires thus one extra manual action before it reconnects (same thing goes for when you rebooted). But it reconnects when you want it to, which is what I’m content with for the moment, considering the alternative.

1. First create a new file for the script:

   sudo nano /etc/keyboard.sh

   Add the following script:

   while (sleep 10)
   do
   sudo hidd --connect AA:BB:CC:DD:EE:FF > /dev/null 2>&1
   done
   

   Close and save.

   Note: that AA:BB address should be the MAC address of your keyboard. You can find it using the new bluetooth tool hcitool scan (make sure your keyboard is findable by hitting its reset switch) or with hidd –search, which coincidently will automatically attempt to connect your device while scanning it.

   EDIT: August 8th, 2010
   I updated the above script to react much more quickly and avoid unnecessary connect attempts:

   
   #! /bin/bash
   
   address="AA:BB:CC:DD:EE:FF"
   
   while (sleep 1)
   do
    connected=`sudo hidd --show` > /dev/null
    if [[ ! $connected =~ .*${address}.* ]] ; then
     sudo hidd --connect ${address} > /dev/null 2>&1
    fi
   done
   

2. Next we’ll make sure it’ll run in the background when booted. Create a new boot entry:

   sudo nano /etc/init.d/keyboard

   Add the following script:

   #!/bin/sh
   
   /etc/keyboard.sh &
   
   exit 0
   

   Close and save.

3. Give both files execution rights with chmod +x {filename}
4. Now run the following command to get the script executing during boot:

   sudo update-rc.d keyboard defaults

Reboot and check if it works. Remember to hit your keyboard’s reset switch when you want Ubuntu to connect your keyboard.

trackback