**** BEGIN LOGGING AT Fri Oct 23 02:59:57 2009
Oct 23 03:11:03 <tmzt> holtmann: there is a driver for rndis that uses libusb and tun
Oct 23 03:11:15 <tmzt> also, it might want rndis_host, possibly with changes
Oct 23 05:05:04 <zhenhua> denkenz: how to enable example_history for hfp?
Oct 23 05:15:11 <denkenz> turn maintainer mode on
Oct 23 05:19:46 <zhenhua> look like it related with ofono_sim_add_ready_watch
Oct 23 05:20:14 <zhenhua> when power on modem, it will invoke modem_sim_ready and will have __ofono_history_probe_drivers
Oct 23 05:21:45 <zhenhua> the thing is when i debugging hfp voicecall, i see only one atom, OFONO_ATOM_TYPE_VOICECALL
Oct 23 05:21:50 <zhenhua> i cannot find OFONO_ATOM_TYPE_HISTORY atom
Oct 23 05:21:57 <zhenhua> i am debugging on that
Oct 23 05:28:14 <denkenz> Ah, history is only probed after sim ready
Oct 23 05:28:18 <zhenhua> the probem is in atmodem, drivers/atmodem/sim.c will register itself and then we probe example_history
Oct 23 05:28:19 <zhenhua> yes
Oct 23 05:28:37 <zhenhua> but we don't have it in hfp.
Oct 23 05:29:00 <denkenz> Hehe, yah the reason that is done is that history needs to be stored by IMSI
Oct 23 05:29:12 <denkenz> So we don't bother enabling history if IMSI is not known
Oct 23 05:29:22 <zhenhua> so now every call we have start time but don't have end time
Oct 23 05:29:57 <denkenz> eh? That isn't related to history
Oct 23 05:29:58 <zhenhua> any comments on this issue? 
Oct 23 05:30:18 <zhenhua> let me check
Oct 23 05:30:25 <denkenz> explain don't have 'end time'
Oct 23 05:30:45 <zhenhua> in ofono_voicecall_disconnected, we call __ofono_history_call_ended
Oct 23 05:31:14 <zhenhua> and then history_call_ended invoke example history call_ended cb
Oct 23 05:31:29 <denkenz> go on
Oct 23 05:31:45 <zhenhua> the example_history_call_ended display lots of message
Oct 23 05:31:55 <zhenhua> like To From, StartTime and EndTime
Oct 23 05:32:03 <zhenhua> so we don't have that
Oct 23 05:32:42 <zhenhua> when voicecall_set_call_status is invoked in voicecall.c
Oct 23 05:32:49 <zhenhua> we only emit StartTime signal to dbus
Oct 23 05:32:55 <zhenhua> but no EndTime signal
Oct 23 05:32:57 <zhenhua> why?
Oct 23 05:33:15 <denkenz> Cuz the application can get the EndTime anyway
Oct 23 05:33:25 <denkenz> by virtue of receiving the disconnected state ;)
Oct 23 05:33:26 <zhenhua> okay
Oct 23 05:33:52 <zhenhua> got u:). so now i list call history as a known issue.
Oct 23 05:34:03 <zhenhua> i want to send my patch to ML first. :)
Oct 23 05:34:26 <denkenz> Heh, its not an 'issue', it simply doesn't work until IMSI is known
Oct 23 05:34:28 <zhenhua> only single call is support now. multi call part needs more work
Oct 23 05:34:34 <zhenhua> ok
Oct 23 05:34:37 <denkenz> for HFP we might have to fake the IMSI by using the remote device bdaddr
Oct 23 05:35:22 <zhenhua> but where to store it? using SAP?
Oct 23 05:35:40 <denkenz> store what?
Oct 23 05:35:57 <zhenhua> call history
Oct 23 05:36:06 <denkenz> We don't care, its up to the plugin ;)
Oct 23 05:36:11 <zhenhua> okay
Oct 23 05:38:53 <zhenhua> and one thing
Oct 23 05:39:11 <zhenhua> i want to define current active call in voicecall
Oct 23 05:39:33 <zhenhua> which is better? using int call_id or struct ofono_voicecall *call
Oct 23 05:40:27 <denkenz> not sure, would have to look at it
Oct 23 05:40:40 <zhenhua> i am interesting why there's no g_free(call) in voicecall.c
Oct 23 05:40:55 <denkenz> driver or core?
Oct 23 05:41:00 <zhenhua> driver
Oct 23 05:41:10 <zhenhua> call is created in atd,
Oct 23 05:41:27 <zhenhua> in release call, i don't find g_free
Oct 23 05:41:52 <denkenz> It is released in poll_clcc or remove
Oct 23 05:42:41 <zhenhua> ok
Oct 23 05:42:49 <zhenhua> i find it.
Oct 23 21:36:51 <padovan> denkenz: I did the patch for netreg driver, it's on the ml.
Oct 23 21:37:28 <padovan> It applies on top of zhenhua patch for voicecall
Oct 23 21:48:19 <denkenz> padovan: Nice, I will look at it once I push out some pending changes
Oct 23 21:48:50 <padovan> Ok.
Oct 23 21:49:36 <denkenz> padovan: Can we make calls over HFP with those two patches?
Oct 23 21:50:48 <padovan> denkenz: Yes, I just did one here.
Oct 23 21:51:00 <denkenz> Awesome :)
Oct 23 21:51:02 <padovan> but I think only zhenhua patch is needed for that
Oct 23 21:51:11 <zhenhua1> padovan: i see your comments on ML. i think it's ag_mpty_feature is initialized in conditional branch 
Oct 23 21:51:51 <zhenhua1> so i need to have something like unsigned int ag_mpty_feature = 0. :)
Oct 23 21:52:15 <padovan> zhenhua1: yes, = 0 worked here.
Oct 23 21:52:24 <zhenhua1> ok. thank you.
Oct 23 21:52:57 <zhenhua1> but why i don't got such error even i have turned on maintainer mode and did distcheck
Oct 23 21:53:05 <padovan> zhenhua1: static void release_id(), why not inline?
Oct 23 21:53:32 <zhenhua1> padovan: it's reused from drivers/atmodem/voicecall.c
Oct 23 21:54:06 <denkenz> make sure you CFLAGS are set with optimization on
Oct 23 21:54:23 <denkenz> Btw, ag_mpty_feature always uses |=
Oct 23 21:54:28 <zhenhua1> oh, i see. thanks.
Oct 23 21:54:35 <denkenz> It needs to be set to 0 in that case
Oct 23 21:54:58 <zhenhua1> i will update that and resend patch out.
Oct 23 21:55:19 <padovan> zhenhua1: so we can put inline in both
Oct 23 21:55:29 <padovan> or out them into voicecall.h
Oct 23 21:56:15 <zhenhua1> denkenz: what do you think
Oct 23 21:56:26 <zhenhua1> i am fine with both
Oct 23 21:56:26 <denkenz> gimme 30 minutes
Oct 23 21:56:39 <denkenz> I need to look first
Oct 23 21:57:46 <denkenz> Send a patch to move alloc_next_id and release_next_id into atutils.h
Oct 23 21:58:26 <denkenz> Make it accept a pointer to int or something
Oct 23 21:58:37 <denkenz> unsigned int rather
Oct 23 21:59:25 <denkenz> The AG_CHLD_FOO comments are useless
Oct 23 21:59:40 <denkenz> If you don't know what those mean, you won't understand what's going on anyway ;)
Oct 23 22:00:47 <zhenhua1> denkenz: and how about call_compare_by_status and call_compare. they are used in everywhere but the same.
Oct 23 22:01:49 <zhenhua1> CHLD_FOO comments are only useful for me, a new guy to telephony. :)
Oct 23 22:02:25 <denkenz> I think we can move create_call and compare_by_id to atutils.h as well
Oct 23 22:02:32 <denkenz> Create atutils.c if you need to
Oct 23 22:02:50 <denkenz> Its already there actually
Oct 23 22:04:06 <denkenz> yeah, lets do that
Oct 23 22:04:15 <denkenz> Send a patch that moves those into atutil.c/h
Oct 23 22:05:53 <zhenhua1> ok. no probs
Oct 23 22:06:33 <zhenhua1> why not put atutil.c to somewhere else. they should not in drivers/atmodem
Oct 23 22:08:03 <zhenhua1> padovan: please review the voicecall patch and give comments to me.
Oct 23 22:08:35 <padovan> zhenhua1: I'm doing that now. :)
Oct 23 22:09:09 <denkenz> zhenhua1: I think it is alright for now, atmodem is a 'generic' at implementation
Oct 23 22:09:37 <denkenz> zhenhua1: Besides, no better place exists right now anyway, it doesn't belong in the core
Oct 23 22:11:08 <zhenhua1> denkenz: then we need a new folder like 'utils'. in arch pic, we have 'utility api' on the left side.
Oct 23 22:11:26 <denkenz> Utility api is in the core
Oct 23 22:11:46 <denkenz> Again, for what atutil.c does right now it is OK
Oct 23 22:11:51 <padovan> zhenhua1: we won't get a callsetup=3 because we don't have a audio connection yet, right?
Oct 23 22:11:56 <denkenz> If it grows out of proportion we will adress it
Oct 23 22:12:48 <zhenhua1> padovan: no. once dialing changes to alerting. ag will send callsetup to us
Oct 23 22:13:10 <zhenhua1> so we need handle callsetup=3
Oct 23 22:13:46 <zhenhua1> and audio connection patch is not in my current patch. i already have that in my local. :)
Oct 23 22:14:25 <zhenhua1> we need to inform AudioManager when we need to switch to Bluetooth audio source and sink.
Oct 23 22:15:09 <zhenhua1> denkenz: yes. i am fine with current atutil.c
Oct 23 22:16:48 <padovan> I got callsetup=3 now. I don't know why it didn't worked first time.
Oct 23 22:18:29 <zhenhua1> denkenz: how about call_compare_by_id and call_compare in src/voicecall.c. can i also move them to atutil.c or still left there?
Oct 23 22:18:41 <denkenz> yah, move them
Oct 23 22:19:03 <denkenz> Put a nice prefix on all of this btw
Oct 23 22:19:10 <denkenz> like at_util_call_compare_by_id
Oct 23 22:19:15 <zhenhua1> okay
Oct 23 22:20:28 <zhenhua1> i saw problem when connecting to nokia phone. it always disconnect when AT+CHLD=?. why
Oct 23 22:20:46 <zhenhua1> but other phone works fine.
Oct 23 22:23:07 <denkenz> Ask the Nokia guys :)
Oct 23 22:23:24 <padovan> zhenhua1: when the other side answers the call my phone hang up. Is this expected?
Oct 23 22:23:44 <denkenz> holtmann: I just pushed initial GPRS support
Oct 23 22:24:02 <denkenz> holtmann: I seems to work, but my MBM card crashes when I enap=1,1
Oct 23 22:24:14 <denkenz> holtmann: Comments welcome :)
Oct 23 22:25:53 <zhenhua1> padovan: single call? why it hang up?
Oct 23 22:26:39 <padovan> zhenhua1: yes
Oct 23 22:26:48 <zhenhua1> padovan: do you see any output on ofono side?
Oct 23 22:27:14 <zhenhua1> should have something like call=0
Oct 23 22:27:54 <zhenhua1> but it's strange. is it because my part?
Oct 23 22:28:26 <padovan> zhenhua1: http://pastebin.com/m3478569a
Oct 23 22:28:44 <padovan> zhenhua1: what is ATD+ for?
Oct 23 22:28:47 <padovan>     if (ph->type == 145)
Oct 23 22:28:48 <padovan>         sprintf(buf, "ATD+%s", ph->number);
Oct 23 22:29:04 <padovan> we don't have ATD+ at spec
Oct 23 22:30:38 <denkenz> padovan: Get yourself a copy of 27.007
Oct 23 22:30:50 <denkenz> That means dial an international number
Oct 23 22:30:59 <padovan> zhenhua1: call is 0 on CIND response, then it never changes.
Oct 23 22:31:07 <zhenhua1> padovan: > AT+CHUP
Oct 23 22:31:13 <padovan> denkenz: right
Oct 23 22:31:26 <zhenhua1> it looks you send out hangup instruction.
Oct 23 22:31:58 <zhenhua1> so the call hang up by itself. and disconnect reason is local hang up.
Oct 23 22:33:03 <zhenhua1> i have no netbook at my side, otherwise i will have a try
Oct 23 22:33:48 <denkenz> padovan: Your driver is a good start but incomplete
Oct 23 22:34:07 <denkenz> padovan: You need to implement registration_status, current_operator and strength functions
Oct 23 22:34:36 <denkenz> padovan: You should also use ofono_netreg_status_notify and ofono_netreg_strength_notify from CIEV indication
Oct 23 22:35:00 <padovan> denkenz: they should only return that values?
Oct 23 22:35:16 <denkenz> padovan: Sorry?
Oct 23 22:37:47 <padovan> denkenz: registration_status, current_operator and strength function should only return the value of these fields, right?
Oct 23 22:38:51 <denkenz> padovan: registration_status should query CIND and return registered/roaming/unregistered depending on the value of service/roam
Oct 23 22:39:05 <denkenz> signal -> simply return CIND value for signal
Oct 23 22:39:20 <denkenz> current_operator -> query COPS, take care of faking the mcc/mnc and return it
Oct 23 22:40:28 <padovan> Ok.
Oct 23 23:03:40 <zhenhua1> denkenz: let me know if you have any comments on hfp voicecall.c
**** ENDING LOGGING AT Sat Oct 24 02:59:56 2009