From: Timo Mueller <[email protected]>
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
Hi Szymon,
Szymon Janc wrote, On 04.12.2013 09:32:
> Hi Timo,
>
>> From: Timo Mueller <[email protected]>
>>
>> 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
Hi Timo,
> From: Timo Mueller <[email protected]>
>
> 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
From: Timo Mueller <[email protected]>
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
From: Timo Mueller <[email protected]>
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