[PATCHv1 0/2] Introduce default adapter property

[PATCHv1 0/2] Introduce default adapter property

[Timo Mueller]

From: Timo Mueller <timo.mueller@bmw-carit.de>

Hi,

the information about the default adapter is currently not available
through the D-Bus API of BlueZ. But as plugins can use this
information to choose the adapter they act upon it would be helpful
for users to be able to retrieve this information as well.

For example the neard plugin uses this information to decide for which
adapter oob data is generated. Users could use the same information to
power the adapter before actually sending the oob data.

Best regards,
Timo

Timo Mueller (2):
  doc: Introduce default adapter property
  adapter: Introduce default adapter property

 doc/adapter-api.txt |  9 +++++++++
 src/adapter.c       | 15 +++++++++++++++
 2 files changed, 24 insertions(+)

-- 
1.8.3.1

[PATCHv1 1/2] doc: Introduce default adapter property

[Timo Mueller]

From: Timo Mueller <timo.mueller@bmw-carit.de>

Some plugins choose a default adapter when no specific adapter has
been selected. This information was not exposed in the adapters D-Bus
properties.

With the new property users can find out which adapter is used if no
adapter has been specified. This allows them to change the properties
of the adapter beforehand, e.g. powering the adapter before oob data
is sent.
---
 doc/adapter-api.txt | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
index 74d235a..9990432 100644
--- a/doc/adapter-api.txt
+++ b/doc/adapter-api.txt
@@ -153,3 +153,12 @@ Properties	string Address [readonly]
 
 			Local Device ID information in modalias format
 			used by the kernel and udev.
+
+		boolean Default [readonly]
+
+			Indicates that the adapter is the default adapter. The
+			default adapter is used when multiple adapters exist and
+			no specific adapter has been selected.
+
+			In case the default adapter is removed, one of the
+			remaining adapters will become the new default adapter.
-- 
1.8.3.1

[PATCHv1 2/2] adapter: Introduce default adapter property

[Timo Mueller]

From: Timo Mueller <timo.mueller@bmw-carit.de>

Some plugins choose a default adapter when no specific adapter has
been selected. This information was not exposed in the adapters D-Bus
properties.

With the new property users can find out which adapter is used if no
adapter has been specified. This allows them to change the properties
of the adapter beforehand, e.g. powering the adapter before oob data
is sent.
---
 src/adapter.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/src/adapter.c b/src/adapter.c
index 41f7bd6..46174d6 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2126,6 +2126,17 @@ static gboolean property_get_modalias(const GDBusPropertyTable *property,
 	return TRUE;
 }
 
+static gboolean property_get_default(const GDBusPropertyTable *property,
+					DBusMessageIter *iter, void *user_data)
+{
+	struct btd_adapter *adapter = user_data;
+	dbus_bool_t is_default = btd_adapter_is_default(adapter);
+
+	dbus_message_iter_append_basic(iter, DBUS_TYPE_BOOLEAN, &is_default);
+
+	return TRUE;
+}
+
 static int device_path_cmp(gconstpointer a, gconstpointer b)
 {
 	const struct btd_device *device = a;
@@ -2193,6 +2204,7 @@ static const GDBusPropertyTable adapter_properties[] = {
 	{ "UUIDs", "as", property_get_uuids },
 	{ "Modalias", "s", property_get_modalias, NULL,
 					property_exists_modalias },
+	{ "Default", "b", property_get_default },
 	{ }
 };
 
@@ -5673,6 +5685,9 @@ static int adapter_unregister(struct btd_adapter *adapter)
 			new_default = adapters->data;
 
 		new_default->is_default = true;
+
+		g_dbus_emit_property_changed(dbus_conn, new_default->path,
+				ADAPTER_INTERFACE, "Default");
 	}
 
 	adapter_list = g_list_remove(adapter_list, adapter);
-- 
1.8.3.1

Re: [PATCHv1 0/2] Introduce default adapter property

[Szymon Janc]

Hi Timo,

> From: Timo Mueller <timo.mueller@bmw-carit.de>
> 
> Hi,
> 
> the information about the default adapter is currently not available
> through the D-Bus API of BlueZ. But as plugins can use this
> information to choose the adapter they act upon it would be helpful
> for users to be able to retrieve this information as well.
>
> For example the neard plugin uses this information to decide for which
> adapter oob data is generated. Users could use the same information to
> power the adapter before actually sending the oob data.

I think this property is bluetoothd internal detail and should not be needed
to be exported to user. If reason for this is scenario where multiple BT and
NFC adapters are present and you need to match them in pairs, then proper
solution would probably require extending neard agent interface. Neard plugin
could be also made 'smarter' about multiple adapters eg. try to choose other
controller if default one is not powered etc. Regarding changing power state
of bt controller, I think this could be done by neard plugin itself (possible
based on some static configuration or even runtime dbus setting...). It is on
my 'TODO when have some spare time' list :)

It would be good if you could outline usecases you are trying to address with
this change.

-- 
BR
Szymon Janc

Re: [PATCHv1 0/2] Introduce default adapter property

[Timo Müller]

Hi Szymon,

Szymon Janc wrote, On 04.12.2013 09:32:
> Hi Timo,
>
>> From: Timo Mueller <timo.mueller@bmw-carit.de>
>>
>> Hi,
>>
>> the information about the default adapter is currently not available
>> through the D-Bus API of BlueZ. But as plugins can use this
>> information to choose the adapter they act upon it would be helpful
>> for users to be able to retrieve this information as well.
>>
>> For example the neard plugin uses this information to decide for which
>> adapter oob data is generated. Users could use the same information to
>> power the adapter before actually sending the oob data.
>
> I think this property is bluetoothd internal detail and should not be needed
> to be exported to user.

Alright. Is the default information needed at all? I might be missing 
something but the default information seems to only be used by the 
hostname, sixaxis and neard plugins. I don't know about sixaxis, but the 
hostname plugin could also do without this information. If the neard 
plugin would handle multiple adapters, then the default adapter property 
could be dropped completely.

> If reason for this is scenario where multiple BT and
> NFC adapters are present and you need to match them in pairs, then proper
> solution would probably require extending neard agent interface. Neard plugin
> could be also made 'smarter' about multiple adapters eg. try to choose other
> controller if default one is not powered etc. Regarding changing power state
> of bt controller, I think this could be done by neard plugin itself (possible
> based on some static configuration or even runtime dbus setting...). It is on
> my 'TODO when have some spare time' list :)

Automatic powering, if enabled by 'configuration', sounds good to me. 
Regarding the adapter selection, how about a runtime dbus setting to set 
the adapter that the neard plugin is using? It could then behave as 
bluetoothctl does right now. Choosing the first adapter on start and use 
the selected adapter afterwards.

>
> It would be good if you could outline usecases you are trying to address with
> this change.

The use case was to only send the oob data when the device has not yet 
been paired with the adapter that is used. On Android this wouldn't 
interrupt the regular Android Beam behaviour (when sending an URL from 
the browser for example). Of course this requires a unique ID that could 
be requested via NFC and mapped to a BD_ADDR. Unfortunately this ID, as 
just discussed in IRC, does not exist. So, admittedly this use case is 
broken.

Best regards,
Timo