On Tue, Nov 19, 2013 at 5:29 AM, Bastien Nocera <hadess@xxxxxxxxxx> wrote: > 6) I have a "TomTom Remote" that shows up as a keyboard and uses "0000" > as its PIN. The problem is that, as per the code in autopair.c we'll > first show a random pincode then quickly fall back to using "0000": >> /* For keyboards rejecting the first random code >> * in less than 500ms, try a fixed code. */ > > How does ChromeOS present this? Does it wait half a second before > showing the pincode to enter? Because flashing an unusable pincode on > the screen before succeeding pairing is pretty rubbish in my opinion... > This is at least slightly better than OS X, which would display the random PIN, and then fail pairing - require you to try again, find the "Advanced" button, set it to one of three or four user-nonsensical options, and then enter 0000 I'm not saying we can't do better, of course, I'm just saying that we can do worse :p A half-second flash of a 6-digit PIN before falling back to a four-digit one at least works in all of the corner cases - including this one. We actually collect logs via metrics of the devices this happens for, right now we only know of one keyboard that this gets triggered for (a Motorola Android Keyboard that's no longer on sale) - the TomTom Remote makes two - I guess nobody's paired a Chromebook with one yet. I'm way open to ideas for improving the experience here, just as long as we keep the "works in the common and corner cases" part ;-) Scott -- Scott James Remnant | Chrome OS Systems | keybuk@xxxxxxxxxx | Google -- 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
