From: Lucas De Marchi <lucas.demarchi@profusion.mobi>
To: "Kumar, Sunil A" <sunil.a.kumar@intel.com>
Cc: "linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>,
"Nair, Rashmi G" <rashmi.g.nair@intel.com>,
"Khanzode, Prashant" <prashant.khanzode@intel.com>,
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Subject: Re: Response to AVRCP Passthrough Commands.
Date: Tue, 28 Feb 2012 10:05:05 -0300 [thread overview]
Message-ID: <20120228130505.GA4170@vader> (raw)
In-Reply-To: <8948CE8A2D1716449B389D5F68D4A30E02048F@FMSMSX108.amr.corp.intel.com>
Hi Kumar,
* Kumar, Sunil A <sunil.a.kumar@intel.com> [2012-02-28 09:47:20 +0000]:
> Hi,
>
> The passthrough command handler - handle_panel_passthrough - ends up responding with response code - ACCEPTED - in below mentioned cases whereas expected response code as per specification is different. Please find the cases and expected response code mentioned below. The document referred for specifying the expected response code is " AV/C Digital Interface Command Set General Specification Version 4.2" which is referred to in AVRCP specification.
>
> 1- Command is supported by Bluez but the Media App doesn't support the same e.g. "FAST FORWARD" is supported by Bluez means present in " key_map" table but Android Froyo Media App doesn't support the same.
> - As per point 5 of section "6.3 AV/C response rules" in above specified document, the expected response code is - NOT IMPLEMENTED. Here is the text for point 5 from document: " If the fields marked in the ck column of the command frame include the unsupported value, the target shall return a NOT IMPLEMENTED response."
As per current implementation, the application on top of BlueZ is
supposed to implement that commands.
>
> 2- Command is supported by Bluez and the Media App. But, command can't be executed at this time because of an error e.g. "PLAY" is supported by Bluez and Media App but playback is not possible when Media App receives this command because of an error.
> - As per point 6 of section "6.3 AV/C response rules" in above specified document, the expected response code is - REJECTED. Here is the text for point 6 from document: " If the target can not execute the CONTROL, STATUS, or NOTIFY command, and a NOT IMPLEMENTED response would not be required for the command, the target shall return a REJECTED response."
>
> 3- Command is not supported by Bluez itself, so doesn't matter whether Media App supports it or not. e.g. " key_map" table is modified to remove "FAST FORWARD".
> - As per point 5 of section "6.3 AV/C response rules" in above specified document, the expected response code is - NOT IMPLEMENTED. Here is the text for point 5 from document: " If the fields marked in the ck column of the command frame include the unsupported value, the target shall return a NOT IMPLEMENTED response."
In this latter case it seems a bug indeed. Does the patch bellow fix the
issue for you?
>
> Could someone help answering following queries:
> - What is the reason for Bluez to respond with response code - ACCEPTED - in these cases? Is this well thought of or just an issue?
The last one is probably a bug. Could you test the patch and see if it
passes all related tests in PTS?
> - If this is not an issue, it shall be great help if you can provide the reasons for current implementation.
We use uinput here to send the commands. uinput is just like a keyboard
pressing that "media keys". The problem here is that there's no feedback
from the application if the command was accepted or not.
Luiz, what do you think?
> - If this is an issue, is there already a plan to correct it? We need to establish the mechanism wherein Bluez waits for response from client (Media App) whenever necessary (case 1 and 2 mentioned above) before sending response.
Unless we stop using uinput to use another mechanism to send the
commands to application, I don't see an easy way to fix it.
Regards,
Lucas De Marchi
---
Subject: AVCTP: return not-implemented for unknown passthrough command
diff --git a/audio/avctp.c b/audio/avctp.c
index 5bd5db1..e36353d 100644
--- a/audio/avctp.c
+++ b/audio/avctp.c
@@ -235,9 +235,12 @@ static size_t handle_panel_passthrough(struct avctp *session,
break;
}
- if (key_map[i].name == NULL)
+ if (key_map[i].name == NULL) {
DBG("AV/C: unknown button 0x%02X %s",
operands[0] & 0x7F, status);
+ *code = AVC_CTYPE_NOT_IMPLEMENTED;
+ return 0;
+ }
done:
*code = AVC_CTYPE_ACCEPTED;
next prev parent reply other threads:[~2012-02-28 13:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 9:47 Response to AVRCP Passthrough Commands Kumar, Sunil A
2012-02-28 13:05 ` Lucas De Marchi [this message]
2012-02-28 13:52 ` Luiz Augusto von Dentz
2012-02-28 14:20 ` [PATCH BlueZ] AVCTP: return not-implemented for unknown passthrough Lucas De Marchi
2012-02-28 15:40 ` Malovany, Ram
2012-02-28 15:54 ` Lucas De Marchi
2012-04-02 14:46 ` Johan Hedberg
2012-02-29 12:20 ` Response to AVRCP Passthrough Commands Kumar, Sunil A
2012-02-29 13:23 ` Luiz Augusto von Dentz
2012-03-01 9:53 ` Kumar, Sunil A
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120228130505.GA4170@vader \
--to=lucas.demarchi@profusion.mobi \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.von.dentz@intel.com \
--cc=prashant.khanzode@intel.com \
--cc=rashmi.g.nair@intel.com \
--cc=sunil.a.kumar@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).