On Mon, Jan 23, 2012 at 4:14 AM, Bastien Nocera <hadess@xxxxxxxxxx> wrote: > On Fri, 2012-01-20 at 15:05 -0800, Scott James Remnant wrote: > > Here's a first pass of handling the HID profile recommendation for > > pairing keyboards inside bluetoothd, rather than expecting the UI > > Agent to deal with it. > > > > This requires agents implement a new DisplayPinCode method, since > > the existing DisplayPasskey method expects a numeric and PIN Codes > > are UTF-8 strings. > > When have you seen non-numerical PINs being used? > Two devices on my desk right now use a UTF-8 text string as the fixed PIN, and three use their Bluetooth address in binary form. That being said, none of them are covered by this patch. > > As well as general type-stricty-ness, the method allows the UI to > > distinguish between a Bluetooth 2.0 keyboard (ie. all of them) and > > future Bluetooth 2.1 keyboards implementing SSP (for which there may > > be keypress notification). UIs might want to display them slightly > > differently (OS X does, and UI developers tend to just copy that). > > > > That said, the PINs generated here are 6-digit 0-padded numerics > > since that's probably less confusing for users and there are > > Bluetooth numeric keypads out there that can't do non-numerics. > > Less confusing for users? Unless the UI is broken and doesn't follow the > documentation, they should be showing a zero-padded 6 digit number: Which is why a zero-padded 6 digit number is generated as the PIN here, for consistency with a Bluetooth 2.1 Passkey. > void DisplayPasskey(object device, uint32 passkey, uint8 entered) > [...] > Note that the passkey will always be a 6-digit number, > so the display should be zero-padded at the start if > the value contains less than 6 digits. > > I fail to see what the benefit of those new functions is, apart from > hypothetical correctness. > Firstly this indicates that a Bluetooth 2.0 keyboard is being paired using a PIN, rather than a Bluetooth 2.1 Secure Simple Pairing device with a passkey. A major UI difference is that the 2.0 device won't have typing notification, and the UI designer might want to respond slightly differently to this case. > From what I can see, the whole operation can be implemented from > user-space without a problem. > > Care to explain what benefits this has for user-space? > Marcel asked me to implement this in bluetoothd, so everyone can benefit equally rather than four different bluetooth agents all handling auto-pairing slightly differently. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? -- 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
