**** BEGIN LOGGING AT Thu Aug 05 02:59:57 2010 Aug 05 13:00:08 denkenz: have you seen voice-only patch on the mailing list? Aug 05 13:14:17 jprvita: I saw it at least. I'll try to test it today with my huawei modem Aug 05 13:14:32 kvalo: thanks :) Aug 05 13:15:23 also, feel free to make comments / suggestions on the code Aug 05 13:16:24 jprvita: thanks, I will Aug 05 13:17:29 I just need to finish something else first Aug 05 14:13:43 jprvita: I gave you some comments on IRC yesterday Aug 05 14:14:24 hum, I may have lost them, need to check the logs Aug 05 14:14:25 jprvita; Please change the simst 1/2/3/4/0/255 into an enum Aug 05 14:14:39 That way the code is easier to follow Aug 05 14:15:17 jprvita: And have you tested with PIN locks? Aug 05 14:16:05 i've tried lock my sim with PinLock(), but it didn't show as locked Aug 05 14:16:30 and I have lock required = none under sim properties Aug 05 14:18:22 weird, it seems your comments never arrived to my client Aug 05 14:19:51 It won't until the next cold boot Aug 05 14:20:14 Locking the Pin activates it the next time SIM is initialized Aug 05 14:20:51 If you're running 'hot' and not re-initializing the SIM, it won't do anything Aug 05 14:20:58 right Aug 05 14:21:19 and what does this 'pin required' means then? Aug 05 14:32:22 PinRequired tells you what PIN/PUK the modem wants Aug 05 14:32:38 It goes to none once you unlock Aug 05 15:24:25 jprvita: sorry, I wasn't able to test your patch today. but I'll do first thing tomorrow morning. Aug 05 15:25:05 *do that Aug 05 16:35:49 kvalo: but it's still 1h30 in the afternoon ;) Aug 05 16:36:19 nevermind, I'll re-send it with denis corrections now, then you can test the reviewed version Aug 05 17:21:34 jprvita: in that case I test it first thing midnight your time ;) Aug 05 17:24:58 kvalo: Promises promises ;) Aug 05 17:26:30 well, his midnight is my morning so the promise didn't change at all :) Aug 05 17:26:52 lol I know Aug 05 18:41:52 jprvita: so this works with PIN enabled modems now? Aug 05 18:42:20 denkenz: yes Aug 05 18:43:05 it had a small issue with never notifying sim as inserted for pin-locked sims Aug 05 18:43:22 ok Aug 05 18:43:28 +enum huawei_sim_state { Aug 05 18:43:28 + HUAWEI_SIM_STATE_INVALID_OR_LOCKED = 0, Aug 05 18:43:29 + HUAWEI_SIM_STATE_VALID = 1, Aug 05 18:43:29 + HUAWEI_SIM_STATE_INVALID_CS = 2, Aug 05 18:43:29 + HUAWEI_SIM_STATE_INVALID_PS = 3, Aug 05 18:43:30 + HUAWEI_SIM_STATE_INVALID_PS_AND_CS = 4, Aug 05 18:43:30 + HUAWEI_SIM_STATE_NOT_EXISTENT = 255 Aug 05 18:43:30 +}; Aug 05 18:43:30 + Aug 05 18:43:33 Just a small nitpick here Aug 05 18:43:47 But we prefer the enum value to be indented Aug 05 18:43:53 see src/smsutil.h for an example Aug 05 18:44:32 I've look on sim.h and I thought I've gone consistent with that Aug 05 18:44:35 will re-look Aug 05 18:45:06 Yeah, this was a rule introduced mid-stream Aug 05 18:45:17 So some of them don't reflect the correct style Aug 05 18:45:33 So no worries, just letting you know ;) Aug 05 18:46:15 +static void notify_sim_state(struct ofono_modem *modem, Aug 05 18:46:16 + enum huawei_sim_state sim_state) Aug 05 18:46:34 Please indent the arguments on the second line at least past the opening '(' Aug 05 18:48:04 ok, but I couldn't find this one on the coding-style doc Aug 05 18:48:32 and about the enum, sorry but I still don't see any difference on the file you've mentioned Aug 05 18:48:50 both cases 1 tab aligned Aug 05 18:49:00 s/aligned/idented Aug 05 18:49:22 I'm talking about the enum value Aug 05 18:49:24 what am I missing here? Aug 05 18:49:30 e.g. =0 Aug 05 18:50:25 I will add that to the coding style doc, that one is still WIP Aug 05 18:50:31 but src/smsutil.h is not idented like that ;) Aug 05 18:51:07 ah crap Aug 05 18:51:11 I meant src/stkutil.h Aug 05 18:51:13 but now I've understood how you want it Aug 05 18:51:14 hehe Aug 05 18:51:26 sorry ;) Aug 05 18:51:29 + if (data->sim_state == HUAWEI_SIM_STATE_NOT_EXISTENT) Aug 05 18:51:30 + return; Aug 05 18:51:30 + Aug 05 18:51:39 I think this case can be omitted from post_sim Aug 05 18:51:49 You will never get to post_sim is sim_inserted is FALSE Aug 05 18:55:12 Rest looks fine Aug 05 18:55:15 Resubmit and I apply it Aug 05 18:55:18 ok, just fixed this all, will re-test it and re-send it Aug 05 18:55:28 cool, tks Aug 05 19:06:26 Ok, I updated the coding-style as well Aug 05 21:18:19 denkenz: I'm going to send a patch series to the list for the icon stuff I have -- I haven't addressed the problems with read_bytes yet, but this is mainly to get your feedback on the other patches in the series and answer some questions I had. Aug 05 21:18:44 sure Aug 05 21:58:05 kristenc: The icon ids will be 1-based, we will pass them as-is from the STK command parser to the UI Aug 05 21:58:18 kristenc: 0 indicates no icon Aug 05 21:58:23 ok Aug 05 21:58:48 + { "GetIcon", "i", "", sim_get_icon, Aug 05 21:59:08 The GetIcon signature should be ay or something Aug 05 21:59:33 Or s Aug 05 21:59:41 xpms are strings I guess Aug 05 22:00:01 The in argument signature should be 'y' not 'i' Aug 05 22:00:19 Max of 255 icons, so use byte as the type Aug 05 22:08:21 kristenc: For patch 2 we might move the pixmap utility/enums to simutil.h Aug 05 22:08:27 Rest looks like a good start Aug 05 22:09:53 denkenz: I had a question about the existing file cache. are all files on the sim filesystem automatically read and stuck into this cache? Because I noticed while I was testing that my iidf files were always in the cache. Aug 05 22:10:19 It depends on the permissions of the files Aug 05 22:10:42 If the file is user-writable, the file isn't cached Aug 05 22:11:22 EFiidf should not be writeable, right? Aug 05 22:11:36 According to the spec it isn't Aug 05 22:12:26 So, do we need to write new code to cache the EFiidfs, because it seems like they are already cached. Aug 05 22:13:38 The problem is that the current caching code does not handle files > 256 bytes Aug 05 22:13:57 The other problem is that we should not read the EFiidf files in their entirety anyway Aug 05 22:14:20 so the existing cache code needs to be modified to NOT cache any EFiidf files. Aug 05 22:14:38 potentially, or cache them differently Aug 05 22:15:01 e.g. allow the caching of fragments Aug 05 22:15:29 I guess I'll look at the existing cache code and see if we can work with it. I like the idea of using as much of the existing stuff as possible rather than inventing a whole separate path for read_bytes. Aug 05 22:17:17 I doubt the existing code will be sufficient Aug 05 22:52:01 wow, the N900 policy daemon in prolog adds a 4 second delay to calls ringing :( Aug 06 00:53:35 denkenz: While XPMs are indeed strings. For simplicity we should do ay in case in the future we wanna export a different format. So given the the raw bytes of the string might be safer. Aug 06 01:09:31 its also quicker as it avoids UTF-8 validation :P Aug 06 01:13:40 ay it is then Aug 06 01:22:38 sigh, so the AT+CFUN=1 actually works fine on Calypso like on other modems, it just reports "+CME ERROR: SIM PIN required" but the error needs to be ignored Aug 06 01:26:20 heh Aug 06 01:26:26 That's calypso for ya Aug 06 01:27:36 The funny part was that the whole reason for choosing that modem (e.g. standards compliance, regular AT commands) was completely void in the end Aug 06 01:28:11 They ended up using signing the NDA and stuffing proprietary commands everywhere ;) Aug 06 01:28:57 But hey, if oFono works on that modem, it can work anywhere :P Aug 06 01:29:33 yeah, but then anything else they'd have chosen would have similar problems, there really isn't many compliant modems Aug 06 01:30:12 Well more like there are zero compliant modems ;) Aug 06 01:30:35 However, the Ericsson firmware was way more sane at the time Aug 06 01:30:53 Greenphone was a breeze compared to calypso Aug 06 01:30:57 so.. it's still tricky to initialise the modem in the right order for STK to work... basically you need to: initialise STK, run AT+CFUN=1, then initialise SIM (enter PIN) in exactly this order.. i'm not sure if i should do this in the calypso plugin Aug 06 01:31:40 denkenz: This reminds me. You never got me a Greephone ;) Aug 06 01:32:14 holtmann: Yeah, I wanted to actually, but there were too little of them by that time Aug 06 01:32:42 Besides, without possibility of running kernel 2.6 on it, the device was DoA anyway Aug 06 01:32:51 Anyhow, so the Huawei patch is considered correct and verified? I am thinking of spinning another release just to make sure it gets out there. Aug 06 01:33:08 kvalo promised to test it in about 6 hours Aug 06 01:33:14 I'd wait till then Aug 06 01:33:31 balrog-k1n: So you need to do the terminal profile before CFUN=1? Aug 06 01:34:02 denkenz: it seem you just tell the Calypso what bits to set in the terminal profile, Aug 06 01:34:19 the profile download actually happens either during CFUN=1 or CPIN="xxx" Aug 06 01:34:40 Probably after CPIN Aug 06 01:34:52 yes, except on card with no pin Aug 06 01:34:56 cards* Aug 06 01:35:23 yep, so the firmware probably queries the SIM and is blocked in case the PIN is active Aug 06 01:35:34 Otherwise it just initializes it, including the terminal profile Aug 06 01:35:46 So the bottom line the main menu arrives before stuff is ready... Aug 06 01:36:20 yes, unless we really initialise the stk atom first.. but i'm not sure this makes sense Aug 06 01:37:14 It really doesn't, but my thinking is that we push the terminal profile out of the core Aug 06 01:37:20 It is a stupid detail anyway Aug 06 01:37:41 Then the modem driver can play some tricks Aug 06 01:38:27 do you count the plugins as core? Aug 06 01:38:45 core = everything in src/ Aug 06 01:38:59 ok, then we don't have anything related to the profile there Aug 06 01:39:55 It would be nice if we could actually tell the modem driver about the profile we support Aug 06 01:40:05 But this seems unlikely, and not even supported on some modems Aug 06 01:40:45 yes, in the end all the modem drivers support the same profile bits (currently the profile string is duplicated in MBM plugin and in calypso plugin) Aug 06 01:41:27 Yeah, so until the modem manufacturers get a clue, we do the profile download in the modem driver Aug 06 01:43:27 do you prefer that we create the stk atom before the stk atom in calypso plugin (only if sim present), or that the plugin registers for %SATI notifications and later passes it on to the atom driver? Aug 06 01:43:31 both are hacks Aug 06 01:43:40 err, stk atom before the sim atom Aug 06 01:44:00 Can't we have the modem driver listen to SATI and pass this on? Aug 06 01:44:22 yeah, that's the second option Aug 06 01:44:35 Maybe we need some sort of 'inject' function to GAtChat :P Aug 06 01:45:43 i was thinking about that too.. but for now the stk atom driver can have an 'inject' function like that Aug 06 01:46:49 and btw. the +CFUN=1 needs to always be done before +CPIN="xxx", otherwise it'll ask you to enter the pin a second time Aug 06 01:47:09 however doing +CFUN=1;+CFUN=4 works too, in case someone wants to implement Offline mode Aug 06 01:47:09 jeez Aug 06 01:47:24 But not CFUN 0 -> 4? Aug 06 01:47:32 nope, Aug 06 01:47:35 AT+CFUN=4 Aug 06 01:47:35 +EXT ERROR: error unknown Aug 06 01:47:41 hilarious Aug 06 01:48:23 So honestly I think both options will work Aug 06 01:48:33 initializing stk early gets it moved to pre_sim state Aug 06 01:48:51 However, that might not have a negative impact Aug 06 01:49:28 initializing stk atom early has the advantage that we don't clutter the atom drivers with the 'inject' call Aug 06 01:49:35 so the whole hack is contained in calypso.c Aug 06 01:50:08 agreed Aug 06 01:50:16 So lets see how that works out **** ENDING LOGGING AT Fri Aug 06 02:59:58 2010