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. > > 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 -- 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
