Hi Luis,
On Fri, May 24, 2013 at 2:21 AM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi,
>
> On Thu, May 23, 2013 at 11:58 AM, Luiz Augusto von Dentz
> <luiz.dentz@xxxxxxxxx> wrote:
>> From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx>
>>
>> By the time the profile is registered it is not really possible to
>> tell which role of AVRCP should be connected, currently this cause
>> a problem with headsets that normally are controllers/sink but since
>> it normally also has target record for features related to things like
>> volume control the target profile is also probed and as it currently
>> has the auto_connect set it would lead to the wrong profile to start
>> connecting.
>> ---
>> profiles/audio/manager.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/profiles/audio/manager.c b/profiles/audio/manager.c
>> index 15226e4..1518e5d 100644
>> --- a/profiles/audio/manager.c
>> +++ b/profiles/audio/manager.c
>> @@ -376,7 +376,6 @@ static struct btd_profile avrcp_target_profile = {
>> .device_probe = avrcp_probe,
>> .device_remove = audio_remove,
>>
>> - .auto_connect = true,
>> .connect = avrcp_target_connect,
>> .disconnect = avrcp_target_disconnect,
>>
>> --
>> 1.8.1.4
>
> This set is now pushed.
What I don't quite get is how exactly BlueZ would ever connect AVRCP.
Let's say both ends are BlueZ 5. Would we trigger the connection once
A2DP gets connected? I'm not seeing where such a policy is currently
implemented.
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
