Return-Path: MIME-Version: 1.0 In-Reply-To: References: <1337009584-17181-1-git-send-email-mikel.astiz.oss@gmail.com> Date: Thu, 17 May 2012 16:41:46 +0300 Message-ID: Subject: Re: [RFC BlueZ v0 0/5] ACL disconnect reason From: Luiz Augusto von Dentz To: Mike Cc: Mikel Astiz , linux-bluetooth@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Mike, On Wed, May 16, 2012 at 5:28 PM, Mike 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