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:
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!
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.
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:
- Kill nickel and related processes (not strictly required, but recommended)
- Insert the sdio_bt_pwr kernel module (plus the uhid module if you want keyboard support)
- Launch hciattach
- 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!
Code:
$ 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.GetManagedObjectsWhen 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.