Clara 2E Tutorial: enabling bluetooth from the command line

[RDavidson]

This tutorial is ONLY for the Clara 2E. Other devices, such as the recent Clara BW and Clara Color, will probably require very different steps.

Suppose for some reason you're developing an app that will kill nickel and take over the screen (you know, like alternative reader apps do), and you want to use bluetooth. You could turn bluetooth on in the settings screen before launching your app, but you might forget, and then if you do you have to exit and wait for nickel to restart, and then do the whole thing over again. Much better to be able to start bluetooth on your own, whenever you want.

On the Clara 2E, here's what you have to do:

1. Kill nickel and related processes (not strictly required, but recommended)
2. Insert the sdio_bt_pwr kernel module (plus the uhid module if you want keyboard support)
3. Launch hciattach
4. Communicate with BlueZ over D-Bus (to launch the bluetooth daemon)

If you leave nickel running, I strongly recommend that you don't try toggling the Bluetooth setting in the UI. Only one bluetooth manager at a time, please!

$ insmod /drivers/mx6sll-ntx/wifi/sdio_bt_pwr.ko
$ /sbin/hciattach -p ttymxc1 any 1500000 flow -t 20
$ dbus-send --system --dest=org.bluez --print-reply  / org.freedesktop.DBus.ObjectManager.GetManagedObjects

This is in fact what nickel does to turn bluetooth on; although it uses Qt's D-Bus module and it makes different calls to BlueZ (to handle scanning, pairing, etc). nickel also uses the -n argument to hciattach instead of -p; this causes it to remain in the foreground, instead of printing its pid and backgrounding itself. If you're starting hciattach as a subprocess you will likely want to do the same thing.

When nickel turns bluetooth off, it kills the hciattach process and removes the sdio_bt_pwr kernel module. The bluetooth daemon (/libexec/bluetooth/bluetoothd) stays running unless it is separately killed.

The sdio_bt_pwr kernel module seems to control the bluetooth hardware itself. Running hciattach connects the bluetooth hardware to the bluetooth stack; without this step you could interact with BlueZ but no adapters would be present, which makes the whole thing pretty useless.

Interacting with BlueZ over D-Bus is exactly the same as it is on any other Bluetooth-enabled Linux machine. Plenty of tutorials and sample code are available. The relevant config directories are /etc/dbus-1 and /usr/share/dbus-1. D-Bus is configured to launch the bluetooth daemon as soon as any interaction happens with the org.bluez busname. So in the above example, just asking it what objects it knows about is sufficient to launch the daemon.

Once the daemon is launched, you can use the bluetoothctl command line tool, or keep interacting with it over D-Bus, depending on the scope of your program. As far as I can tell, nothing you do here is going to break nickel's Bluetooth support, though nickel may be a little confused if you pair a keyboard, because nickel assumes you're going to be pairing audio devices.

If you wanted to completely isolated from nickel's bluetooth settings, you may be able to do this by swapping out the contents of /var/db/bluetooth. (That is, move the existing contents to a safe place, then put in the saved settings files for your app, and then reverse this process before allowing nickel to restart.) I have not tested this for safety. Needless to say, if you do try this, you should make absolutely certain that bluetoothd is not running when you make changes in its settings directory.

[jixbo]

Can you do this permanently?

I am trying to use my kobo clara 2e for typing with a bluetooth keyboard, but I have to enable bluetooth every time, and I haven't found a way to take notes, as Koreader kills bluetooth.

[RDavidson]

I don't know what you mean by "do this permanently". Of course bluetooth will be turned off the next time the device reboots, and there is no way (other than modding koreader) to prevent koreader from turning bluetooth off.

[lumping-sugar66]

Hello. Wow, I must've I missed this because I asked the question which you answered here.

For archive purposes I'll share my turn on/off scripts below. But I was going crazy with how

hciconfig hci0 up

would simply not bring the device up. This insmod seem to do the trick.

I will give your solution a try, I think the only thing missing from your script as it currently sits is the

hciconfig hci0 up

at the end, but it goes through hiccup.

One thing that I've notived with my experiments so that is that if you turn on bluetooth via nickel, then no matter what you do the system will lose 3% battery per hour, doesn't matter if you properly shutdown bluetooth or pkill all processes, nothing. Maybe this mod you mentioned is the trick. I will experiment and share my findings here.


FWIW, it's easy to prevent koreader from killing bluetoothd on startup:
Just comment out the bluetoothd in the killall comment in koreader/koreader.sh

killall -q -TERM nickel hindenburg sickel fickel strickel fontickel adobehost foxitpdf iink dhcpcd-dbu # bluetoothd

But If you can turn it on from the koreader via a plugin (which I'm writing), I wouldn't comment it out, and leave it as it is.


One thing that still baffles me is the requirement to have wifi enabled is still present with this set of commands. I disable network and trigger these commands via koreader, and bluetooth won't come up. It doesn't have to be connected to any network, but wifi needs to be turned on.