**** BEGIN LOGGING AT Wed Apr 20 02:59:58 2011
Apr 20 13:42:50 <Gzajac> denkenz: ping
Apr 20 13:47:02 <denkenz> Gzajac: pong
Apr 20 13:48:27 <Gzajac> denkenz: Hi, I finished fixing Gustavo patches into ConnMan to request a private network whenever a data call is needed.
Apr 20 13:48:53 <Gzajac> Now I have to commit a ConnMan plugin into oFono
Apr 20 13:49:09 <Gzajac> this plugin involved some new functions into emulator
Apr 20 13:49:10 <denkenz> yep
Apr 20 13:49:35 <Gzajac> however there are some pending patches concenring escape sequence detection
Apr 20 13:49:42 <Gzajac> on my local branch
Apr 20 13:49:53 <Gzajac> if I commit new patches on emulator
Apr 20 13:50:01 <Gzajac> there will some confilcts on your side?
Apr 20 13:50:29 <denkenz> yes, you have two options
Apr 20 13:50:58 <denkenz> git format-patch -26 for your escape sequence patches, then git reset --hard HEAD~26
Apr 20 13:51:09 <denkenz> That will just reset your tree to before these existed
Apr 20 13:51:13 <denkenz> Then proceed as normal
Apr 20 13:51:23 <denkenz> Or, work on the new changes
Apr 20 13:51:38 <denkenz> and then git rebase --interactive HEAD~26+n
Apr 20 13:51:46 <denkenz> and move the new patches backwards
Apr 20 13:51:51 <Gzajac> ok
Apr 20 13:51:52 <denkenz> Then just send that subset
Apr 20 13:52:25 <Gzajac> I have another question
Apr 20 13:52:35 <Gzajac> conerning PPP stack in oFono
Apr 20 13:52:44 <Gzajac> if I modify ppp_net.c
Apr 20 13:52:56 <Gzajac> to use ConnMan file descriptor
Apr 20 13:53:18 <Gzajac> there will be a problem for gsmdial
Apr 20 13:53:43 <Gzajac> I mean gsmdial won't be able to be used
Apr 20 13:54:14 <denkenz> you need to add a new constructor for ppp that takes an existing fd
Apr 20 13:54:59 <denkenz> So in effect you have two ways, the legacy one and the connman one
Apr 20 13:55:23 <Gzajac> ok
Apr 20 13:56:44 <Gzajac> so I should keep  2 implementations into ppp_net and test the fd passed by connman:
Apr 20 13:56:44 <Gzajac> if -1 I use the old routine (for gsmdial)
Apr 20 13:56:44 <Gzajac> if > 0 I use connman fd (for emulator)
Apr 20 13:57:37 <denkenz> no, use two g_at_ppp constructors
Apr 20 13:58:28 <denkenz> e.g. g_at_ppp_new_full()
Apr 20 13:58:35 <denkenz> or g_at_ppp_new_with_fd()
Apr 20 13:58:46 <Gzajac> I see
Apr 20 13:58:48 <Gzajac> ok
Apr 20 18:09:31 <fdanis> denkenz: ping
Apr 20 18:14:26 <denkenz> fdanis: pong
Apr 20 18:15:24 <fdanis> did you take a look to v4 of +CHUP ?
Apr 20 18:15:40 <denkenz> yes, its fine and pending on my next push
Apr 20 18:15:48 <fdanis> ok, thanks
Apr 20 18:19:00 <fdanis> about RING, if I understand correctly, I should stop the timer only when callsetup goes to inactive, or should I check for waiting call at each callsetup change ?
Apr 20 18:20:01 <denkenz> The current logic only bites you if callsetup goes to dialing / alerting
Apr 20 18:20:43 <denkenz> we have to be a bit careful how we set the indicators in those cases as well
Apr 20 18:23:15 <fdanis> this can only happens with a waiting call (not an incoming), right ?
Apr 20 18:24:46 <fdanis> is it possible to have incoming and outgoing calls at same time on the network ?
Apr 20 18:28:38 <denkenz> no
Apr 20 18:28:43 <denkenz> only waiting + dialing
Apr 20 18:34:47 <fdanis> so it could be ok to check waiting call when ring timer is running before stopping it
Apr 20 18:41:29 <denkenz> likely, yes
Apr 20 18:41:48 <denkenz> However, the problem is also that a dialing call can be canceled or a waiting call can go away
Apr 20 18:42:00 <denkenz> And how we set the indicator in those cases is tricky
Apr 20 18:42:46 <denkenz> Maybe we should let the voicecall atom do this for us
Apr 20 18:43:00 <denkenz> since it knows exactly when an incoming/waiting call goes away
Apr 20 18:45:21 <fdanis> currently in voicecall, the indicators are set for each call state change depending on the whole call list, so I think there is no problem
Apr 20 18:45:21 <fdanis> if the dialing call is canceled the callsetup will go back to waiting
Apr 20 18:45:21 <fdanis> if the waiting call go away, the ring timer should be stopped
Apr 20 18:47:33 <denkenz> Then we might have to introduce an explicit end call setup function to emulator
Apr 20 18:47:48 <denkenz> because the indicator will not be set in the case waiting call goes away
Apr 20 18:49:11 <denkenz> likely no headset in the world gets this part right though ;)
Apr 20 18:49:39 <fdanis> yes, but if we check if a waiting call exists for other callsetup state (!incoming) we can stop the timer without a new API
Apr 20 18:50:55 <fdanis> This just need to change precedence of callsetup status in notify_emulator_call_status() (voicecall.c) so waiting are less important than dialing/alerting
Apr 20 18:51:21 <fdanis> and not stop ring timer if a waiting call exists
Apr 20 18:54:53 <fdanis> I will send you a patch for this tomorrow
Apr 20 19:07:35 <fdanis> denkenz: about +CLIP, should I do same thing than in phone_and_clip_to_string() ?
Apr 20 19:07:35 <fdanis> It may be useful to move phone_and_clip_to_string() from voicecall.c to common.c, right ?
Apr 20 19:18:23 <denkenz> hmm, let me see
Apr 20 19:18:46 <denkenz> No, it is not really quite what you want
Apr 20 19:19:10 <denkenz> in case a number is withheld, report it as "", 128
Apr 20 19:19:58 <denkenz> Also, I'm not sure we can rely on indicators properly
Apr 20 19:20:16 <denkenz> if we have something like active + waiting -> active + dialing + waiting -> active + dialing
Apr 20 19:20:29 <denkenz> The indicator will not change
Apr 20 19:21:04 <denkenz> If you think you can, go for it, but if you see the code getting ugly, then we might need a slightly different approach
Apr 20 19:32:29 <fdanis> ok, I will try
Apr 20 19:32:31 <fdanis> I start to implement the +BLDN using a file to store the latest dialed number over ofono restart (like netreg settings).
Apr 20 19:32:31 <fdanis> Is it ok or should I use history plugin to retrieve latest dialed number ?
Apr 20 19:36:14 <denkenz> just storing it in voicecall settings is fine
Apr 20 19:39:28 <fdanis> ok, thanks
Apr 20 22:57:40 <balrog-k2n> i had a single segfault when playing with RoamingAllowed on MBM modem which was roaming.  segfault was when freeing the mms context when setting Powered=0 later, and i'm unable to reproduce it
Apr 20 22:57:49 <balrog-k2n> just mentioning because maybe it's something obvious
Apr 21 00:42:27 <denkenz> balrog-k2n: I think there's a meego bug filed against this
Apr 21 00:43:13 <denkenz> This might be related to the ppp tty being hung-up
Apr 21 00:43:58 <denkenz> I'm still too lazy to actually track this down, but likely this needs a similar tweak that Martin made in the huawei driver
**** ENDING LOGGING AT Thu Apr 21 02:59:58 2011