DBUS APIs in BLUEZ

Question

I am new to BLUEZ as well as linux. I found that Bluez promotes usage of DBUS APIs. I want to know whats a DBUS API in terms of BLUEZ also, whats the benefit of using them instead of direct C APIS? How different is it as compared to C APIs?

Answer 1

From my own experience:

• DBUS apis are the officially published ones so are more likely to be stable, maintained and documented.
• The C apis are a bit more low level and it's not always obvious how they can be used (beyond simple discover).
• The C apis are more light weight whereas the DBUS APIs require more both at build time and at run time (glib, dbus, bluetoothd to name a few things).

So it depends on what you are trying to achieve. If you just want basic discovery and rfcomm/l2cap connections then the C apis are probably ok. If you want anything beyond that and if your platform is able to accommodate the extra overhead of DBUS/bluetoothd/etc then you probably want to go with the DBUS apis.

Answer 2

Update: bluez now supports a gatt API via the dbus. Just completed in 5.28 (though I think there were bits of it in earlier versions).

Answer 3

Bluez pushes the use of the DBUS interface over the rest. Unfortunately, not everything is possible through the DBUS interface.

I haven't looked at it recently, but it used to be that BLE was poorly supported though DBUS. You could only interact with officially published BLE profiles such as heart rate monitors. If you wanted to do anything with attributes not part of any Bluetooth BLE profile then you were stuck. So, for example, accelerometers were impossible to access via the DBUS interface.

This may have changed in the 5.X branch (I haven't been looking at it because it doesn't work on the 3.4 kernel I have to use). The 4.X branch of Bluez hasn't changed and it's definitely the case you'll have issues with BLE over DBUS on non-profile attributes.

Just a note of warning, though, if you're using the 3.4 kernel or older you'll have issues opening more than one L2CAP socket. There's a bug in the kernel that no one seems interested in fixing. (what happens is all the data comes down one socket regardless of which device it came from)