**** BEGIN LOGGING AT Thu Nov 12 14:27:36 2009
Nov 13 01:17:47 <denkenz> zhenhua: In sync_dialing_cb, can we only look for dialing/alerting calls ?
Nov 13 01:18:24 <denkenz> zhenhua: I don't like that you notify all calls with potentially mismatched indexes
Nov 13 01:18:55 <denkenz> zhenhua: So we can parse the clcc list, look for dialing/alerting calls and try to find dialing/alerting calls on our list
Nov 13 01:19:24 <denkenz> zhenhua: If exists, we copy the clip there, otherwise we create a new call with our ID and copy the clip into it
Nov 13 01:25:43 <zhenhua> denkenz: yeah. i know what you means.
Nov 13 01:26:06 <zhenhua> denkenz: actually, if we sort call by index. the algorithm is much similar with atmodem
Nov 13 01:26:38 <zhenhua> denkenz: so that, sync_dialing_cb may not be necessary and can be merged with clcc_poll_cb
Nov 13 01:27:15 <denkenz> Actually, if we do not merge it with clcc_poll we can handle your weird LG hardware
Nov 13 01:27:31 <denkenz> We simply ignore the indexes that CLCC reports, we're only interested in the dialing ones
Nov 13 01:28:39 <zhenhua> no probs, we can do that, i think
Nov 13 01:28:53 <zhenhua> just check call->status = 2 or 3
Nov 13 01:29:10 <denkenz> have a think what happens if the call rapidly progresses from dialing->alerting->active
Nov 13 01:29:17 <zhenhua> so how about clcc_poll_cb? still use my algorithm?
Nov 13 01:29:22 <denkenz> I guess worst case we lose clip information
Nov 13 01:29:40 <zhenhua> i use memcpy, why it will lose?
Nov 13 01:30:01 <denkenz> well suppose the AG dials and the call is auto accepted
Nov 13 01:30:10 <denkenz> Our CLCC results might show only active call
Nov 13 01:30:35 <zhenhua> so i still suggest to use my current implementation
Nov 13 01:30:56 <zhenhua> it works well. what's wrong? it is only a little bit slow.
Nov 13 01:31:16 <zhenhua> remember we create_call and this call into vd->calls
Nov 13 01:31:32 <zhenhua> so even werid LG HW, the call id is the same as ours
Nov 13 01:31:35 <denkenz> I don't want to rely on CLCC at all until we get multiparty calls
Nov 13 01:32:09 <zhenhua> me too. but you can see you must use CLCC to get phone number.
Nov 13 01:32:21 <denkenz> just for that its ok
Nov 13 01:32:31 <denkenz> But not for general call state synchronization
Nov 13 01:32:58 <denkenz> Also, your current sync uses call_compare
Nov 13 01:33:07 <zhenhua> i don't reply on CLCC. if no CLCC, then we guess one and it still works fine
Nov 13 01:33:09 <denkenz> So if the indexes are out of whack you're screwed
Nov 13 01:33:19 <zhenhua> impossible here
Nov 13 01:33:34 <zhenhua> because we just atd a new call
Nov 13 01:33:44 <zhenhua> so the index must be same as us.
Nov 13 01:33:59 <zhenhua> how do you think the index will be changed here
Nov 13 01:34:01 <denkenz> yeah, but I want the same path used in multiple call case
Nov 13 01:34:30 <zhenhua> nop. in my case. ;)
Nov 13 01:34:45 <zhenhua> that's why i seperate sync_dialing with clcc_poll
Nov 13 01:35:04 <zhenhua> anyway, you can argue that and put atmodem algorithm here
Nov 13 01:35:29 <zhenhua> the reason is simple, handle werid index stuff.
Nov 13 01:35:30 <denkenz> I'm not arguing anything, I just want this to make sense after 6 months
Nov 13 01:36:07 <zhenhua> i know
Nov 13 01:36:17 <denkenz> By then we'll be wondering wtf sync call is for and why its doing nearly the same thing as poll_clcc
Nov 13 01:36:41 <zhenhua> what is 'wtf' stands for?
Nov 13 01:36:50 <denkenz> what the f...
Nov 13 01:37:22 <zhenhua> add comments?
Nov 13 01:37:57 <zhenhua> anyway, i don't have better solution for LG case.
Nov 13 01:38:10 <zhenhua> and even CHLD=1x, 2x. I think we can handle that
Nov 13 01:38:25 <denkenz> that's my point, make sync_dial only look for dialed calls
Nov 13 01:38:26 <zhenhua> by record another GSList *remote_calls.
Nov 13 01:38:28 <denkenz> Ignore the rest
Nov 13 01:38:40 <denkenz> That will work for all cases
Nov 13 01:39:13 <zhenhua> ok. that's simple
Nov 13 01:39:25 <zhenhua> let me do a little change and let u review
Nov 13 01:39:41 <zhenhua> i just check whether oc->call is in the clcc result
Nov 13 01:39:53 <zhenhua> because oc->call is points to the new dialing call
Nov 13 01:40:10 <zhenhua> is that ok?
Nov 13 01:40:32 <denkenz> that should work for now
Nov 13 01:41:01 <zhenhua> but still, you need while loop to know a new call dialing from AG, not HF
Nov 13 01:41:05 <denkenz> though ideally I wanna get rid of that call variable
Nov 13 01:41:18 <denkenz> exactly ;)
Nov 13 01:41:30 <zhenhua> to me, it's good. why not.
Nov 13 01:41:40 <zhenhua> i will rename it to active_call.
Nov 13 01:41:48 <zhenhua> so it's more meaningful.
Nov 13 01:41:53 <denkenz> Trust me, your code will be much more readable when you get rid of it
Nov 13 01:42:02 <denkenz> Longer, maybe, but more readable ;)
Nov 13 01:42:49 <zhenhua> no, it's more efficent than you use g_slist_find_custom.;)
Nov 13 01:43:07 <denkenz> we have a max of 7 calls in the system
Nov 13 01:43:23 <denkenz> who the hell cares 
Nov 13 01:43:56 <zhenhua> remember your code is running on MID, not x86
Nov 13 01:44:05 <zhenhua> why not.
Nov 13 01:44:07 <denkenz> MID is still x86
Nov 13 01:44:14 <zhenhua> ok, not C2D
Nov 13 01:44:33 <denkenz> And trust me, that is not where the performance bottleneck is
Nov 13 01:44:41 <zhenhua> ...
Nov 13 01:45:04 <zhenhua> no. i won't give up on that.
Nov 13 01:45:54 <denkenz> Just try it, that variable gets completely silly once you have mpty calls
Nov 13 01:46:29 <zhenhua> i know it's not useful for mpty call. but still use in 3-ways calls.
Nov 13 01:46:45 <zhenhua> do we have case to release held call in 3-way calls?
Nov 13 01:47:16 <denkenz> case?
Nov 13 01:47:59 <zhenhua> i means will upper dialer ask to release the held call in a 3way calls.
Nov 13 01:48:35 <denkenz> strictly speaking it can 
Nov 13 01:50:06 <zhenhua> okay. then i can handle it now.
Nov 13 01:50:48 <denkenz> so after that I want 3way calls with no CLCC polling
Nov 13 01:50:55 <denkenz> Can we do that or are there issues?
Nov 13 01:52:16 <zhenhua> we need CLCC. for example, if any call is released by remote. how can u know which line is off?
Nov 13 01:52:21 <zhenhua> you must poll clcc
Nov 13 01:52:34 <denkenz> well, your will get a callheld=0
Nov 13 01:52:36 <denkenz> or call=0
Nov 13 01:52:40 <denkenz> So you still know
Nov 13 01:53:00 <zhenhua> you only know the status is changed, but don't know exactly which line
Nov 13 01:53:20 <denkenz> Umm, yes you do
Nov 13 01:53:28 <denkenz> Remember, just 1 active 1 held 1 waiting
Nov 13 01:53:51 <zhenhua> yes. now i know that.
Nov 13 01:55:46 <denkenz> so call=1, callsetup=1 -> callsetup=0 the waiting call released
Nov 13 01:55:58 <denkenz> call=1, callsetup=1 -> call=0, active call is released
Nov 13 01:56:22 <denkenz> What cases don't work?
Nov 13 01:57:07 <zhenhua> err...wait, let me think
Nov 13 01:59:06 <zhenhua> if two calls, active and held.
Nov 13 01:59:17 <zhenhua> how do you know which is released after call=0
Nov 13 01:59:57 <denkenz> callheld still remains 1 -> active
Nov 13 02:00:51 <zhenhua> and for your case, what if i dialing out a call, then callsetup = 2 or 3
Nov 13 02:01:05 <zhenhua> and then the waiting call is released and callsetup become 0
Nov 13 02:01:32 <denkenz> Can't have dialing + waiting AFAIK
Nov 13 02:01:50 <zhenhua> still, not quite sure...
Nov 13 02:02:09 <denkenz> I think its possible, that is how most cheapo headsets work more than likely
Nov 13 02:03:41 <zhenhua> anyway, clcc is the safe and conservative way
Nov 13 02:03:57 <zhenhua> without clcc, the things become more complex.
Nov 13 02:03:57 <denkenz> Heh, not really
Nov 13 02:04:03 <denkenz> CLCC is optional
Nov 13 02:04:08 <zhenhua> no.
Nov 13 02:04:28 <zhenhua> in HFP 1.5 it is mandatory
Nov 13 02:05:07 <zhenhua> page 14 of spec
Nov 13 02:05:44 <denkenz> Ok, but as we've seen CLCC is useless on half of them
Nov 13 02:06:06 <denkenz> And the silly wait 2 seconds for CLCC or break the device is nuts
Nov 13 02:06:13 <denkenz> Way too slow
Nov 13 02:06:55 <zhenhua> slow?
Nov 13 02:07:10 <denkenz> 2 seconds is an eternity
Nov 13 02:07:22 <zhenhua> you have wait to see status changed. 
Nov 13 02:07:33 <zhenhua> maybe i should add poll_again like atmodem
Nov 13 02:07:51 <denkenz> Ok, I do this myself
Nov 13 02:07:53 <zhenhua> i know it's not good to wait 2 seconds
Nov 13 02:07:55 <denkenz> Waste of time
Nov 13 02:08:59 <zhenhua> so i will change it to use poll_again. is that ok?
Nov 13 02:09:20 <zhenhua> like poll every 1 second
Nov 13 02:09:59 <zhenhua> because 0.5 second is too short
Nov 13 02:23:31 <zhenhua> denkenz: still there?
Nov 13 02:26:34 <zhenhua> denkenz: for sync_dialing_cb, i could not change to use vd->call and compare this call.
Nov 13 02:27:12 <zhenhua> denkenz: think about one case. vd->call points to an active call already and user dial a new call from AG.
Nov 13 02:27:47 <zhenhua> denkenz: because we know nothing of new call, if use vd->call, we're screwed.
**** ENDING LOGGING AT Fri Nov 13 02:59:57 2009