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. >> >> Those are same rules so it will be gone only if it is left temporary (ie >> Connect() or Pair() was never called). I'll document that. >> >>>> 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. >> >> I was thinking about that too. I'll make it return object path. >> >>>> + >>>> + 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. >> >> Maybe we should just implicitly make it connect to device? That would keep >> things simple and wouldn't require any additional kernel work. If connect >> failed we remove device. > > that would work as well and since for LE we always scan first, we get the advertising data as well. Now the question is if just call it DiscoverDevice instead. I am reluctant to call it ConnectDevice since that is a bit overlapping with Device.Connect. And CreateDevice is bad as well since this is temporary connection in most cases. actually just trying to connect really only works for BR/EDR. With LE that would not help us with non-connectable devices. So I am leaning towards DiscoverDevice that does BR/EDR connect and SDP. And on LE it does an active scan for that specific device. No connection attempt required on LE. 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
