**** BEGIN LOGGING AT Wed May 12 02:59:56 2010
May 12 06:32:37 <feitingen> denkenz: sorry, fell asleep a bit quicker than anticipated yesterday...
May 12 06:33:10 <feitingen> i have a sim in it, it powers on and works for a while on fso, but fso crashes for some reason
May 12 08:28:19 <feitingen> i am wondering if this is because my sim card has a pin code, but i don't think it should matter for just powering up the modem
May 12 13:13:58 <denkenz> feitingen: CFUN=1 shouldn't fail, have you updated the modem to the latest firmware?
May 12 13:14:27 <feitingen> yes, moko11
May 12 13:15:45 <denkenz> Is this a Freerunner or the Neo?
May 12 13:16:05 <feitingen> freerunner
May 12 13:17:58 <feitingen> it returns error even in a terminal session with the modem freshly restarted
May 12 13:18:31 <denkenz> Try inserting AT+CMEE=2 before the CFUN
May 12 13:18:49 <denkenz> See whether the modem gives a better error
May 12 13:19:12 <feitingen> +CME ERROR: SIM PIN required...
May 12 13:20:18 <denkenz> interesting, the PIN has to be checked before a CFUN on a freerunner?
May 12 13:20:32 <feitingen> seems that way..
May 12 13:22:47 <denkenz> Then you might have to do some surgery to the calypso plugin
May 12 13:23:44 <feitingen> seems that way.. CFUN is just supposed to turn the modem on?
May 12 13:24:27 <denkenz> On most devices I've seen CFUN turns on the modem yes
May 12 13:24:50 <denkenz> However, the Freerunner might be different because it has a physical power on / off switch
May 12 13:24:58 <denkenz> so CFUN might only mean tx/rx circuits
May 12 13:25:20 <feitingen> yes, and it seems the calypso has a lot of other quirks..
May 12 13:25:22 <denkenz> So it makes sense that those can't be on before a SIM PIN is entered
May 12 13:26:49 <feitingen> hehe, but it wont let me enter my pin :P
May 12 13:26:58 <denkenz> one way to solve this is to send the CFUN from the post_sim callback instead, and only add the post_sim atoms then
May 12 13:28:16 <feitingen> i have not looked enough in the source for that, but i will do when i get home
May 12 13:30:22 <denkenz> it should let you enter the pin
May 12 13:30:34 <denkenz> once the sim atom is alive
May 12 13:31:49 <feitingen> but "something" has to be done before that, it does not let me enter a pincode immediately.. < AT+CPIN=**** > +CME ERROR: operation not allowed
May 12 13:34:12 <balrog-k1n> so it can't do emergency calls without pin?
May 12 13:35:35 <feitingen> good question, i am not sure..
May 12 13:36:50 <denkenz> that's just screwed up
May 12 13:37:12 <feitingen> sometimes i think that summarizes the calypso
May 12 13:37:37 <denkenz> maybe the firmware is just plain confused? Have you tried a clean boot without any other stack taking control?
May 12 13:39:06 <denkenz> btw, in theory it should be +CPIN="1234"
May 12 13:39:53 <feitingen> oh, thanks
May 12 13:46:02 <feitingen> the quotes worked, i need to check for (and send) CPIN before CFUN
May 12 14:06:35 <denkenz> yang_ubuntu1: here?
May 12 14:06:42 * balrog-k1n will wait with sending his stk patches for calypso until this is worked out
May 12 14:06:59 <balrog-k1n> in theory the voicecall atom can now be post_sim
May 12 14:07:30 <denkenz> send the stk driver ones
May 12 14:07:51 <denkenz> besides, this is only a problem for PIN enabled sims
May 12 14:08:09 <balrog-k1n> but the whole hack may be useless if AT+CFUN is issued later
May 12 14:09:00 <denkenz> ah I see what you mean
May 12 14:14:02 <feitingen> denkenz: would you use a pin-free sim in your phone?
May 12 14:14:24 <denkenz> feitingen: Never saw a point to pin locks
May 12 14:15:59 <feitingen> if my phone was stolen i wouldn't like someone to access the info on my sim without any effort
May 12 14:18:16 <denkenz> I tend to set a lock on the phone itself and never use SIM phonebook
May 12 14:18:50 <denkenz> my phone doesn't even store SMS on the SIM, so nothing besides my phone number is on the SIM anyway
May 12 15:45:58 <denkenz> pessi: ping
May 12 19:15:31 <denkenz> padovan: +                       include/bluetooth.h
May 12 19:15:39 <denkenz> That is really wrong, this belongs in plugins
May 12 19:17:18 <padovan> denkenz: I was wondering about putting it in plugin or src. Originally I did it in plugin then move it to src ;)
May 12 19:17:31 <padovan> I can change that.
May 12 19:18:41 <denkenz> nod, do it in plugins, the core shouldn't have knowledge of such details
May 12 19:19:01 <denkenz> Especially since all of this is BlueZ specific and all our BlueZ plugins will be in-tree builtins
May 12 19:21:11 <padovan> Right, I'll change that and re-submit. ;)
May 12 19:21:28 <denkenz> also, what is your long term plan for supporting DUN client inside oFono?
May 12 19:21:40 <denkenz> You'll have to fake a couple of atoms to make it work...
May 12 19:22:51 <denkenz> and then there's the issue that the DUN dial string is notoriously device specific
May 12 19:24:42 <padovan> denkenz: I can support it, I'll stay in the community after finish it.
May 12 19:25:58 <padovan> I didn't looked to that issues yet, I'm going to do the BlueZ side agent first.
May 12 19:26:22 <padovan> Then will come DUN stuff inside oFono.
May 12 19:27:21 <denkenz> yeah so this is my concern, you do need a user configurable dial string because all devices in the market are stupid
May 12 19:27:36 <denkenz> oFono doesn't really allow that..
May 12 19:29:30 <padovan> so I'll have to work on that too.
May 12 19:34:48 <padovan> denkenz: and what about the code I submited? does it looks good to you?
May 12 19:36:21 <denkenz> still going through it
May 12 19:36:55 <denkenz> did holtmann ever accept the send_method_call patches into gdbus?
May 12 19:38:31 <padovan> denkenz: no, then I postponed such change.
May 12 19:39:07 <denkenz> Ok, so my advice is to break that patch up into more manageable chunks
May 12 19:39:19 <denkenz> e.g. if you're moving send_method_call, then just send a patch for that
May 12 19:40:00 <denkenz> alot of the utility stuff can go into bluetooth.c almost immediately
May 12 19:40:29 <padovan> yeah, most of the patch is one big atomic change.
May 12 19:41:04 <denkenz> yep, otherwise I get lost reviewing such a huge chunk
May 12 19:45:09 <padovan> Ok, I'll rework the patches. ;)
May 13 02:21:29 <yang_ubuntu1> denkenz: ping
May 13 02:22:01 <denkenz> yang_ubuntu1: pong
May 13 02:23:23 <yang_ubuntu1> denkenz: You sent me a message yesterday, while I'm actually off.
May 13 02:24:01 <yang_ubuntu1> Any order from you, sir?
May 13 02:24:22 <denkenz> yang_ubuntu1: I was just going to ask you about those > 0 checks
May 13 02:24:33 <denkenz> yang_ubuntu1: But then commented on the list instead
May 13 02:24:59 <denkenz> Now that you're here though
May 13 02:25:05 <yang_ubuntu1> I have read that part, and I will leave the other code ther.
May 13 02:25:26 <yang_ubuntu1> s/ther/there
May 13 02:25:31 <denkenz> When working on the proactive command parsers, feel free to ignore the ones we don't care about
May 13 02:25:55 <denkenz> Namely anything related to MMS, data channels and bluetooth / irda
May 13 02:25:58 <yang_ubuntu1> What would be the necessary part?
May 13 02:26:08 <yang_ubuntu1> How about send sms?
May 13 02:26:21 <yang_ubuntu1> I found the test cases are quite complicated.
May 13 02:26:22 <denkenz> Send sms definitely we need
May 13 02:26:33 <yang_ubuntu1> :-(
May 13 02:26:43 <denkenz> what are the complications?
May 13 02:26:54 <yang_ubuntu1> I will find other time to add more test cases.
May 13 02:27:37 <yang_ubuntu1> I also saw your comments on parsing item list
May 13 02:27:59 <yang_ubuntu1> It seems you want to introduce ctlv_save/restore?
May 13 02:28:32 <yang_ubuntu1> the struct of sms is complicated.
May 13 02:28:39 <denkenz> Just an idea if saving the iterator state is the only thing standing in your way
May 13 02:28:51 <yang_ubuntu1> However, I think I can deal with them. Just need some effort.
May 13 02:29:05 <denkenz> Note that you're free to ignore any CDMA cases for now
May 13 02:29:30 <yang_ubuntu1> Right, I will ignore the CDMA cases.
May 13 02:30:00 <yang_ubuntu1> For the sms parser, I add cdma ctlv decoding for it's easy.
May 13 02:30:32 <denkenz> I figured
May 13 02:30:48 <denkenz> ask for help if you're getting stuck on sms btw
May 13 02:31:01 <yang_ubuntu1> But when we are parsing list, I have to remember state everytime we move forward.
May 13 02:31:42 <yang_ubuntu1> sure, you're always kind and helpful;)
May 13 02:31:43 <denkenz> that's fine, a save / restore function would be extremely cheap
May 13 02:32:21 <yang_ubuntu1> But what's the drawback of a flag? I think it's cheaper.
May 13 02:32:42 <denkenz> main drawback is you'd also need to pass in the size of the structure
May 13 02:32:47 <yang_ubuntu1> save should only remember the pos.
May 13 02:32:55 <denkenz> so that you can malloc for the GList
May 13 02:33:55 <yang_ubuntu1> What do you mean the "pass in"? I can pass in the type.
May 13 02:34:23 <denkenz> yeah, but you don't know the struct for that type
May 13 02:34:39 <denkenz> what are you going to malloc?
May 13 02:34:50 <yang_ubuntu1> That part is hard coding.
May 13 02:34:55 <denkenz> exactly ;)
May 13 02:36:01 <denkenz> There are I think 3 cases where this occurs, it is easier to handle it as an exception
May 13 02:36:04 <yang_ubuntu1> yes. I can understand it's not good for parse_dataobj() to know something like this.
May 13 02:36:29 <yang_ubuntu1> Actually only 2 types.
May 13 02:36:58 <denkenz> 2 types in 3 commands right?
May 13 02:37:09 <yang_ubuntu1> right
May 13 02:37:23 <yang_ubuntu1> The other is provisioning file reference.
May 13 02:37:40 <yang_ubuntu1> ok. I will try the way of save/restore.
May 13 02:38:00 <denkenz> Just an idea ;)
May 13 02:38:50 <yang_ubuntu1> To save the state, only to save the pos is enough.
May 13 02:39:15 <yang_ubuntu1> I wonder how to write the save function.
May 13 02:39:27 <yang_ubuntu1> Only have someway to save pos, or the whole iter?
May 13 02:39:40 <denkenz> You can always make a save into another iter
May 13 02:39:44 <denkenz> keep it simple
May 13 02:40:45 <yang_ubuntu1> Most of the fields of iter are useless.
May 13 02:41:47 <denkenz> well, if you have a more clever way, feel free :)
May 13 02:42:47 <yang_ubuntu1> The simple way is to remember the pos when parsing the list. After parsing the list, copy the pos to iter->pos (kind of restore), and use parse_dataobj() for the rest ctlvs.
May 13 02:43:02 <yang_ubuntu1> Do you agree on this approach?
May 13 02:43:52 <yang_ubuntu1> My first implementation was in this way.
May 13 02:43:57 <denkenz> that's fine too, as long as you can guarantee user does a next always
May 13 02:44:28 <denkenz> it might be cleaner to restore and the pos and re-fill all the fields again
May 13 02:45:23 <yang_ubuntu1> For a general restore, i agree all the fields should be restored. 
May 13 02:45:46 <denkenz> treat it as a general restore
May 13 02:45:55 <denkenz> its a fully-fledged internal API
May 13 02:45:57 <yang_ubuntu1> But in our code, we use parse_dataobj() later, which will read the next one again.
May 13 02:46:20 <denkenz> You can always name it 'peek'
May 13 02:46:31 <denkenz> to get the next tag
May 13 02:47:25 <yang_ubuntu1> ok. I will introduce the function for save and restore, and submit the patch.
**** ENDING LOGGING AT Thu May 13 02:59:56 2010