**** BEGIN LOGGING AT Mon Apr 11 02:59:57 2011
Apr 11 20:01:36 <Jeevaka> denkenz: ping
Apr 11 20:01:44 <denkenz> Jeevaka: pong
Apr 11 20:02:42 <Jeevaka> discussion is about emergency number list
Apr 11 20:03:34 <Jeevaka> if there is no numbers in EFecc, then we should only have the unionof(default, modem/network)
Apr 11 20:04:13 <denkenz> yep
Apr 11 20:04:44 <Jeevaka> as per the current implementation, we will have default_en_list_no_sim as well
Apr 11 20:06:43 <denkenz> hah, you're right
Apr 11 20:07:44 <denkenz> Guess we need that boolean after all
Apr 11 20:10:59 <Jeevaka> seems so
Apr 11 20:26:13 <denkenz> Jeevaka: I pushed a fix 857d2df
Apr 11 20:26:15 <denkenz> Please test
Apr 11 20:27:23 <Jeevaka> denkenz: consider that its taken care ;)
Apr 11 20:27:57 <Jeevaka> supplementary service notification has to be handled in ifx as well
Apr 11 20:28:49 <Jeevaka> generic atmodem already has this support. Replication of the same code doesnt look good
Apr 11 20:31:42 <denkenz> Just move CSSI/CSSU parsers to at_util maybe
Apr 11 20:31:42 <Jeevaka> MT related events can happen during the call, generic AT command doesnt have the call id parameter. So, how are we going to handle this or how is it handled?
Apr 11 20:32:29 <denkenz> We just guess, if there's an ambiguity we drop it on the floor
Apr 11 20:32:44 <denkenz> However, I don't believe Andras ever got those working anyway
Apr 11 20:33:19 <Jeevaka> currently, generic at driver just sends the call id as 0
Apr 11 20:33:50 <Jeevaka> it will work if there is only one call
Apr 11 20:34:18 <denkenz> exactly
Apr 11 20:34:28 <denkenz> That's just the limitation of AT commands
Apr 11 20:34:32 <denkenz> Maybe IFX can give us an ID
Apr 11 20:34:34 <Jeevaka> may be ll move the cssi to atatutik
Apr 11 20:34:57 <Jeevaka> atutil and introduce a vendor specifi URC with id
Apr 11 20:35:01 <Jeevaka> exactly
Apr 11 20:37:53 <Jeevaka> next item is about ctm
Apr 11 20:37:56 <Jeevaka> :)
Apr 11 20:40:25 <Jeevaka> Currently, we have a property in the TextTelephony interface to enable/disable/query the TTY status
Apr 11 20:41:01 <Jeevaka> do we need to provide a simial property for each voice call object?
Apr 11 20:45:04 <denkenz> I have no idea
Apr 11 20:50:00 <Jeevaka> eg: Settings application is used for enabling/disabling/query TTY property using TextTelephony interface whereas Dialer app relies on the TextTelephony property on the voicecall object to show something to the user during a call
Apr 11 20:52:06 <denkenz> Your guess is as good as mine
Apr 11 20:52:28 <denkenz> Sounds more useful to the audio engine
Apr 11 20:52:29 <holtmann> Jeevaka: In theory we need to expose a property that tells us that this call is a TTY call.
Apr 11 20:52:51 <holtmann> If and only if the call UI wants to show a difference.
Apr 11 20:52:59 <holtmann> Otherwise exposing this in AudioSettings is enough.
Apr 11 20:53:15 <denkenz> Whether this is done through an oFono property or not depends on what the audio streaming protocol is
Apr 11 20:53:26 <holtmann> Jeevaka: That is why I wanted to see the use case for TTY from a UI point of view.
Apr 11 20:53:54 <holtmann> So far nobody has answered the question on how the UI differs between TTY and non-TTY call.
Apr 11 20:55:31 <Jeevaka> holtmann: agree. may be I need to contact the respective UI project administrator
Apr 11 20:56:39 <Jeevaka> holtmann: most probably that will take some weeks or even months, you never know
Apr 11 20:57:39 <holtmann> We can do a lot of things here, but it all boils down to the description of the UI use cases and how they want to present TTY calls.
Apr 11 20:57:47 <holtmann> Until that is clear, no extra properties.
Apr 11 20:58:10 <holtmann> APIs that are not used are actually harmful.
Apr 11 20:59:04 <Jeevaka> ok
Apr 11 21:26:26 <balrog-k1n> now that i think of it shouldn't the Cancel and Release methods in agents be converted to signals?
Apr 11 21:26:49 <balrog-k1n> err perhaps not
Apr 11 21:26:55 <balrog-k1n> ignore me :)
Apr 11 21:28:53 <denkenz> lol
Apr 11 21:29:18 <holtmann> double lol
Apr 11 21:35:02 <balrog-k1n> is there are reason emulator doesn't support +COPS=?
Apr 11 21:38:18 <denkenz> Not supported in HFP
Apr 11 21:41:04 <balrog-k1n> oh
Apr 11 22:19:02 <Jeevaka> denkenz: pin
Apr 11 22:19:09 <Jeevaka> denkenz: ping*
Apr 11 22:19:16 <denkenz> yes?
Apr 11 22:19:16 <holtmann> AT+CPIN=1234
Apr 11 22:20:59 <Jeevaka> reason for resetting the flag inside first if loop in free_eim_ecc_numbers?
Apr 11 22:22:06 <denkenz> Efficiency, we only free the sim numbers with FALSE when we are about to set new sim eccs
Apr 11 22:22:20 <denkenz> so its avoiding resetting the flag and setting it
Apr 11 22:24:13 <Jeevaka> incase of sim refresh and nw list update, we will be relying on the sim_en_list instead of the flag 
Apr 11 22:24:21 <Jeevaka> is that ok?
Apr 11 22:27:06 <denkenz> yes, I don't want to switch eccs until the EFecc has been re-read
Apr 11 22:27:16 <denkenz> since otherwise you might have an incomplete list
Apr 11 22:27:27 <denkenz> its better to do this semi-atomically
Apr 11 22:27:35 <denkenz> Not like this will ever happen anyway
Apr 11 22:43:17 <Jeevaka> denkenz: failing in sim present -> sim removed scenario
Apr 11 22:43:36 <denkenz> oh?
Apr 11 22:43:54 <Jeevaka> may be we need to have the resetting of the flag outside
Apr 11 22:47:08 <denkenz> No, I'm just an idiot
Apr 11 22:49:08 <Jeevaka> dont get why we check vc->new_sim_en_list for existence and free sim_en_list
Apr 11 22:49:58 <denkenz> Try e9f12d7
Apr 11 22:51:27 <denkenz> As I said, I am an idiot ;)
Apr 11 22:53:26 <denkenz> We really need someone to add proper sim insertion / removal support to phonesim
Apr 11 22:56:51 <Jeevaka> hmm, may be i'll take it
Apr 11 23:11:57 <Jeevaka> sim insert/removal, efecc failure, no number in EFecc and network emergency number cases working fine
**** ENDING LOGGING AT Tue Apr 12 02:59:57 2011