**** BEGIN LOGGING AT Mon Nov 16 02:59:56 2009
Nov 16 17:07:23 <denkenz> holtmann: Can you test the MBM plugin on your F3507 when you have a chance?
Nov 16 18:13:30 <holtmann> denkenz: Have you applied all patches?
Nov 16 18:14:33 <denkenz> holtmann: All the ones I was gonna take
Nov 16 18:15:10 <denkenz> holtmann: On second thought, which patches?
Nov 16 18:16:50 <denkenz> I only see the doc one from Martin
Nov 16 18:20:45 <holtmann> Didn't he send some other ones.
Nov 16 18:23:03 <denkenz> Yeah, I didn't take them and did my own fixes
Nov 16 18:23:11 <denkenz> I asked him if he had any issues and he said no
Nov 16 18:23:23 <denkenz> So I've no idea whats going on
Nov 16 18:26:44 <holtmann> Seems we have to wait a little bit until we can sync. However let me see if I find time to play with it.
Nov 16 18:26:51 <holtmann> Your f36xx is still crashing?
Nov 16 18:27:12 <denkenz> yeah I gave up on it, twice
Nov 16 18:28:13 <denkenz> If I have time this week I might try to make the HSO hardware work
Nov 16 18:28:24 <denkenz> Since its literally 3 commands to make it work
Nov 16 18:29:01 <holtmann> That is not good. No idea what is wrong with that hardware. And more funny that it does work with ConnMan.
Nov 16 18:29:25 <denkenz> I don't see how
Nov 16 18:29:31 <denkenz> It crashes for me in minicom
Nov 16 18:29:49 <denkenz> Maybe the one I have is just faulty
Nov 16 18:30:36 <denkenz> It also crashes under ZTerm in Mac OS X
Nov 17 00:34:03 <zhenhua> denkenz: there?
Nov 17 00:40:53 <denkenz> kinda
Nov 17 00:41:57 <zhenhua> oh. i just send reply to the ML
Nov 17 00:43:31 <zhenhua> and i am not happy with release_with_status. it should not be so complex.
Nov 17 00:54:22 <denkenz> That one's tricky, we can't use callheld_1 for that one
Nov 17 00:54:37 <denkenz> And btw, release_with_status is simply list removal extended to multiple elements
Nov 17 00:54:43 <denkenz> Nothing really complicated about it
Nov 17 00:56:56 <zhenhua> okay
Nov 17 00:58:07 <denkenz> In fact, we can actually get rid of callheld_1 now that I think about it
Nov 17 00:59:02 <zhenhua> if you remove it, you need clcc
Nov 17 00:59:32 <denkenz> So there are four cases:
Nov 17 00:59:39 <denkenz> AG dials with an active call
Nov 17 00:59:43 <denkenz> AG Dials with a held call
Nov 17 00:59:48 <denkenz> HF dials with an active call
Nov 17 00:59:53 <denkenz> HF dials with a held call
Nov 17 00:59:59 <zhenhua> yes. you're right
Nov 17 01:00:27 <zhenhua> then?
Nov 17 01:00:28 <denkenz> We take care of AG cases and HF + active right now
Nov 17 01:01:20 <denkenz> Actually no, I got that backward
Nov 17 01:01:50 <denkenz> We don't take care of either dial + held case
Nov 17 01:01:56 <zhenhua> remember CHLD=1 could swap call
Nov 17 01:02:20 <zhenhua> so callheld=1 will also happen if you do CHLD=1
Nov 17 01:02:33 <denkenz> Yeah, but we take care of the waiting case
Nov 17 01:02:45 <denkenz> waiting->active, active->held
Nov 17 01:03:18 <zhenhua> i know. my point is we should use clcc
Nov 17 01:03:22 <zhenhua> in this case.
Nov 17 01:03:50 <denkenz> You might be right, lets think this through though
Nov 17 01:04:06 <denkenz> Can't we ignore callheld=1 when dialing call exists?
Nov 17 01:04:15 <zhenhua> only for callheld=1, other 0 or 2 is fine.
Nov 17 01:04:38 <zhenhua> if the call is dialing from AG, how do you that call exist
Nov 17 01:04:57 <denkenz> we do get callsetup=2, what order though
Nov 17 01:06:23 <zhenhua> i don't wanna to rely on callsetup=2
Nov 17 01:06:26 <denkenz> So we can actually do this, if no active calls exist, then ignore callheld=1
Nov 17 01:06:42 <zhenhua> maybe this callsetup=2 is for another call that failed to dial out
Nov 17 01:07:44 <zhenhua> anyway, i need more think about this.
Nov 17 01:08:04 <denkenz> See if that works, if no active && no waiting, ignore callheld=1
Nov 17 01:08:25 <denkenz> Then we don't even need the callheld_1 variable
Nov 17 01:08:53 <zhenhua> wait, can we have such case
Nov 17 01:09:08 <denkenz> yes, AG dials with a call on hold
Nov 17 01:09:08 <zhenhua> two held calls in mpty call, and another waiting call
Nov 17 01:09:21 <zhenhua> then we use CHLD=1 to swap call
Nov 17 01:09:50 <denkenz> CHLD=1 doesn't swap
Nov 17 01:09:58 <denkenz> CHLD=1 will accept the waiting call and place it into active
Nov 17 01:10:35 <zhenhua> sorry. swap should be CHLD=2.
Nov 17 01:10:49 <zhenhua> hmm...it maybe work.
Nov 17 01:11:10 <denkenz> I think it'll work actually
Nov 17 01:11:26 <denkenz> I'm too tired to guarantee it, but it should
Nov 17 01:11:39 <denkenz> That way we can throw away the gboolean hack
Nov 17 01:11:49 <zhenhua> i know.
Nov 17 01:12:10 <zhenhua> but i think current code is more complex.
Nov 17 01:12:41 <zhenhua> we have many if else and depents on indicator order
Nov 17 01:13:02 <denkenz> I don't disagree, but I tried not to depend on indicator order
Nov 17 01:13:51 <denkenz> However, the logic should handle broken devices and not need to poll most of the time
Nov 17 01:14:36 <zhenhua> the only advance is to save poll times here.
Nov 17 01:15:07 <denkenz> and battery
Nov 17 01:15:18 <zhenhua> and in clcc_poll_cb, new call should never happen
Nov 17 01:15:38 <denkenz> Again, I'm willing to scrap all of this if it doesn't work and go back to straight polling
Nov 17 01:16:18 <zhenhua> one question
Nov 17 01:16:24 <zhenhua> like broken LG,
Nov 17 01:16:33 <zhenhua> it has no response after CHLD=1, or 2.
Nov 17 01:16:47 <zhenhua> i means no indicator update.
Nov 17 01:17:20 <zhenhua> i am afraid other broken device have the same behavior
Nov 17 01:17:56 <denkenz> Remember, we're targeting fancy car kits here
Nov 17 01:18:47 <denkenz> Hopefully the devices used will be on some whitelist
Nov 17 01:19:03 <zhenhua> hope too.
Nov 17 01:19:13 <denkenz> Otherwise, maybe we add 'Type' attribute to BlueZ gateway as a hint to oFono
Nov 17 01:19:28 <denkenz> so we can set necessary driver quirks / choose different driver
Nov 17 01:19:40 <zhenhua> pass it through vendor
Nov 17 01:19:54 <denkenz> For those devices we might simply never enable CHLD1, 2, etc
Nov 17 01:20:41 <denkenz> The protocol is just *bad*, horribly so
Nov 17 01:20:44 <zhenhua> why you remove check about CLCC
Nov 17 01:20:57 <zhenhua> i remember i have some checks.
Nov 17 01:21:08 <denkenz> As you pointed out, that support is mandatory
Nov 17 01:21:31 <zhenhua> okay
Nov 17 01:22:23 <zhenhua> OK. that's all my parts. you may have a good sleep earlier.
Nov 17 01:23:44 <denkenz> Did you do much testing btw, I assume you've done alot since you found a few tricky issues
Nov 17 01:24:06 <zhenhua> of course i did
Nov 17 01:24:29 <denkenz> Other than the ones reported, does it work well?
Nov 17 01:24:48 <zhenhua> yeah. it works well.
Nov 17 01:25:09 <zhenhua> do you have device to test hfp?
Nov 17 01:25:30 <denkenz> Yeah I've my iPhone, Sony Ericsson 
Nov 17 01:25:36 <denkenz> Maybe few others
Nov 17 01:25:54 <zhenhua> i have a test iPhone.
Nov 17 01:25:56 <denkenz> I haven't had time to do it seriously though, so I'm glad you did all the testing for me
Nov 17 01:26:03 <denkenz> :)
Nov 17 01:26:13 <zhenhua> that's the job.;)
Nov 17 01:26:28 <denkenz> I spent an hour on Friday with AT&T trying to get them to enable mpty on my account
Nov 17 01:26:37 <zhenhua> maybe i will first draw a flow graph.
Nov 17 01:26:40 <denkenz> So much of the testing time got cut :)
Nov 17 01:27:19 <denkenz> That's a good idea
Nov 17 01:27:25 <zhenhua> if in china, you need wait a month to get mpty enable...
Nov 17 01:27:58 <zhenhua> and i am lucky to enable it by the end of oct...
Nov 17 01:28:40 <denkenz> yikes
Nov 17 01:28:44 <denkenz> btw, http://www.mcpc-jp.org/news/pdf/tr002v15.pdf
Nov 17 01:29:06 <denkenz> That one covers a few more cases not in the spec
Nov 17 01:29:22 <denkenz> And tells of other potential bad implementations :)
Nov 17 01:29:38 <zhenhua> ok. i will read it today.
Nov 17 01:30:03 <zhenhua> why it is still a draft
Nov 17 01:30:16 <zhenhua> no final version yet?
Nov 17 01:30:20 <denkenz> no idea, something I came by during my search
Nov 17 01:30:27 <denkenz> Maybe there's more up to date versions
Nov 17 01:31:12 <zhenhua> i will find more if could.
**** ENDING LOGGING AT Tue Nov 17 02:59:56 2009