* Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> [2011-06-09 21:38:22 +0900]: > Hi Marcel, > > On Thu, Jun 9, 2011 at 7:24 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > > Hi Waldemar, > > > >> The method is called if min. 16 bytes pincode is mendatory > >> to authenticate connection. > >> > >> In practice this will be called only with mgmtops switched on. Hciops > >> don't support secure pin code so far. > >> --- > >> doc/agent-api.txt | 11 +++++++++++ > >> 1 files changed, 11 insertions(+), 0 deletions(-) > >> > >> diff --git a/doc/agent-api.txt b/doc/agent-api.txt > >> index 9ab2063..b1cb354 100644 > >> --- a/doc/agent-api.txt > >> +++ b/doc/agent-api.txt > >> @@ -31,6 +31,17 @@ Methods void Release() > >> Possible errors: org.bluez.Error.Rejected > >> org.bluez.Error.Canceled > >> > >> + string RequestSecurePinCode(object device) > >> + > >> + This method gets called when the service daemon > >> + needs to get the secure passkey for an authentication. > >> + > >> + The return value should be a string of 16 characters > >> + length. The string can be alphanumeric. > >> + > >> + Possible errors: org.bluez.Error.Rejected > >> + org.bluez.Error.Canceled > >> + > > > > I do not like this since it is really legacy stuff and makes since > > really complicated. And now we are making big efforts to support this > > and that is bad. Since Simple Pairing solved this nicely for us. > > > > However I need to talk with Johan about this and figure something out. > > We are getting closer to 4.100, maybe it is time to start doing the > transition to 5.x, which means we could start thinking on fixing the > current API without worrying if it breaks or not. How about that? I'm with Luiz here. Unless we want the the crazy idea of have a development branch we should start breaking the API someday. How about now? And if we are really going for it a roadmap made public somewhere would be good. :) Gustavo -- 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