Heya, I've had a few thoughts about some use cases that currently cause problems (or would cause problems) with bluetoothd. 1) Printer pairing and setup The cups backend will create a non-paired device to detect whether devices with a printer class have supported services. The problem is that the CUPS backend will not remove the device once done, and the device will now appear in the list of known devices for bluetoothd. In terms of UIs, that means it shows up in the wizard (as it's not paired or setup), but not in the properties, thus can't be removed from the list. It would be nice to receive this data and have it cached client-side instead, like we do for discovery results. 2) Adapter provided devices Although we don't currently have code for that, it would be nice to handle the possibility. Some adapters provide a way to store link keys, and other data pertaining to input devices. The problem with setting those up is that the pairing will be permanent on the bluetoothd side. We should make sure the associations go away when the adapter goes down. Opinions? -- 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
