On Sat, Jan 21, 2012 at 8:36 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > I am a little bit concerned here since we are using legacy pairing. I > have not looked at the implementation, but I think we should only reply > with the random PIN code to the controller once this method got returned > with a positive reply. > > And in addition I prefer if we handle a negative/reject or non reply at > all to make this work with older agents as well. That way the core can > fallback to just RequestPinCode if this gets rejected. > That's a good idea. I'll change that in the patch. > In addition to that, I am not sure we can actually nicely emulate the > "entered" feature from SSP. I know you mentioned that Apple does > something like this, but it is nowhere near a standard. So do we really > wanna call this method multiple times or just accept that it will be > only called once and if it gets rejected, we fall back to requesting the > PIN code. > My intent was that it will only ever get called once in contrast to DisplayPasskey which can be called multiple times - and that's one good reason the UI would want different methods here, if it gets DisplayPinCode it knows it's never getting typing notification. I'll adjust the docs, I think that's a Copy & Paste error. I looked into the Apple hack, but it's so randomly specific and evil, I decided to ignore it. Scott -- 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
