**** BEGIN LOGGING AT Tue Aug 31 02:59:57 2010 Aug 31 03:02:04 This means all kinds of ss have interference with ussd. But if we call the dedicated API from call-barring, we don't check if ussd is busy or not. So there should be some problems here. Aug 31 06:16:42 denkenz: DUN is starting to work :) Aug 31 06:16:45 ofonod[26788]: > AT+CGDCONT=2,"IP",""\r Aug 31 06:16:45 ofonod[26788]: < AT+CGDCONT=2,"IP",""\r Aug 31 06:16:45 ofonod[26788]: < \r\nOK\r\n Aug 31 06:16:45 ofonod[26788]: > AT+CGDATA="PPP",2\r Aug 31 06:16:45 ofonod[26788]: < AT+CGDATA="PPP",2\r Aug 31 06:16:47 ofonod[26788]: < \r\nCONNECT\r\n Aug 31 06:16:50 Entering new phase: 1 Aug 31 06:21:39 denkenz: but I had to do some nasty hacks in src src/gprs.c, we have to check how to fix that: http://pastebin.com/G6fhCigs Aug 31 06:23:02 padovan: What are you trying to accomplish by disabling the idmap? Aug 31 06:23:49 You might also want to see: Aug 31 06:23:50 void ofono_gprs_set_cid_range(struct ofono_gprs *gprs, Aug 31 06:23:50 unsigned int min, unsigned int max); Aug 31 06:26:04 denkenz: I was just trying to avoid segfaults, to check if I could get setProperty(Active) called and "working" Aug 31 06:26:22 denkenz: what idmap is for? Aug 31 06:26:49 all it does is essentially pick a context id, guaranteed to be unique in the range Aug 31 06:26:56 For you its probably always 1 Aug 31 06:27:35 so min and max set to 1 Aug 31 06:27:42 Yep Aug 31 06:28:05 Ok, let me fix that. Aug 31 06:28:08 So I'm not really sure where you get segfaults, idmap shouldn't be it Aug 31 06:29:06 catch me tomorrow, I'm off to bed Aug 31 06:31:46 then it will be Thursday, I'll attend LinuxCon Brazil next two days ;) Aug 31 09:01:46 morning Aug 31 13:21:44 denkenz: in maemo we have signals telling that if a voice call is ongoing or if emergency call is ongoing... should we have similar properties in ofono VoiceCallManager? Aug 31 13:22:58 now anyone wanting to know if call is ongoing needs to follow CallAdded/CallRemoved and keep track of all the calls Aug 31 15:00:12 pessi: What do you have in mind? Aug 31 15:00:46 pessi: I'm currently toying with the idea of an EmergencyMode property on the Modem object that gets triggered by PIN/PUK/SIM with FDN Aug 31 15:09:40 when emergencycall is requested, a EmergecyCallOnGoing property changes to true ... when it ends, it changes back to false Aug 31 15:09:59 same thing for normal calls, except for property name Aug 31 15:12:23 Ok, so the tricky part is the whole figuring out when an emergency call is active Aug 31 15:12:44 the call type? Aug 31 15:12:50 I asked this several times before, is doing matching against EmergencyCallList enough? Aug 31 15:12:59 0 for ordinary voice calls, 1 for emergency calls Aug 31 15:13:16 ECL comes from SIM? Aug 31 15:13:28 I think that network can update the list Aug 31 15:13:32 And where is this type coming from? Aug 31 15:13:45 I have no idea if the update should end up in the SIM Aug 31 15:13:56 type must come from driver Aug 31 15:14:14 Again, not really possible since +CLCC doesn' give this info Aug 31 15:14:59 then perhaps we should not build a real phone on +CLCC Aug 31 15:15:29 Shrug, that's a given Aug 31 15:16:11 but even %CPI and ECAV don't provide this info AFAIK Aug 31 15:19:04 If someone wants to build a phone with ofono, they have to do something Aug 31 15:19:43 if we have something built into core, they will come Aug 31 15:20:24 Don't get me wrong, I'm totally for the idea Aug 31 15:20:28 its even on the TODO list Aug 31 15:20:38 But give me suggestions that work on modems besides ISI Aug 31 15:23:53 !g_strcmp(call->phone_number.number, "112") Aug 31 15:26:11 Which is why I asked earlier, is performing strcmp on the emergency call list enough Aug 31 15:26:19 it works 1) because emergency calls don't have called party number 2) modem has to get a phone number out of thin air 3) the easiest thing to use is 112 Aug 31 15:28:47 So tell you what, give me a at trace of plain old AT based modem making an emergency call Aug 31 15:28:53 I'd like to see what CLCC reports Aug 31 15:29:16 And another trace of any vendor call progress indication enabled, like Freerunner or something Aug 31 15:30:00 Since in theory there are several numbers that trigger emergency calls, not just 112 Aug 31 15:30:08 and some of them can be burned into modem ROM Aug 31 15:36:13 sure.. Aug 31 15:36:50 so is the question, do we use EmergencyCallList to check for emergency calls in core? in driver? Aug 31 15:37:00 In the core Aug 31 15:37:08 do we it before dialing? after dialing? Aug 31 15:37:23 how the modem fw can report extra emergency numbers? Aug 31 15:37:30 can they change? Aug 31 15:37:39 There's also a task about country / operator specific emergency numbers Aug 31 15:37:54 oh yes. Aug 31 15:38:09 The assumption for modem fw ones are that they are static or per mcc/mnc Aug 31 15:38:17 So querying them on sim insertion is enough Aug 31 15:38:49 from sim driver? Aug 31 15:39:07 no, from the voicecall atom Aug 31 15:39:18 we query the EFecc from the sim atom Aug 31 15:39:43 However, EFecc is always available, for modem specific ones we might have to wait until sim ready Aug 31 15:39:50 This area is fuzzy Aug 31 15:40:11 most likely the list is simply static Aug 31 15:40:20 And that's it Aug 31 15:43:46 en.wikipedia.org/wiki/Emergency_telephone_number says Aug 31 15:43:55 The GSM network can also update the list of well-known emergency numbers when the phone registers to it. Aug 31 15:44:44 so perhaps we make this a notification instead of a query Aug 31 15:45:03 Then its up to the driver to figure this out Aug 31 15:45:53 More than ever I want to do a GSM soft-modem Aug 31 15:46:10 3GPP totally failed to produce a workable TE-ME interface Aug 31 15:46:16 24.008 has Emergency Number List in LOCATION UPDATING ACCEPT Aug 31 15:47:21 Yeah, but even NITZ network name is not updated via an unsolicited notification Aug 31 15:47:30 so oFono has to resort to polling on ever cell change Aug 31 15:48:27 I'd push the polling to the driver Aug 31 15:48:48 what we will do is have our own operator db Aug 31 15:48:55 And skip the modem list entirely Aug 31 16:05:23 anyways, what about the CallOnGoing and EmergencyCallOnGoing properties for VCM? Aug 31 16:05:50 are they ok, or should the clients do with CallAdded/Removed? Aug 31 16:07:14 Let me stew on CallOnGoing, we just removed the Calls property Aug 31 16:07:28 So now you wanna put a variation of it back in ;) Aug 31 16:08:05 I'm OK with EmergencyCallOngoing though Aug 31 16:08:39 ok Aug 31 16:15:11 What is wrong with just an Emergency boolean property inside the call object? Aug 31 16:18:51 That could work as well actually, except there's only ever going to be 1 of them Aug 31 16:19:01 what was roughly the reason for the removal of Calls? Aug 31 16:19:27 Every time Calls was signaled, the app had to find the new call and call GetProperties Aug 31 16:19:40 So we made that explicit by using CallAdded(props) Aug 31 16:19:55 The bootstrap process was also nasty, since you had to GetProperties() on the main interface Aug 31 16:20:00 then once for each call Aug 31 16:20:06 Now you just do 1 round trip Aug 31 16:20:32 what does the bootstrap look like now? Aug 31 16:20:39 GetCalls() Aug 31 16:20:45 ah ok Aug 31 16:22:09 denkenz: I thought the only reason is that the UI does some extra markup. Otherwise they are the same to us. Aug 31 16:22:46 Well there's also the power management thingy Aug 31 16:23:05 If you're on an emergency call your battery should magically grow itself, etc Aug 31 16:23:24 I can see both being useful Aug 31 16:23:43 Lets see what ends up being better once someone actually puts up some code Aug 31 16:26:21 holtmann: In theory having Emergency bool on the call object is more powerful, since you get signaled about it with the CallAdded signal Aug 31 16:28:26 I would prefer doing it this way. It looks a lot simpler right now if I consider the Dialer and what we need it for. Aug 31 16:31:15 That is looking preferable to me as well right now Aug 31 16:34:17 Then lets do it like that until the dialer UI developer comes with a different use case. Aug 31 16:34:46 pessi: ^^^^^ **** ENDING LOGGING AT Wed Sep 01 02:59:57 2010