**** BEGIN LOGGING AT Wed Apr 13 02:59:57 2011 Apr 13 14:53:22 holtmann: ping Apr 13 14:54:49 Jeevaka: pong Apr 13 14:56:30 creating the emergency-call-handling.txt file Apr 13 14:56:32 http://pastebin.com/pVkyGiF3 Apr 13 14:56:42 Is this what you expect? Apr 13 14:57:48 I am fine with that. Apr 13 14:57:58 denkenz: Please have a look as well. Apr 13 15:00:33 Jeevaka: looks good Apr 13 15:02:01 denkenz: holtmann: Thanks for the confirmation Apr 13 15:13:36 denkenz: I take a look at voicecalls_release_next() in voicecall.c and I do not understand why this calls hangup_active multiple times Apr 13 15:13:36 for me, the release_list and related functions should only be used when we need to call release_specific to do the job Apr 13 15:14:54 we don't call it multiple times Apr 13 15:16:11 And the reason is that CHLD=1X does not work on dialing/alerting/incoming calls or emergency calls Apr 13 15:16:34 At least not according to some interpretations of AT commands Apr 13 15:18:42 hangup_active is equivalent to AT+CHUP, and release_specific should be implement with CHLD=1X, right ? Apr 13 15:19:52 roughly, depends on the manufacturer Apr 13 15:21:01 True 27.007 does not allow CHLD=1X on held calls Apr 13 15:21:12 And +CHUP hangs up all calls but waiting Apr 13 15:21:32 So there's subtle differences between HFP and the rest of the world Apr 13 15:23:59 so we should have 2 different release_next functions for HFP or other, right ? Apr 13 15:27:26 not really Apr 13 15:27:52 HFP CHUP should use hangup_active if available, otherwise fall back to release_queue Apr 13 15:30:31 ok, thanks Apr 13 15:32:52 uhm ... may I ask some newbie questions? Apr 13 15:35:16 i haver here ofonod 0.45 and an mbm device Apr 13 15:35:17 sure Apr 13 15:35:59 running ofono -d it seems my device is found by ofono Apr 13 15:37:14 now I am using qdbusviewer trying to see something Apr 13 15:37:35 there is org.ofono in the list Apr 13 15:38:54 i'd expect org.ofono.Manager GetModems would show my something Apr 13 15:39:41 but I only get the error "Unable to find method GetModems on path / in interface org.ofono.Manager" Apr 13 15:40:49 so, what would be the easiest way to find out whether ofono would work on my system? Apr 13 15:43:27 and how to find out the device path for a specific device to e.g try the test-tools Apr 13 15:58:23 Try test/list-modems Apr 13 15:59:38 However, if you are not able to execute GetModems, then likely something is screwed up with your D-Bus permissions Apr 13 16:03:55 in the meanwhile I found out that test/enable-modem is needed first Apr 13 16:04:02 so I proceeded Apr 13 16:04:28 test/list-modems works Apr 13 16:04:47 Then you're doing something wrong ;) Apr 13 16:05:54 ok, I had no clue how a modem identifyer looks like - now I know that's simply a number Apr 13 16:11:17 denkenz: now I am trying test/unlock-pin Apr 13 16:11:30 Operation failed Apr 13 16:11:50 my commandline ist test/unlock-pin / pin 1234 Apr 13 16:12:14 (with the correct pin, of course) Apr 13 16:13:02 no idea without the AT log Apr 13 16:15:20 denkenz: how do I get the AT log? is there a value for -d? Apr 13 16:15:33 export OFONO_AT_DEBUG=1 before running ofonod Apr 13 16:25:21 denkenz: ok, test/enter-pin would have been a better idea Apr 13 16:25:35 that simply works Apr 13 16:39:42 denkenz: ok, thanks for your help so far Apr 13 16:39:46 I am leaving Apr 13 16:43:54 denkenz: ping Apr 13 16:44:03 Jeevaka: pong Apr 13 16:45:12 are we expecting the application to also check whether the dialled number is an emergency number(particularly in no sim state)? Apr 13 16:49:11 or are we expecting the application to set the online mode irrespective of the number dialled? Apr 13 16:59:01 Jeevaka: Generally if the user brings up the dialer, then he should be asked to bring the modem online Apr 13 16:59:27 Whether a number is emergency or not doesn't seem relevant Apr 13 16:59:34 ok Apr 13 16:59:49 The only exception might be a dedicated panic button, but then the user's intent is known anyway Apr 13 17:44:00 denkenz: So ofono-0.46 tarballs should be uploaded now. Apr 13 17:44:52 nice Apr 13 17:45:12 We should have made a release in between. This one includes 1 month of work now. Apr 13 17:50:51 yep Apr 13 17:51:00 But I wanted all the emergency changes in one release Apr 13 17:59:32 And you got it ;) Apr 13 18:25:53 denkenz: ping Apr 13 18:26:01 ? Apr 13 18:26:56 while working with sms application (meego), found the following issue. Apr 13 18:27:18 set the delivery report flag to true, and close sms Apr 13 18:27:27 reboot Apr 13 18:27:35 the settings are not stored Apr 13 18:28:16 they are stored only if modem is set offline or powered down Apr 13 18:35:48 yes, but why is oFono not being shut down cleanly on reboot? Apr 13 18:35:53 Same as pulling the battery ;) Apr 13 18:37:41 yeh Apr 13 18:38:22 but the data is stored only on atom removal Apr 13 18:39:22 from an application perspective, the settings were accepted, but never stored. Apr 13 18:40:22 why we don't store it on SetProperty? Apr 13 18:43:11 Because its inefficient? Apr 13 18:43:46 I don't really want to encourage that. an unclean shut down is stupid anyway Apr 13 18:43:48 but at least the persistant settings such as this should be stored Apr 13 18:44:05 oFono cleans up nicely after itself, you need to let it do that Apr 13 18:44:46 all i did was a reboot command from console, and i also thought it should store these, but it didn't Apr 13 18:45:19 Then oFono probably got kill -9ed Apr 13 18:45:19 not getting enough time to store? Apr 13 18:45:55 but there is a handler for that i believe Apr 13 18:46:25 Yes, oFono handles signals gracefully, but nothing it can do against -9 Apr 13 18:47:53 You really need to let it shutdown gracefully, as we also disable modems, and sync other stores Apr 13 18:48:05 Otherwise even your hardware can get screwed up Apr 13 18:52:21 controlled shut down from UI, only be able to do that. Apr 13 18:52:44 but reboot, or sutdown from console are also valid cases Apr 13 18:54:26 Then the init scripts need to be compatible Apr 13 18:55:33 Anyhow, I think we need a periodic sync process, and not try to sync immediately Apr 13 18:56:08 yeh, could also be immediate sync for a subset of properties Apr 13 18:56:31 Which we do for the really important ones, like SMS Ref Apr 13 18:57:05 Otherwise you might have simple UIs which set all N settings, causing n writes Apr 13 18:57:27 writes need to be done only if there is change, for properties Apr 13 18:58:00 but yeh still there can be UIs which can cause n writes Apr 13 18:59:02 We don't always check for value == old value Apr 13 19:02:18 Let me think about it some more, but the distro must still solve the clean shutdown issue Apr 13 19:03:28 other cases of battery removal, accidents etc should also needs to be addressed the best possible way Apr 13 19:04:38 I'm not so worried about battery removal Apr 13 19:04:51 There are only a few settings that are that critical **** ENDING LOGGING AT Thu Apr 14 02:59:58 2011