Hi Mikel,
On Thu, May 23, 2013 at 11:54 PM, Mikel Astiz <mikel.astiz.oss@xxxxxxxxx> wrote:
> 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.
It is implemented in profiles/audio/device.c:device_avdtp_cb so it
should connect just fine in BlueZ against BlueZ scenario, it might
actually connect both sink and source.
--
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
