Hi Luiz, >> 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. > > Disconnect reason doesn't solve all the problems, specially in multi > profile case when just one profile has disconnected but the link is > still active. Besides that I would be very interested to know why each > model has to have a different behavior this goes completely in > opposite of having a common stack with a well defined behavior. The ACL disconnect case might not cover all use-cases, but it does cover the most important one: the link loss. Exposing if a specific profile has disconnected cleanly is IMO way too much. > When you say you want this specific per model all I can think of is > how much IOP problems it can cause and in the end I see no benefit for > the user, we should aim for re-connect as quick as possible and that > should be enough for any model. Let's not make a big deal out of this. We are talking about small differences in policies, such as how many devices and profiles are connected, and according to which priorities. I do agree that anything that could cause IOP problems should be handled inside BlueZ. And the immediate reconnection try after a link loss does sound an example of this kind. So I would be fine if BlueZ internally handles this, but I still think we need to expose this in D-Bus somehow. One alternative to my original proposal -adding a Disconnected(uint8 reason) signal- would be to use the state property of each interface (HFP, A2DP). If the autoreconnect policy is enabled, a link loss would generate the transition "connected"->"connecting" (or "playing"->"connecting"). Never setting the state to "disconnected" would effectively be equivalent as reporting a link loss. Any thoughts on this second approach? Any other proposal? 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
