Re: [RFC] adapter: Add CreateDevice method
From: Marcel Holtmann <marcel@holtmann.org>
Date: 2018-01-18 09:40:04
Hi Szymon,
This allows to create Device1 object without discovery. This is needed for some of qualification tests where there is no general discovery upfront and we need to do connection to device with provided address. Another usecase is for scenario where scanning happen on one controller but connection handling on another. Implementation wide this results in new temporary device object being created that if unused will be cleanup just like it would be if found during discovery session.
so what are the rules around the cleanup? On next discovery it is gone again, then that might needs to be mentioned.
quoted hunk ↗ jump to hunk
This patch implements bare minimum properties needed for connection - address and address type. If needed eg. for non-NFC based OOB it could be extended with more options. --- doc/adapter-api.txt | 29 ++++++++++++++++ src/adapter.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 125 insertions(+)diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt index 0533b674a..c8f3ce26e 100644 --- a/doc/adapter-api.txt +++ b/doc/adapter-api.txt@@ -145,6 +145,35 @@ Methods void StartDiscovery()Possible errors: None + void CreateDevice(dict properties) [experimental] + + Creates new temporary device with defined properties.
Why is this not returning the device object path that gets created? Seems a waste time cycles to wait for a device showing up later.
+ + Parameters that may be set in the filter dictionary + include the following: + + string Address + + The Bluetooth device address of the remote + device. This parameter is mandatory. + + string AddressType + + The Bluetooth device Address Type. This is + address type that should be used for initial + connection. If this parameter is not present + BR/EDR device is created. + + Possible values: + "public" - Public address + "random" - Random address + + Possible errors: org.bluez.Error.InvalidArguments + org.bluez.Error.AlreadyExists + org.bluez.Error.NotSupported + org.bluez.Error.NotReady + org.bluez.Error.Failed +
Now what I wonder is that in case of LE, this should actually trigger a quick scan for that device so that you get advertising data and other information about the device. We are missing a kernel API for such a targeted case and that might need fixing as well. In case of BR/EDR, this might should trigger a connection and SDP discovery. Otherwise this is not an API and just a hack to create a device path object. So you are essentially just doing an “InjectDevice” instead of anything real. That said, using a DiscoverDevice() method name might be more accurate. Regards Marcel