Am 06.05.2010 17:03, schrieb Johan Hedberg:
BlueZ will (or at least should) set the name for the adapter as follows: 1. If there's a name in /var/lib/bluetooth/... use that 2. Else if there's a name in main.conf use that 3. If all else fails set the name to "BlueZ"
Hm, IIRC it was set to $(hostname)-$(hci-id) last time I established a connection.
So I fail to see why this patch is needed at all. It sounds like there's something else wrong in the initialization process which makes the initialzation fail if the adapter contains some invalid default name (we shouldn't as far as I see be trying to read the name at all from the adapter before we've written it ourselves from the host side). I.e. I suspect the patch might be just working around the real issue instead of fixing it.
Yes, obviously Bluez fails to set a reasonable device name if the initial device name isn't already valid. However, I believe Bluez shouldn't necessarily be expected to handle invalid device names, as they clearly violate the specs. Instead, if Bluez detects an invalid name, it should convert it into a valid name as soon in the initialization process as possible. This sounds just naturally to me and is exactly what my patch does.
Cheers, Fabian -- 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
