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?
> 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:
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.
In gnome-bluetooth, we have special-casing for keyboards with a
different PIN display, and instructions for users to press "Enter" after
entering the PIN. We use a random 6-digit number for every pairing that
doesn't use a hard-coded PIN.
>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?
Cheers
--
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
