**** BEGIN LOGGING AT Fri Mar 25 02:59:57 2011
**** ENDING LOGGING AT Fri Mar 25 07:03:19 2011

**** BEGIN LOGGING AT Fri Mar 25 07:04:14 2011
**** ENDING LOGGING AT Fri Mar 25 07:16:35 2011

**** BEGIN LOGGING AT Fri Mar 25 07:18:14 2011
Mar 25 09:45:06 <rpourtier> holtmann:ping
Mar 25 09:47:01 <holtmann> rpourtier: pong
Mar 25 10:22:41 <fdanis> pnunes_: ping
Mar 25 15:01:16 <BertrandAygon> fdanis: ping
Mar 25 17:58:02 <Jeevaka> denkenz: ping
Mar 25 18:17:58 <denkenz> Jeevaka: pong
Mar 25 18:28:33 <Jeevaka> denkenz: question is on emergeny call in state - online but PIN entry required
Mar 25 18:29:30 <Jeevaka> denkenz: I thought we dont need to create any post online atoms in that case
Mar 25 18:29:38 <denkenz> we don't
Mar 25 18:31:36 <Jeevaka> only case for which we will create post online atoms is "Pin not locked, offline state". right?
Mar 25 18:32:23 <Jeevaka> basically for SIM present, PIN already entered
Mar 25 18:32:54 <denkenz> two cases:
Mar 25 18:33:02 <denkenz> sim ready, offline -> online
Mar 25 18:33:23 <denkenz> online, sim pin / no sim -> online, sim ready
Mar 25 18:33:50 <denkenz> the second case is e.g. user entering a pin
Mar 25 18:37:43 <Jeevaka> but why do we need to create the post online atoms for the second case. after the call we still need to enter the actual pin to use it full mode
Mar 25 18:38:20 <denkenz> the call is optional
Mar 25 18:38:26 <denkenz> so you can do something like this:
Mar 25 18:38:33 <denkenz> modem.SetOnline(TRUE)
Mar 25 18:38:49 <denkenz> sim_mgr.EnterPin("1234")
Mar 25 18:39:05 <denkenz> in which case both post_sim and post_online atoms need to be populated
Mar 25 18:42:27 <Jeevaka> incase of Enter pin request, sim state changes will anyway trigger the creation of post online atoms
Mar 25 18:45:09 <denkenz> post_sim yes, not so sure about post_online
Mar 25 18:47:14 <Jeevaka> sim_state_watch(modem.c) will trigger the change to offline and online
Mar 25 18:47:49 <denkenz> only if get_online is true
Mar 25 18:47:55 <denkenz> That is set only during a modem reset
Mar 25 18:48:30 <denkenz> modem.c will require some surgery, but it shouldn't be too bad
Mar 25 18:49:41 <Jeevaka> i see the point
Mar 25 18:52:02 <denkenz> Just take a stab at it and I help you
Mar 25 19:00:09 <Jeevaka> ok
Mar 26 00:04:04 <balrog-k1n> denkenz: in stk refresh we don't current check whether USSD or voicecalls are in progress as we say we would in the todo
Mar 26 00:04:40 <balrog-k1n> denkenz: do you think we should? the spec makes it sound like the card had already updated the files when it notifies us about it
Mar 26 00:05:16 <balrog-k1n> and the longer we wait before refreshign our caches etc. the longer we're out of sync
Mar 26 00:05:30 <balrog-k1n> s/had/has
Mar 26 00:29:04 <denkenz> balrog-k1n: I think it depends on the modem behavior
Mar 26 00:29:15 <denkenz> If our opinion actually matters, then we should reject the refresh
Mar 26 00:29:32 <denkenz> But if the modem simply informs us, then we trust the firmware to do its job
**** ENDING LOGGING AT Sat Mar 26 02:59:58 2011