BlueZ Part 4: Understanding DBUS – Type system summary – (3)

Introduction:

In our last post, we delved into the intricacies of D-Bus container types, including Arrays, Dictionaries, and Variants. We provided straightforward examples to guide you in preparing and parsing these types using the powerful gbus/GVariant APIs from GLib. This time, let’s take our exploration a step further and uncover the full potential of these versatile tools. So to summarize,

While we haven’t yet explored every type and possible combination, we’ve laid a solid foundation by covering the basics and container types. This groundwork will be invaluable as we move forward, particularly in understanding how BlueZ leverages these types and where they come into play. Get ready to dive deeper into the world of D-Bus with BlueZ, uncovering the seamless integration and practical applications of these versatile data structures. Join us as we continue this exciting journey into the heart of Bluetooth technology!

Exploring BlueZ DBUS types:

There are many ways to explore how DBUS is used in BlueZ i.e for example, using

• DBus tools dbus-monitor, dbus-send
• gdbus – Tool for working with D-Bus objects
• busctl – systemd tool, which comes with flexibility

For the ease of understanding, we will be using busctl, but you can achieve the same using other similar tools as well. busctl by default lists all the dbus services running with Name, connection and systemd service which is responsible to providing the services over the DBUS.

To start with,

busctl introspect org.bluez /org/bluez
NAME                                TYPE      SIGNATURE RESULT/VALUE FLAGS
org.bluez.AgentManager1             interface -         -            -
.RegisterAgent                      method    os        -            -
.RequestDefaultAgent                method    o         -            -
.UnregisterAgent                    method    o         -            -
org.bluez.ProfileManager1           interface -         -            -
.RegisterProfile                    method    osa{sv}   -            -
.UnregisterProfile                  method    o         -            -
org.freedesktop.DBus.Introspectable interface -         -            -
.Introspect                         method    -         s            -

where org.bluez is the DBUS service and /org/bluez is the object path. Also,

busctl introspect org.bluez /org/bluez/hci0 org.bluez.Adapter1
NAME                  TYPE      SIGNATURE RESULT/VALUE                             FLAGS
.GetDiscoveryFilters  method    -         as                                       -
.RemoveDevice         method    o         -                                        -
.SetDiscoveryFilter   method    a{sv}     -                                        -
.StartDiscovery       method    -         -                                        -
.StopDiscovery        method    -         -                                        -
.Address              property  s         "A8:93:4A:DB:EA:16"                      emits-change
.AddressType          property  s         "public"                                 emits-change
.Alias                property  s         "parthiban"                              emits-change writable
.Class                property  u         7078156                                  emits-change
.Discoverable         property  b         false                                    emits-change writable
.DiscoverableTimeout  property  u         180                                      emits-change writable
.Discovering          property  b         false                                    emits-change
.ExperimentalFeatures property  as        -                                        emits-change
.Manufacturer         property  q         93                                       emits-change
.Modalias             property  s         "usb:v1D6Bp0246d054D"                    emits-change
.Name                 property  s         "parthiban"                              emits-change
.Pairable             property  b         true                                     emits-change writable
.PairableTimeout      property  u         0                                        emits-change writable
.PowerState           property  s         "on"                                     emits-change
.Powered              property  b         true                                     emits-change writable
.Roles                property  as        2 "central" "peripheral"                 emits-change
.UUIDs                property  as        12 "0000110e-0000-1000-8000-00805f9b34f… emits-change
.Version              property  y         10                                       emits-change

provides specific details about the hci0 dapter and specific interface org.bluez.Adapter1. So now we have three new terminologies to explore, service, object path and interface name.

In the context of D-Bus, a service, object path, and interface name are key concepts that help organize and access different functionalities provided by various applications.

1. D-Bus Service: A service in D-Bus is a unique name that identifies an application or a daemon providing specific functionalities over the D-Bus message bus. It is often in the reverse domain name format, ensuring uniqueness. For example, org.bluez is the D-Bus service name for BlueZ, the official Linux Bluetooth protocol stack.
2. Object Path: An object path in D-Bus is a hierarchical identifier used to address and organize objects within a service. Each object can represent a different component or resource within the service. For instance, /org/bluez/hci0 is an object path representing the first Bluetooth adapter managed by BlueZ.
3. Interface Name: An interface name in D-Bus defines a group of related methods, signals, and properties that an object implements. It is similar to an interface in object-oriented programming. The interface name org.bluez.Adapter1 in BlueZ, for example, defines methods, properties, and signals specific to Bluetooth adapter functionalities.

Example with BlueZ

• Service: org.bluez
  The org.bluez service name uniquely identifies the BlueZ Bluetooth stack on the D-Bus system.
• Object Path: /org/bluez/hci0
  This object path represents a specific Bluetooth adapter, typically the first adapter (hci0) managed by BlueZ.
• Interface Name: org.bluez.Adapter1
  The org.bluez.Adapter1 interface defines the operations, properties, and signals that can be used with a Bluetooth adapter object, such as enabling or disabling the adapter, setting its properties, or responding to specific adapter-related events.

By using these three components—service, object path, and interface name—D-Bus allows applications to interact with specific functionalities provided by other applications in a structured and organized manner.

Working with busctl:

> busctl get-property org.bluez /org/bluez/hci0 org.bluez.Adapter1 Powered
b true

here we are trying to get the powered state of the Bluetooth adapter using busctl, which returns true along with it signature. Speaking about signature, the column with all the signatures for BlueZ now should makes sense based on our understanding of basic and container types.

Conclusion:

We’ve provided an overview of the D-Bus type system, complete with signatures, and explored the specific types used by BlueZ for managing a Bluetooth adapter. With this foundational knowledge, you’re now equipped to understand how these components fit together.

In our next step, we’ll take it a notch higher by demonstrating how to read the powered state of an adapter using GDBus APIs. Get ready to dive into practical examples and see how to leverage these powerful tools in your own applications. Stay tuned for an exciting deep dive into the world of GDBus and BlueZ!