Re: [RFC BlueZ v0 0/5] ACL disconnect reason

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Luiz,

On Mon, May 14, 2012 at 7:00 PM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi Mikel,
>
> On Mon, May 14, 2012 at 6:32 PM, Mikel Astiz <mikel.astiz.oss@xxxxxxxxx> wrote:
>> From: Mikel Astiz <mikel.astiz@xxxxxxxxxxxx>
>>
>> Some use-cases require distinguishing the reason behind an ACL disconnection. Particularly, IVI use-cases regarding HFP and A2DP need to know if a disconnection was due to a timeout, in order to know which should be the reconnection strategy.
>
> Afaik there is only one use case which is link loss aka out of range,
> because of that carkit/headset policy is normally clean disconnect do
> not reconnect, non-clean disconnect do reconnect.

Right, with a few exceptions including clean disconnection during
head-unit shutdown.

>>
>> This information needs to be exposed to some component implementing the specific policy of each application. Typically neither BlueZ or oFono (in case of HFP) would be the case. This means the disconnect reason needs to be exposed in D-Bus.
>>
>> In this patch series the proposed approach is to add a signal in the device API, given that we already have some low-level disconnection-related API there. Another approach would be to support it in the specific HFP and A2DP interfaces.
>
> The disconnect reason might no be necessary, have you thought about
> implementing the reconnection logic directly in bluetoothd? This way
> we can test this without the UI, and we know when for example A2DP has
> disconnect without CLOSE command or things like that and afaik we can
> query the error from the socket.

The connection/reconnection policy is manufacturer and model-specific.
Therefore I find it difficult that we could include this inside
bluetoothd.

Having said that, I would be happy to review any proposal.

> Btw, none of this is useful without tuning the link supervision
> timeout because the current one used by BlueZ iirc is 20 seconds, far
> too big for being able to recover the audio.

That should definitely be tuned. However it's not always about
recovering audio, but knowing to which phone the car should connect.
With HFP there might be no audio and no voicecall during connection.

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


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux