**** BEGIN LOGGING AT Wed Oct 28 02:59:58 2009
Oct 28 16:32:36 <sabotage> denkenz: ping
Oct 28 16:32:53 <denkenz> sabotage: pong
Oct 28 16:33:09 <sabotage> o.o.VoiceCallManager.Dial question...
Oct 28 16:33:22 <sabotage> appears to be returning an already existing path
Oct 28 16:33:39 <sabotage> is this an at_modem/phonesim bug
Oct 28 16:33:55 <denkenz> when you make a second call right?
Oct 28 16:34:00 <denkenz> I think I saw this before
Oct 28 16:34:01 <sabotage> yeah
Oct 28 16:34:25 <denkenz> let me look, I should have a fix soon
Oct 28 16:34:27 <sabotage> whereas, propchanged on call manager reports valid paths
Oct 28 16:34:49 <sabotage> but I can't, dont want to wait for call manager prop change sigs
Oct 28 16:34:51 <sabotage> ok
Oct 28 16:35:48 * sabotage wonders if a fix will materialize in time for him to use it in todays release or does he need to hack a workaround?
Oct 28 16:36:25 <sabotage> (i.e. test if path == exising, and if so, modify it to increment by one)
Oct 28 16:36:29 <sabotage> X(
Oct 28 16:36:35 * sabotage shivers at the thought
Oct 28 16:37:27 <sabotage> sorry for the late notice, but I was chasing other, more fundamental issues and only discovered this last night (this morning) around 1am
Oct 28 16:37:40 <sabotage> while deep testing multi call handling
Oct 28 16:45:55 <denkenz> yeah, I saw this yesterday and wanted to fix it
Oct 28 16:46:02 <denkenz> but was in the middle of doing something else
Oct 28 16:46:24 <sabotage> sure thing... 
Oct 28 16:47:05 <sabotage> I was just digging deeper into multi-call state management and testing when I noticed this
Oct 28 16:47:51 <sabotage> it seems to get set correctly by the time the VCM send the PropertyChanged signal
Oct 28 16:48:05 <denkenz> So here's what happens
Oct 28 16:48:20 <sabotage> so it looks like a timing issue with callbacks?
Oct 28 16:48:25 <denkenz> You have an active call, and dial a new one
Oct 28 16:48:26 <sabotage> oh
Oct 28 16:48:33 * sabotage waits to be schooled
Oct 28 16:48:57 <denkenz> so two things can happen, ofono core can get notified of the new call first, and then dial_callback gets called
Oct 28 16:49:07 <denkenz> Or dial_callback gets called first
Oct 28 16:49:37 <denkenz> If dial_callback is called first, we search to see if the notification of the new call already happened
Oct 28 16:49:45 <denkenz> We search for dialing/alerting/active calls
Oct 28 16:50:06 <denkenz> Problem is, we already had an active call before, so it is picking up that one :)
Oct 28 16:50:36 <sabotage> oops
Oct 28 16:50:51 <sabotage> yeah, thats exacly what I was seeing
Oct 28 16:50:57 <sabotage> all call props were the same
Oct 28 16:51:32 <sabotage> if I used 199 to simulate an incoming call, all was fine, since core was sending me the notice
Oct 28 16:51:52 <denkenz> Yah, its only a problem if you dial then dial again
Oct 28 16:51:59 <denkenz> If you put on hold first, it'll work
Oct 28 16:52:11 <sabotage> so I could have a dial iniatiated and a signal created call, but not two dial initiated ones
Oct 28 16:52:47 <sabotage> hmm, I am not putting it on hold explicitly
Oct 28 16:52:54 <denkenz> The problem really is that the spec allows dialing with an active call
Oct 28 16:52:58 <sabotage> was letting ofono manage that state for me
Oct 28 16:53:20 <denkenz> So it gets a bit tricky to figure out what happened :)
Oct 28 16:53:26 <sabotage> so if I hold first, you think I should get a valid path
Oct 28 16:53:30 <denkenz> yes
Oct 28 16:53:34 <sabotage> if so, I could workaround it for now
Oct 28 16:53:44 <sabotage> ok
Oct 28 16:53:48 <sabotage> will see what happens
Oct 28 16:53:55 <denkenz> Let me think of a fix, it shouldn't be that hard, but I need to think it through
Oct 28 16:54:05 <denkenz> For now holding the active call will do it
Oct 28 16:54:20 <sabotage> what will(is) the officially sanctioned *ofono* recomendation on how to do this?
Oct 28 16:54:20 <denkenz> And it is a safer choice anyway, some modems don't let you dial while a call is active
Oct 28 16:54:28 <sabotage> kk
Oct 28 16:54:43 * sabotage hurries back to fix bug and cut release
Oct 28 19:40:21 <denkenz> sabotage: The problem should be now fixed upstream
Oct 28 19:40:35 <sabotage> denkenz: coolio...
Oct 28 19:40:53 <sabotage> your workaround sugggestion worked BTW...
Oct 28 19:40:54 <sabotage> thanks
Oct 28 19:43:38 <denkenz> no prob
Oct 28 20:04:02 <denkenz> holtmann: In terms of performance, does textfile* stuff from BlueZ offer any advantages over g_key_file?
Oct 28 20:05:15 <holtmann> It might, but I would not use it again.
Oct 28 20:08:19 <denkenz> oh?
Oct 28 20:11:56 <denkenz> holtmann: Btw, what was the reason you didn't want to keep GPRS attached while roaming?
Oct 28 20:12:18 <holtmann> Depends on how the invoicing is setup.
Oct 28 20:12:33 <holtmann> If it is based on GRPS attach or something stupid, you might use all your minutes.
Oct 28 20:12:40 <holtmann> Also you could potentially save power.
Oct 28 20:13:16 <denkenz> holtmann: True, but you are failing to realize that this only works for proper voice + data devices
Oct 28 20:13:34 <denkenz> Data-only devices won't ever register to CSD network
Oct 28 20:14:17 <holtmann> In case of data only devices that is fine, but most data only devices do register to CSD and at least allow SMS.
Oct 28 20:14:58 <denkenz> So the question is, do we need to have the driver tell ofono what kind of device it is?
Oct 28 20:17:08 <holtmann> We might wanna add a quirk for data only devices to the GPRS atoms.
Oct 28 20:17:48 <denkenz> In which case we ignore RoamingAllowed and always attach?
Oct 28 20:18:11 <holtmann> Most likely yes.
Oct 28 20:19:10 <holtmann> denkenz: I removed more crap from phonesim.git. It will become a proper Qt app at some point. I have only a few useless headers left.
Oct 28 20:19:37 <holtmann> And out of sudden the moc stuff makes more sense. Whoever build that initial tree had no idea what they were doing.
Oct 28 20:20:09 <denkenz> The Qtopia tree was strange too
Oct 28 20:20:23 <denkenz> It wasn't properly ported to Qt 4.x from Qt 2.x
Oct 28 20:21:32 <denkenz> And you should be able to automake-ize the thing
Oct 28 20:21:56 <denkenz> Just have to grep for Q_OBJECT and moc the files
Oct 28 20:22:01 <holtmann> I am close now.
Oct 28 20:22:11 <denkenz> Then take care of running uic on the .ui files
Oct 28 20:29:12 <holtmann> qtopiaglobal.h and qtopiaipcmarshal.h are the only ones that are left now.
Oct 28 20:29:19 <holtmann> And they are actually used.
Oct 28 20:29:40 <denkenz>  qtopiaipcmarshal, funny
Oct 28 20:29:45 <denkenz> where?
Oct 28 20:30:42 <denkenz> Feel free to cut the serialize/deserialize functions
Oct 28 20:30:53 <denkenz> We don't use IPC inside phonesim, so they can easily go
Oct 28 20:31:17 <holtmann> For some of the SIM and SMS stuff.
Oct 28 20:31:44 <holtmann> You might wanna have a look. The rest of the repo is pretty clean now.
Oct 28 20:50:46 <denkenz> Fuck I hate g++ and its cryptastic messages
Oct 28 21:02:54 <denkenz> holtmann: Ok I got rid of qtopiaipcmarshal for you
Oct 28 21:09:16 <denkenz> holtmann: And now qtopiaglobal.h is gone
Oct 28 21:09:19 <denkenz> holtmann: Have fun
Oct 29 00:25:17 <denkenz> zhenhua: hfp_release_specific is meant to work only on active calls / dialing / alerting calls, correct?
Oct 29 00:28:04 <zhenhua> denkenz: let me check
Oct 29 00:28:52 <zhenhua> should include incoming call
Oct 29 00:28:55 <zhenhua> i think
Oct 29 00:29:17 <zhenhua> how about held call?
Oct 29 00:29:23 <denkenz> no, the core calls hangup for incoming calls
Oct 29 00:30:43 <denkenz> According to HFP spec +CHUP only terminates the currently active call
Oct 29 00:30:48 <zhenhua> for hfp, they all use CHUP in standard
Oct 29 00:31:10 <denkenz> Not held, unfortunately
Oct 29 00:32:08 <zhenhua> if core hangup incoming call by invoking hangup, i am not sure whether it's correct
Oct 29 00:32:26 <zhenhua> because use 0x3f as parameter, which means you hangup all calls 
Oct 29 00:32:36 <zhenhua> but actually, it's not correct
Oct 29 00:33:12 <zhenhua> now i use +CIEV back status to verify it.
Oct 29 00:33:31 <zhenhua> callsetup = 0 then i know the call is released
Oct 29 00:33:41 <denkenz> Hangup can only be used to hangup an incoming call
Oct 29 00:33:48 <denkenz> If there's an incoming call, there are no other calls
Oct 29 00:34:04 <denkenz> So 0x3f is correct in that case
Oct 29 00:35:06 <denkenz> Note that the specs differ here, 27.007 is fairly ambiguous as to what CHUP does
Oct 29 00:35:07 <zhenhua> okay, i mean vd->call already point to it.
Oct 29 00:35:22 <denkenz> Most likely it causes all held and active calls (except waiting) to be released
Oct 29 00:35:41 <zhenhua> in Hfp, that's not the case
Oct 29 00:35:50 <zhenhua> it should only release current one
Oct 29 00:36:05 <denkenz> Actually it can release a multiparty call to
Oct 29 00:36:09 <denkenz> too even
Oct 29 00:36:56 <zhenhua> really?
Oct 29 00:37:21 <denkenz> Yes, If you have 4 parties on a mpty call and it is active, all 4 will be released
Oct 29 00:37:29 <denkenz> mpty is treated as a single call
Oct 29 00:38:14 <denkenz> Yes, so 27.007 is freaking ambiguous, it doesn't say what the behavior is
Oct 29 00:38:26 <denkenz> This is why the core doesn't use CHUP much
Oct 29 00:38:42 <zhenhua> fortunately it's not for hfp
Oct 29 00:38:59 <zhenhua> when i test manager_hangup_all, it works and hangup each call one by one. :)
Oct 29 00:39:10 <zhenhua> okay, i got your point
Oct 29 00:39:58 <zhenhua> but you know, for hfp, if AG doesn't support enhanced call control, it only has CHUP to hang up calls
Oct 29 00:40:06 <denkenz> I need to find myself a copy of V250
Oct 29 00:40:41 <zhenhua> what's it
Oct 29 00:41:05 <denkenz> The spec that defines ATA ATH ATD
Oct 29 00:41:14 <denkenz> I never could nail down what ATH does :P
Oct 29 00:41:34 <zhenhua> okay, i will try if i can find it. :)
Oct 29 00:42:09 <zhenhua> why we have list_calls, but it never be used in core
Oct 29 00:42:59 <zhenhua> and i have another question about decode_at_error in atutil.c
Oct 29 00:43:27 <zhenhua> it never parse error code from result, but assign as 0. error->error = 0;
Oct 29 00:45:15 <denkenz> Cuz I'm lazy
Oct 29 00:45:18 <denkenz> On both questions ;)
Oct 29 00:46:40 <zhenhua> okay, i will try to fix them and send patch when it's ready
Oct 29 00:47:05 <zhenhua> and what is swap_without_accept? i see isimodem supports it while atmodem doesn't
Oct 29 00:48:03 <zhenhua> another question is about CLCC
Oct 29 00:48:22 <zhenhua> if AG's phone does NOT support CLCC, when shall we report error/warning?
Oct 29 00:49:14 <zhenhua> i would prefer probe stage because CLCC is important
Oct 29 00:49:39 <zhenhua> if AG doesn't support CLCC, it could only dial single call not multicall
Oct 29 00:50:46 <zhenhua> if AG doesn't support CLCC, we will not register +CCWA notification and do not allow him to dial another call during an existing call
Oct 29 00:50:52 <zhenhua> is that correct?
Oct 29 00:59:53 <denkenz> swap_without_accept -> some vendors support this
Oct 29 00:59:57 <denkenz> there is no standard command
Oct 29 01:00:03 <denkenz> and running CLCC at init is fine
Oct 29 01:00:30 <denkenz> If we can't find a more clever way to figure out what's going on, that's what we'll have to do
Oct 29 01:02:33 <zhenhua> in mpty call, if any line hangup the call by remote, you don't know which line since only callheld=0 or callsetup=0 is returned
Oct 29 01:02:43 <zhenhua> so you must query the status by CLCC
Oct 29 01:03:02 <zhenhua> the logic will not be correct without CLCC i think.
Oct 29 01:04:06 <zhenhua> even in single call, if AG dial out a call from phone, not from oFono, we don't know what happened, in that case, we also need CLCC to query that
Oct 29 01:08:20 <zhenhua> another question is related hfp_dial
Oct 29 01:08:41 <zhenhua> in atmodem, we can use +COLP to get call number and type from atd_cb
Oct 29 01:09:24 <zhenhua> but we don't have it in hfp, can we directly pass ofono_phone_number from hfp_dial to atd_cb
Oct 29 01:10:12 <zhenhua> because we know the exact phone number and type already
Oct 29 01:50:07 <zhenhua> denkenz: no comments?
Oct 29 02:01:59 <denkenz> Well we don't really
Oct 29 02:02:20 <denkenz> Besides, the core synthesizes the anyway
Oct 29 02:03:03 <zhenhua> sorry, not catch you
Oct 29 02:03:36 <denkenz> core atom already stuffs the phone number into the call
Oct 29 02:03:51 <denkenz> Only if COLP is actually provided does it update the number
Oct 29 02:04:37 <denkenz> There's nothing wrong with hfp driver doing this, but only if it is actually necessary
Oct 29 02:04:52 <zhenhua> yes, i think it's necessary
Oct 29 02:05:19 <zhenhua> because no other way to get phone number without CLCC
Oct 29 02:05:44 <zhenhua> i am trying to save one more CLCC to fill phone number when we create_call
**** ENDING LOGGING AT Thu Oct 29 02:59:57 2009