Hi Lucas,
On Wed, Sep 21, 2011 at 3:15 PM, Lucas De Marchi
<lucas.demarchi@xxxxxxxxxxxxxx> wrote:
> Hi Luis,
>
> On Wed, Sep 21, 2011 at 7:33 AM, Luiz Augusto von Dentz
> <luiz.dentz@xxxxxxxxx> wrote:
>> Hi Lucas,
>>
>> On Tue, Sep 20, 2011 at 9:31 PM, Lucas De Marchi
>> <lucas.demarchi@xxxxxxxxxxxxxx> wrote:
>>> ---
>>> audio/avctp.c | 2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/audio/avctp.c b/audio/avctp.c
>>> index e9b8e40..59fbed9 100644
>>> --- a/audio/avctp.c
>>> +++ b/audio/avctp.c
>>> @@ -155,6 +155,8 @@ static struct {
>>> { "BACKWARD", BACKWARD_OP, KEY_PREVIOUSSONG },
>>> { "REWIND", REWIND_OP, KEY_REWIND },
>>> { "FAST FORWARD", FAST_FORWARD_OP, KEY_FASTFORWARD },
>>> + { "VOLUME UP", VOL_UP_OP, KEY_VOLUMEUP },
>>> + { "VOLUME DOWN", VOL_DOWN_OP, KEY_VOLUMEDOWN },
>>> { NULL }
>>> };
>>
>> Have a look at the SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES
>> white paper:
>>
>> Recommendation 16:
>> If volume is changed on the RD, the RD should not send an AVRCP volume
>> command to the MP device.
>> Motivation 16:
>> Sending an AVRCP volume command to the MP may cause the MP to send
>> again an AVRCP volume
>> command to the RD device which could lead to an endless loop of AVRCP
>> volume commands.
>>
>
> Humnn... ok
>
>> We don't support those because it is very likely that it would create
>> the endless loop with those devices as we can only act as a MP we just
>> ignore, for RD this would probably be useful so the handling of the
>> keys need to take into account the role of the device.
>
> You mean, it's simply a matter of checking we are only TG before
> calling send_key?
Yep, or maybe have a different table for TG and CT.
--
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
