On Wed, Sep 15, 2010 at 5:10 AM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > Hi Andrzej, > > On Wed, Sep 15, 2010, Andrzej Kaczmarek wrote: >> On behalf of ST-Ericsson SA, below is our proposal of API for out of band >> association model. To give you a bit more overview how this will be integrated >> into BlueZ: >> >> .RequestRemoteOobData should be called from hcid_dbus_request_io_cap to >> check if any data was exchange/retrieved from remote device. Returned data >> will be stored (if any) and used to reply with proper IO capabilities as well >> as to to return retrieved data. This will involve some changes in flow from >> io_capa_request onwards. >> >> Please let me know if you have any comments. Implementation will follow. > > I'd prefer to do this completely internally in bluetoothd through a > plugin. Do you see any reasons why not to do it that way? We still need > some UI to call CreatePairedDevice but a plugin that knows about local > platform specific OOB mechanisms (e.g. NFC) could provide the core > daemon with enough info to set the IO capabilities correctly and provide > the necessary OOB values. > > Johan > -- Hi Andrzej, I did some testing with OOB last year. See my branch git://git.infradead.org/users/cktakahasi/bluez.git oob-displayyesno About the API changes. MAYBE, Hash and Randomizer could be only adapter properties. For the remote Hash and Randomizer still not clear to me what is the best way to allow external apps to set those values, but in my opinion BlueZ should not know the OOB mechanism, only the capability is enough. Regards, Claudio -- 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
