Hi David, > Since only half of my binary-PIN patches got applied upstream, I want to start > a new discussion about binary PIN support. > > The thing is, the wiimote device (and as reported also some other > devices) requires > a BT-address (which may contain \0) as bluetooth pin. Current dbus > design forbids > strings containing \0 (used as string terminator) and so an agent cannot send > binary PINs to bluetoothd as return value of RequestPinCode(). > > The BT specs 3.0+ HS (Volume 3, Part C, 3.2.3 Bluetooth Passkey) say > the UI-input shall > be UTF-8 encoded and preferably use only the UFT-8 range 0x00-0x7F to > avoid multibyte > characters. There is also a recommendation for multi-byte characters. > Dbus uses utf-8 encoded strings so bluetoothd does not need to modify the > PIN, but current implementation restricts/violates the specs because > it disallows 0x00 as > valid PIN character. > > Since the idea with hex-encoding binary PINs and prefixing them with > '$' did not get > accepted, I have some other ideas for this: > > 1: Use hard coded PINs for those devices. That is, use VID/PID > detection during pairing > and send hardcoded PIN (or based on src/dst address). Problem: VID/PID > information is > not available during pairing or may not be available, yet. Some > devices may even reject > SDP requests when not paired (as mentioned on IRC). Maybe someone has > an idea how to > get this working. if I remember this correctly, then Wiimote does support DeviceID profile and thus reports proper VID/PID combinations. So just create some auto-pair support in bluetoothd (if needed via plugins) and just auto-pair them like we would do with Secure Simple Pairing anyway. There is really no need at all to involve the UI code and mess up the D-Bus API as it is. It was never designed for hardcoded PIN codes other then numbers and strings anyway. > 2: Extend DBus Agent API with a function RequestBinaryPinCode() which > works exactly > like RequestPinCode() but returns a bytearray (with length) instead of a string. > A dbus agent then needs to signal to bluetoothd that it provides this > method and bluetoothd > shall call RequestBinaryPinCode() instead of RequestPinCode(). > However, I couldn't figure out a proper way to signal this capability > to bluetoothd. > The agent could send some kind of EnabledBinaryPinSupport-Signal to > bluetoothd... No way ever. We had that problem when we initially had to support a fallback for the agent in 3.x series. Never ever again. > 3: Use some kind of encoding in the UTF-8 string as proposed with the > '$' character. > However, this might break old software. And how is that going to work out in reality. Same as $ is a valid character. So also a clear no. Go with 1) and try to just auto-pair the Wiimotes. That is the right approach and makes a lot sense. It might be the one with the most work on getting the DeviceID support integrated properly, but it is the right way forward here. Regards Marcel -- 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
