**** BEGIN LOGGING AT Tue Oct 13 02:59:56 2009 Oct 13 16:51:17 Looks like IRC has been a terribly exciting place recently Oct 13 19:32:09 denkenz, idling is he true essence of ircing Oct 13 19:36:04 * dilinger idles harder Oct 13 19:36:33 inz: Yeah I noticed that :) Oct 13 20:02:38 denkenz: ping Oct 13 20:03:21 padovan: pong Oct 13 20:06:40 denkenz: what about HFP on ofono? do you have a plan to do that? or at least know how that should be done? Oct 13 20:07:29 padovan: We're doing an HFP backend for oFono, I have some patches in my merge queue, but they're about #3 on the list Oct 13 20:08:04 padovan: The integration between oFono and BlueZ is a little fuzzy, we need jhe for that Oct 13 20:09:52 denkenz: what's the state of that backend? Oct 13 20:10:55 padovan: There are patches, but I haven't looked at them honestly Oct 13 20:11:09 padovan: But regardless HFP will be just another set of drivers for oFono Oct 13 20:11:25 padovan: netreg, voicecall and call-volume drivers Oct 13 20:12:24 denkenz: ok, thanks, I'll take a look on that. Oct 13 20:15:24 padovan: Nod, ofono already does much of the heavy lifting, especially for call state transitions, etc, so it just makes sense to bring HFP in as well Oct 13 20:18:16 denkenz: Great. Oct 13 20:19:23 going to study all this stuff now :) Oct 13 20:20:04 sure Oct 13 21:13:20 grr! Oct 13 21:13:22 ofonod[644]: plugins/g1.c:g1_debug() > AT+CMGS=25\r Oct 13 21:13:22 ofonod[644]: plugins/g1.c:g1_debug() < > \r Oct 13 21:13:22 ofonod[644]: plugins/g1.c:g1_debug() > 0011000A8116571042540000A70DF937881CBE9F59A0791DFE03 Oct 13 21:13:25 ofonod[644]: plugins/g1.c:g1_debug() < \r\n Oct 13 21:13:28 ofonod[644]: plugins/g1.c:g1_debug() < \r\n+CMS ERROR: 193\r Oct 13 21:13:45 * dilinger is going to have to spend some time debugging this :/ Oct 13 21:14:21 Network problem sounds like, "No SC subscription" Oct 13 21:15:32 ofonod[644]: Sending failed, retrying in 5 seconds... Oct 13 21:15:32 ofonod[644]: tx_next: 0x63760 Oct 13 21:15:32 ofonod[644]: plugins/g1.c:g1_debug() > AT+CMGS=25\r Oct 13 21:15:32 ofonod[644]: plugins/g1.c:g1_debug() < > \r Oct 13 21:15:32 ofonod[644]: plugins/g1.c:g1_debug() > 0011000A8116571042540000A70DF937881CBE9F59A0791DFE03 Oct 13 21:15:35 ofonod[644]: plugins/g1.c:g1_debug() < \r\n Oct 13 21:15:38 ofonod[644]: plugins/g1.c:g1_debug() < \r\n+CMGS: 58\r\n\r\nOK\r\n Oct 13 21:15:40 ofonod[644]: at_cmgs_cb got result: 1 Oct 13 21:15:43 i have no idea what changed.. Oct 13 21:15:58 Telling you, your network provider barfed Oct 13 21:16:03 This is why oFono retries Oct 13 21:16:34 yeah Oct 13 21:16:38 super annoying Oct 13 21:16:47 thanks, tmobile Oct 13 21:17:46 of course oFono retries forever right now, which could be 'bad' under some circumstances ;) Oct 13 21:19:06 heh, the retries seem to have caused yafono to puke Oct 13 21:22:19 not my bug :) Oct 13 21:29:49 hrmph Oct 13 21:29:55 stuff's just disappearing Oct 13 21:30:20 sending from sprint's network, ofono (on the tmobile modem) never even sees the SMS Oct 13 21:33:16 heh. and the SMS send went through, but the g1 modem still reported an error. Oct 13 21:33:28 so duplicates were sent Oct 13 21:37:49 SMS in the U.S. is craptastic Oct 13 21:37:59 Sometimes it takes hours to deliver Oct 14 00:13:35 denkenz: hi, denkenz Oct 14 00:16:20 zhenhua: hi Oct 14 00:17:31 denkenz: i think you have received my mail Oct 14 00:18:04 without CLCC, we cannot identify which call line is active Oct 14 00:18:36 zhenhua: Describe the scenario Oct 14 00:19:08 In GSM you cannot have an incoming call during an active/held call Oct 14 00:19:11 It will always be waiting Oct 14 00:19:18 In which case you receive CCWA Oct 14 00:19:37 yes Oct 14 00:20:17 So if the incoming call ends, wouldn't you get callsetup=0? Oct 14 00:20:28 s/incoming/waiting Oct 14 00:20:35 call=0 Oct 14 00:20:46 when call started, callsetup=0 Oct 14 00:21:28 let's use a simpler one Oct 14 00:21:46 Not according to the HFP 1.5 spec I read :) Oct 14 00:21:47 if call is made by phone, we don't have record in HF Oct 14 00:22:15 Yeah, for that one we can't do anything, I agree Oct 14 00:22:20 when we cannot find call only using callsetup and call Oct 14 00:22:29 we must use CLCC to identify it. Oct 14 00:22:32 that's the problem Oct 14 00:23:37 Can we simply fall back to lowest useable state if CLCC is not supported? Oct 14 00:24:24 sure. if CLCC is not supported, we only allow to make call from HF side Oct 14 00:24:48 That sounds fine Oct 14 00:24:56 If the manufacturer's device is broken, that is their problem Oct 14 00:24:59 if call is made from AG side, we should ignore it? or guess the number? i don't know Oct 14 00:25:26 yes. my point is that CLCC mandatory for HFP 1.5. Oct 14 00:25:47 so my previous patch's logic is still correct I think Oct 14 00:26:09 Well, I don't want to actually poll CLCC, its too expensive Oct 14 00:26:15 Lets not do it unless we have to Oct 14 00:26:40 So what you're saying is if we're not the ones dialing, then we have no idea of the phone number Oct 14 00:26:45 okay Oct 14 00:26:46 and HFP doesn't support COLP Oct 14 00:27:06 In this case simply return the number as unknown Oct 14 00:27:09 yes, HFP doesn't support COLP Oct 14 00:27:21 Assuming CLCC fails/not supported Oct 14 00:28:55 poll CLCC is a safe way. callsetup and call don't tell you which call line'status is changed Oct 14 00:29:38 so i prefer to use CLCC. thinking in multicall case, the first call could be ended at any time Oct 14 00:29:49 Just so we're not confused: Oct 14 00:30:08 the default driver actually polls CLCC repeatedly every x seconds Oct 14 00:30:17 and does a comparison of the state Oct 14 00:30:29 If you run CLCC once just to get some information, that is fine Oct 14 00:30:38 okay, Oct 14 00:31:05 The reason the default driver does this is that it gets no notification that e.g. call is no longer waiting/incoming Oct 14 00:31:05 every x seconds? Oct 14 00:31:12 0.5 seconds I think Oct 14 00:31:25 In HFP you have this info through the use of CIEV Oct 14 00:31:43 so once i got CIEV, i could use CLCC to poll it again, right? Oct 14 00:31:59 You can schedule a CLCC to find out exactly what happened, yes Oct 14 00:32:11 yes. that's a workable way, i think Oct 14 00:32:54 Most phones are targetted at dumb hfp headsets, not car kit useage Oct 14 00:32:57 okay, i will follow this way Oct 14 00:33:06 Hence the really crappy spec support Oct 14 00:33:27 yeah Oct 14 00:33:56 Can you go ahead and fix this up, then submit the voicecall driver portion up to the ML? Oct 14 00:34:09 I wanna get that one in soon Oct 14 00:34:11 sure, i will Oct 14 00:34:27 Worst case we can use rfcomm to create a tty or something Oct 14 00:34:29 do you need multiparty call support? Oct 14 00:34:46 if you're ready, otherwise lets start small Oct 14 00:35:01 this is a big patch, i would divide them into several parts Oct 14 00:35:24 like one patch is for plugins, and one patch for voicecall driver Oct 14 00:36:12 and for bluetooth part, we need patch review first Oct 14 00:36:25 Well, can you do a minimal plugin patch? Oct 14 00:36:28 i mean the patch for BlueZ, oFonoHFP Oct 14 00:36:39 Just assume the device is setup on rfcomm0 or something Oct 14 00:37:29 you means without patch for BlueZ? that is not our original design Oct 14 00:37:44 I know, but that part is really nasty Oct 14 00:37:58 it couldn't work because there's no SCO connection Oct 14 00:38:03 Something minimal just for testing the protocol implementation Oct 14 00:38:24 Don't worry about SCO, I just want to make sure the protocol implementation works first Oct 14 00:39:09 E.g. Oct 14 00:39:13 [hfp] Oct 14 00:39:17 Driver=hfp Oct 14 00:39:20 i don't know, but i think current patch should works fine Oct 14 00:39:27 yes Oct 14 00:39:31 Device=/dev/rfcomm0 Oct 14 00:39:54 I know your point and I could test it Oct 14 00:40:01 we can use rfcomm bind to create /dev/rfcomm0 Oct 14 00:40:14 yah, that's really all we need right now Oct 14 00:40:35 That way we can get the individual drivers for voice, netreg, call volume tested Oct 14 00:41:13 so i will get rid of the communication with BlueZ in my patch, right? Oct 14 00:41:48 shall i remove it or keep it there? Oct 14 00:41:52 Keep it in your tree, simply submit a new cut-down modem driver version Oct 14 00:42:15 okay Oct 14 00:42:49 thank you for your suggestion. i really need that. Oct 14 00:43:24 Don't worry, I want this stuff in as well actually Oct 14 00:43:54 yeah, i understand Oct 14 00:43:55 But lets do this gradually so I can review it better Oct 14 00:44:12 okay Oct 14 00:44:14 2500 line patch is a bit too much for me right now :) Oct 14 00:44:20 :) Oct 14 00:44:32 i will make them into several patch for your review. :) Oct 14 00:45:00 nod, cut it down to just the necessities Oct 14 00:45:16 okay Oct 14 00:45:24 Right now we want BRSF exchange + voice Oct 14 00:45:31 Then volume, then netreg Oct 14 00:45:36 thanks Oct 14 00:45:45 got u Oct 14 02:59:12 BRSF? **** ENDING LOGGING AT Wed Oct 14 02:59:56 2009