Author: Parthiban

This blog is the continuation of list controllers using HCI interface, to cover the same use case using DBUS interface provided by Bluez. We will be using the “GetManagedObjects” methid to get the list of Bluetooth controllers.

Using GDBUS:

Using GDBUS Proxy:

If Bluetooth service is not running, you can start it using,

systemctl start bluetooth

As described in the in Bluez Blog D-Bus ObjectManager section, one should use “GetManagedObjects” method provided by the “org.freedesktop.DBus.ObjectManager” interface to get list of available Bluetooth controllers by filtering the interface name againt “Adapter1“. Here in our examples, after obtaining the object paths, we are using the “org.freedesktop.DBus.Properties.Get” method in “org.bluez.Adapter1” interface to get the Name and MAC address of the Bluetooth controllers. When more then one Bluetooth controller is found, this example will list the Name and Address for all the controllers.

Similarly one can use the same method to get all the other properties of the controller (will be in next blog).

We can use dbus-send to explore the same information. Try the below command.

dbus-send --system --print-reply --type=method_call --dest='org.bluez' '/' org.freedesktop.DBus.ObjectManager.GetManagedObjects

Caution:

One should be cautious when using GDBUS proxy based implementation in real application, because

• If the service provider (Bluez in this case) is disappeared/crashed/restarted, then our proxy connection will be invalidated (in dangling state)
• This can even happen when “StopWhenUnneeded=yes” option is specified in systemd service file “Unit” section.
• Using such danging proxy will result in Segmentation fault.

To avoid such cases, one should watch “InterfacesRemoved” and “InterfacesAdded” generated on the “org.freedesktop.DBus.ObjectManager” interface to update the proxy to service path/name.

Yocto stops building the global sysroot (both native and cross) from version 2.6. To build any package yocto copies the sysroot as “recipes-sysroot” and “recipes-sysroot-native” into each WORKDIR. This stops the external application builders from using “tmp/sysroots/<MACHINE>” for cross compilation. To do the same way building external application using common sysroot and toolchain one need to build or populate the sysroot explicitly using

bitbake build-sysroots

This bitbake command explicitly populates the sysroot in “tmp/sysroots/<MACHINE>”  and “tmp/sysroots/x86_64 or x86” accordingly. With this application developers can cross compile after exporting the toolchain path “tmp/sysroots/x86_64/usr/bin/<toolchain-name>”. All the dependent cross compiled binaries and libraries can be found under “tmp/sysroots/<MACHINE>”.

Use bitbake sysroot to find provider:

You can also use this sysroot to find the provider of a particular file. For example, if you want to use blkid functionality and you don’t know the yocto/bitbake provider for this libraries or binaries to include into your recipe, you can grep for the header/library/binary inside “tmp/sysroots/<MACHINE>” directory. For this case “libblkid.so/blkid.h” is provided by util-linux, which can be obtained from “manifest-armv7ahf-neon-util-linux.populate_sysroot” (machine type may vary according to your target configuration).

Reference: Build directory structure in Yocto Mega manual

This is the fist post in the series of blogs for Bluetooth in Linux. In this series we are going to cover mostly about Bluez and it’s provisions for Bluetooth functionality over DBUS (API’s in bluez/doc/).

We will also cover few Bluetooth profiles like GAP, A2DP, AVRCP, PBAP in near future.
Assumption:

This series of post assumes that you have successfully installed Bluetooth and libbluetooth-dev package. And also enabled the Bluetooth controller. If not, please visit your distribution document and install the required packages.

For arch linux,

pacman -S bluez bluez-utils

systemctl start bluetooth

systemctl enable bluetooth # Enable automatic startup during bootup

In this post, we are going to find the available Bluetooth controller using the HCI interface. Note: We are not going to use HCI interface in our future post. The next blog will cover the same use case of finding the controllers using org.bluez interface provided by Bluez over DBUS.

HCI_MAX_DEV is the maximum number of controller devices which can be handled at a time. So here we are using the HCI interface “hci_devinfo” to find the device information. This API internally uses AF_BLUETOOTH socket to connect with Linux Kernel Bluetooth and uses IOCTL HCIGETDEVINFO to get device information.

hci_devinfo fills the “struct hci_dev_info“, which contains the information/details about the controller. flags element in hci_dev_info stores the current status of the controller. This example tests the status against HCI_UP to find the controller which is in UP state. Here only the Name and MAC address of the controller is printed.

As HCI interface interacts directly from userspace to kernel space using IOCTL, we don’t need have bluetoothd daemon running.