Hi Mike, On Wed, May 16, 2012 at 5:28 PM, Mike <puffy.taco@xxxxxxxxx> wrote: >> 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. > > The reason this is per model is that there is no spec on this and > hence it will be very implementation specific. If you are a desktop > hooked up to AC, you really don't care, but an embedded device will > need to implement something that meets its battery constraints. As > well, the efforts of bluez will be fruitless if the rest of the system > goes into suspend. In my case, my device goes to suspend as soon as > possible (and wakes if there is BT UART traffic). Hence, timers that > implement re-connection need to let the system know when the next > attempt will occur. Yes, but that can be implemented in audio.conf, so you can enter the number of retries and the interval between them that you want per platform, but I think 99% will just pick the default. Btw, you need to elaborate a bit more about your requirements, this work is focuses on IVI system where I don't expect the system to go into suspend that often. -- Luiz Augusto von Dentz -- 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
