Hi Luiz, > So if it is recommended by the white paper I don't see why it should > be manufacture/model specific, note that only the number of attempts > to re-connect is implementation dependent, but we can have an option > in audio.conf where the platform configure the number of attempts and > perhaps the interval between them if we cannot find a good default. We might be discussing about different reconnection policies. You are focusing on the short-term reconnection strategy, where several attempts can be made in order to reconnect as soon as possible and improve user experience. For this I agree BlueZ could handle the case. However this RFC was motivated by the overall connection policy (perhaps "reconnect" was not the right term here). A use-case can be a car with a paired phone and HFP is connected. The user leaves the car while still turned on (someone else could be driving) and a timeout would eventually occur. Next morning, when the user enters the car, his phone should be connected. On the contrary, if the user disconnected the HFP from the phone, this reconnection should not be triggered. >From my point of view, the exact policy of which devices, how many of them, using which priorities, which profiles, etc. is manufacturer and model-specific. I don't think these policies should be embedded in BlueZ. After all, we already have a nice D-Bus API to handle these use-cases, and only the disconnect reason seems to be missing. Cheers, Mikel -- 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
