Question

Here I want to know about dbus-send command in brief

I want to know how we can use this and how this command call automatically functions of other c files.

Here I put one example which is used in Bluetooth pairing and unpairing. please Explain me

dbus-send --system --print-reply --dest=org.bluez  $BT_ADAPTER org.bluez.Adapter.RemoveDevice objpath:$BT_ADAPTER/dev_$BD_ADDR_XX

Here BT_ADAPTER is Blue adapter like: /org/bluez/1536/hci0
BD_ADDR_XX is Bluetooth address: XX_XX_XX_XX_XX_XX

Here I know about –system –print-reply options and all others options but how its works with source files I do not know.

So Anybody please can Explain me hows this command call and use functions from C source files.

Answer 1

You need to check out dbus document and there’s a long way to go.

http://www.freedesktop.org/wiki/IntroductionToDBus

What exactly do you want? Writing a dbus service or a client?

Must you write in C, because python would be a far better choice.
http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html

============================

First, a dbus service connects to dbus-daemon and ask for a service address(in your case org.bluez).
Then it registers different interface at different object paths, each interface contains some method calls/signals for users to use.

In your case:

• Dbus daemon process(dbus-daemon –system) is started.

• Bluez daemon process started and ask dbus-daemon for “org.bluez” service address

• Bluez daemon process register some interfaces at /org/bluez/{process pid}/{bluetooth controller name} (check bluez source code, in doc directory)

• When you call dbus-send command, the command line tool will connect to dbus-daemon, sending the service address(-dest), object path(/org/bluez/1536/hci0), interface name, the method you call(
  org.bluez.Adapter.RemoveDevice) and parameters.

• Dbus-daemon resend it to bluez

============================

Dbus daemon doesn’t get service address or method calls.
It’s you or client process who tells it the service address and method-call names.

DBus daemon will then send target service process a data packet contains obj-path, interface/method name and parameters in its own format(through a unix local socket file).

Target service process then unpacks the packet, get the object-path, interface and etc. , decide what it should do. That’s not automatically done and you need to write your own code to handle it(method dispatch or so), or use some library like dbus-glib/gdbus.

============================

I checked source code of Bluez-4.98. It uses gdbus for method dispatch.

Take “CreateDevice” for example.

in src/adapter.c, there’s such a struct

static GDBusMethodTable adapter_methods[] = {
{ "GetProperties",  "", "a{sv}",get_properties      },
{ "SetProperty",    "sv",   "", set_property,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "RequestSession", "", "", request_session,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "ReleaseSession", "", "", release_session     },
{ "StartDiscovery", "", "", adapter_start_discovery },
{ "StopDiscovery",  "", "", adapter_stop_discovery,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "ListDevices",    "", "ao",   list_devices,
                    G_DBUS_METHOD_FLAG_DEPRECATED},
{ "CreateDevice",   "s",    "o",    create_device,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "CreatePairedDevice", "sos",  "o",    create_paired_device,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "CancelDeviceCreation","s",   "", cancel_device_creation,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "RemoveDevice",   "o",    "", remove_device,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "FindDevice",     "s",    "o",    find_device     },
{ "RegisterAgent",  "os",   "", register_agent      },
{ "UnregisterAgent",    "o",    "", unregister_agent    },
{ }
};

which means CreateDevice Method call will eventually calls create_device function.

And in line 2418

    if (!g_dbus_register_interface(conn, path, ADAPTER_INTERFACE,
                adapter_methods, adapter_signals, NULL,
                adapter, adapter_free)) {
    error("Adapter interface init failed on path %s", path);
    adapter_free(adapter);
    return NULL;
}

you register the interface ADAPTER_INTERFACE(“org.bluez.Adapter”) with all its methods and signals.

Then all the underlying dbus event monitor and method dispatch will be handled by gdbus(after init dbus connection and event handling in src/main.c). When some client calls org.bluez.Adapter.CreateDevice, it eventually get into function create_device at src/adapter.c line 1468.

static DBusMessage *create_device(DBusConnection *conn,
                DBusMessage *msg, void *data)
{
struct btd_adapter *adapter = data;
struct btd_device *device;
const gchar *address;
DBusMessage *reply;
int err;

if (dbus_message_get_args(msg, NULL, DBUS_TYPE_STRING, &address,
                    DBUS_TYPE_INVALID) == FALSE)
    return btd_error_invalid_args(msg);

if (check_address(address) < 0)
    return btd_error_invalid_args(msg);

if (!adapter->up)
    return btd_error_not_ready(msg);

if (adapter_find_device(adapter, address))
    return btd_error_already_exists(msg);

DBG("%s", address);
......

I’m not familiar with gdbus and if you want to dig deeper I suggest you to check the official website: http://developer.gnome.org/gio/stable/gdbus-convenience.html

============================

lol

Then you just need to check out ‘test’ directory of bluez source code.

There are both python and C examples.

Also, bluez dbus interface changed a lot from 3.XX to 4.XX, so check out the right version.