Hi Szymon,
Szymon Janc wrote, On 04.12.2013 09:32:
Hi Timo,
From: Timo Mueller <timo.mueller@xxxxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
