Closed
Bug 827204
Opened 12 years ago
Closed 12 years ago
[Bluetooth][Hfp] Activate/Deactivate "indicator events reporting" (AT+CMER)
Categories
(Core :: DOM: Device Interfaces, defect)
Tracking
()
People
(Reporter: gyeh, Assigned: gyeh)
References
Details
Attachments
(2 files, 2 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
When we receive AT command AT+CMER=0, no indicator events should be reported back to headset; when receiving AT+CMER=1, indicator events like signal and callsetup should be reported.
Please see 4.2.1 "Service Level Connection Initialization" of HFP 1.5 for more detail.
Assignee | ||
Comment 1•12 years ago
|
||
Assignee: nobody → gyeh
Attachment #698543 -
Flags: review?(echou)
Comment 2•12 years ago
|
||
Comment on attachment 698543 [details] [diff] [review]
Patch 1(v1): Activate/Deactivate "indicator events reporting"
Review of attachment 698543 [details] [diff] [review]:
-----------------------------------------------------------------
Looks good. r+ after the question is answered.
::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +617,5 @@
> * Do nothing but respond with "OK".
> */
> + ParseAtCommand(msg, 8, atCommandValues);
> +
> + if (atCommandValues.Length() != 4) {
Question: How about checking if the length is "less and equal than 4" instead of "not equal to 4"? The spec says that AT+CMER may be longer than 4 arguments.
The format of AT+CMER is: AT+CMER=[<mode>[,<keyp>[,<disp>[,<ind> [,<bfr>]]]]]
Attachment #698543 -
Flags: review?(echou) → review+
Assignee | ||
Comment 3•12 years ago
|
||
Yes, the length checking shall be "<= 4" rather than "!= 4". Thanks.
Final patch with nits picked.
try:
https://tbpl.mozilla.org/?tree=Try&rev=084eea27bfca
https://tbpl.mozilla.org/?tree=Try&rev=5030c673f5d6
Attachment #698543 -
Attachment is obsolete: true
Assignee | ||
Comment 4•12 years ago
|
||
Comment 5•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Assignee | ||
Updated•12 years ago
|
Blocks: b2g-bluetooth-hfp
Updated•12 years ago
|
tracking-b2g18:
--- → ?
Updated•12 years ago
|
status-b2g18:
--- → affected
Comment 6•12 years ago
|
||
status-b2g18-v1.0.0:
--- → wontfix
status-b2g18-v1.0.1:
--- → wontfix
status-firefox20:
--- → wontfix
status-firefox21:
--- → fixed
Assignee | ||
Comment 7•12 years ago
|
||
This bug(and other 9 bugs) block Bluetooth certification. So, these bugs need to be marked as tef+ and landed to v1.0.1 in order to pass Bluetooth certification:
bug 827255
bug 827212
bug 827266
bug 828175
bug 823346
bug 827230
bug 828798
bug 835740
bug 846647
bug 828160
bug 827204
bug 825861
bug 825851
So, mark these bugs as tef?. These fixes have some dependency and it would be better to have them landed in a specific order. I'll provide the order later.
blocking-b2g: --- → tef?
Assignee | ||
Comment 8•12 years ago
|
||
I recommend to land these patches in the following order:
01. bug827204
02. bug827255
03. bug823346
04. bug827230
05. bug828798
06. bug827212, patch 1
06. bug827212, patch 2
07. bug827266
08. bug828175
09. bug846647
10. bug825861
11. bug825851
12. bug835740
I'm going to attach patches for b2g18_v1_0_1 for each bug. Please land them in the above order. There should be no conflict and feel free to let me know if I can be any help.
Assignee | ||
Comment 9•12 years ago
|
||
Comment 10•12 years ago
|
||
tef- for now until tef release partner confirms this is blocking BT cert.
blocking-b2g: tef? → -
Assignee | ||
Comment 13•12 years ago
|
||
Ryan, I've updated all patches. Please land them in the following order, thanks.
01. bug827204
02. bug827255
(03. bug823346 has been landed on v1.0.1)
04. bug827230
05. bug828798
06. bug827212, patch 1
06. bug827212, patch 2
07. bug827266
08. bug828175
09. bug846647
10. bug825861
11. bug825851
12. bug835740
Comment 14•12 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•