**** BEGIN LOGGING AT Fri Oct 16 02:59:57 2009
Oct 16 17:46:44 <remy_> yup everyone
Oct 16 17:47:14 <remy_> just discovered ofono... looks like some magic stuff that can do everything, but I cannot see clearly if I can use it for my project
Oct 16 17:48:22 <remy_> that would be to create a phone interface that can use both voip, rtc and gsm from a computer (with the sound acquired on the computer)
Oct 16 17:48:34 <remy_> could I use ofono to be (part) of the backend ?
Oct 16 17:49:03 <denkenz> yes
Oct 16 17:49:45 <denkenz> oFono will drive the GSM modem, you still need to perform hardware level integration
Oct 16 17:50:01 <denkenz> e.g. getting sound in/out, etc
Oct 16 17:52:03 <remy_> ok
Oct 16 17:52:11 <remy_> and can I use an external phone for this ?
Oct 16 17:53:59 <denkenz> theoretically
Oct 16 17:54:28 <denkenz> all phones are different, but the basics should work on almost every one
Oct 16 17:54:42 <denkenz> Still, there might be utterly broken ones out there
Oct 16 17:55:39 <remy_> aren't they lots of vendor locks or things like that ?
Oct 16 17:56:13 <denkenz> Not all phones expose a full set of functionality over usb/bluetooth
Oct 16 17:56:36 <denkenz> And oFono is meant as a full-featured stack, that goes over the bare metal (hardware)
Oct 16 17:57:05 <remy_> yeah I can see that
Oct 16 17:58:52 <remy_> thanks
Oct 16 18:09:48 <padovan> zhenhua: ping
Oct 16 18:12:28 <denkenz> padovan: PRC comes alive a bit later, though they might already be off for the weekend
Oct 16 18:13:48 <denkenz> Feel free to discuss the patch here anyway, since it'll be for my benefit as well
Oct 16 18:15:06 <padovan> denkenz: Right, I'm still trying to test it, test-modem script is not working for hfp.
Oct 16 18:15:46 <denkenz> hmm, lemme see
Oct 16 18:16:52 <denkenz> Did you setup modem.conf to point to an rfcomm device? 
Oct 16 18:17:11 <denkenz> You might also wanna establish the connection, not sure if gatchat will work otherwise
Oct 16 18:17:30 <padovan> denkenz: yes, and I did the bind.
Oct 16 18:17:49 <denkenz> Yeah, bind worries me
Oct 16 18:17:57 <denkenz> Since it does crazy stuff underneath
Oct 16 18:37:23 <padovan> hmm, it's not registering the modem.
Oct 16 18:37:51 <denkenz> hmm?
Oct 16 18:39:59 <padovan> denkenz: hfp driver does nothing on hfp_init(), I think it need to register itself on ofono_modem_driver_register.
Oct 16 18:40:31 <denkenz> the patch does this...
Oct 16 18:41:31 <padovan> yes, I found that here :-(
Oct 16 18:42:16 <denkenz> Make sure hfp is your only modem defined in modem.conf, since enable-modem looks for entry 0
Oct 16 18:42:53 <padovan> sure
Oct 16 18:56:50 <denkenz> Gah, I now see why you submitted that patch ;)
Oct 16 19:00:42 <denkenz> so it works for me
Oct 16 19:01:02 <denkenz> Of course the driver doesn't get very far since my phone doesn't support CHLD
Oct 16 19:03:10 <denkenz> padovan: Here are the steps that I took:
Oct 16 19:03:22 <denkenz> edit ofono's modem.conf:
Oct 16 19:03:26 <denkenz> [hfp]
Oct 16 19:03:28 <denkenz> Driver=hfp
Oct 16 19:03:29 <denkenz> Device=/dev/rfcomm0
Oct 16 19:03:51 <denkenz> rfcomm connect 0 <bdaddr> <channel>
Oct 16 19:04:00 <denkenz> ofonod -nd, enable-modem
Oct 16 19:04:28 <denkenz> also you probably want to export OFONO_AT_DEBUG=1 before starting ofonod to see the AT commands in their glory
Oct 16 19:04:39 <padovan> hmm. let me see.
Oct 16 19:04:58 <denkenz> rfcomm bind probably won't work right now since we open the tty non-blocking
Oct 16 19:05:17 <denkenz> And that won't work with bind'ed rfcomms
Oct 16 19:16:47 <padovan> It worked, but failed at BRSF handshake, debugging here..
Oct 16 19:20:06 <denkenz> cool, my failed at CHLD handshake, but I'm using some POS SE phone right now
Oct 16 19:23:51 <denkenz> holtmann: Feel free to cut 0.8 at commit eb2c60469cb703999219fd377eae43e185315d12
Oct 16 19:25:42 <padovan> my bad, it's working, I was using the wrong rfcomm channel. :(
Oct 16 20:14:24 <padovan> denkenz: holtmann: all the HF side of HFP will be at ofono? I mean, will anyhing be done into BlueZ?
Oct 16 20:14:54 <denkenz> The current thinking is oFono will be used for proper HFP devices (e.g. GSM, car kits)
Oct 16 20:15:27 <denkenz> And perhaps a basic implementation inside BlueZ for VoIP only devices (apparently there's a new HFP rev coming)
Oct 16 20:18:30 <padovan> Right.
Oct 16 20:35:19 <holtmann> denkenz: The 0.8 is uploading right now.
Oct 16 20:51:21 <denkenz> fuck glib is evil
Oct 16 20:51:46 <denkenz> g_at_chat_shutdown: 0x5b852a8
Oct 16 20:51:48 <denkenz> g_at_chat_unref: freed chat
Oct 16 20:51:49 <denkenz> read_watcher_destroy_notify: 0x5b852a8
Oct 16 20:51:52 <denkenz> anyone detect a problem? :)
Oct 16 21:34:58 <tmzt> end to end compressed voice?
Oct 16 21:35:08 <tmzt> speex or celt in firmware?
Oct 16 21:36:06 <tmzt> holtmann: do you thing audio service will ever end up in something like pulseaudio?
Oct 16 22:12:16 <denkenz> tmzt: Nokia has already done this with N900
Oct 16 22:16:03 <tmzt> sorry, i mean bluetooth audio rather than socket from pulse to bluez/bluetoothd
Oct 17 02:05:34 <zhenhua> padovan: pong, do you still have question about hfp patch?
Oct 17 02:18:54 <padovan> zhenhua: not about the patch. But I have other questions. Will you keep working on HFP into ofono?
Oct 17 02:19:41 <padovan> we are studying a solution with HFP and maybe we wil help ofono with that.
Oct 17 02:20:51 <denkenz> padovan: the answer is yes ;)
Oct 17 02:21:06 <zhenhua> padovan: yes.
Oct 17 02:21:36 <zhenhua> padovan: as i said in ML, i am working on voicecall now. :)
Oct 17 02:22:09 <zhenhua> the multicall is tricky because of status machine. but i believe i can fix them soon.
Oct 17 02:24:02 <padovan> zhenhua: denkenz: do you have a estimative when all should be done?
Oct 17 02:24:34 <denkenz> it depends, the current patch needs some work, but its mostly correct
Oct 17 02:25:14 <denkenz> The netreg aspect should be trivial
Oct 17 02:25:24 <padovan> I'm looking to it, but I need to read spec yet.
Oct 17 02:25:51 <denkenz> voicecalls are a bit tricky, but if we make it work with a 'good' implementation before we focus on crappy ones
Oct 17 02:26:13 <denkenz> The real pain is BlueZ audio integration
Oct 17 02:26:21 <zhenhua> yes
Oct 17 02:26:49 <zhenhua> I don't know how much changes need to be made at BlueZ side
Oct 17 02:26:58 <zhenhua> and audio part need a small patch too
Oct 17 02:27:29 <padovan> I see.
Oct 17 02:28:14 <zhenhua> currently, single call works fine but multiparty call is problematic. HFP always send callsetup/call but no info about which call line status is changed
Oct 17 02:28:30 <zhenhua> we need keep a status machine here.
Oct 17 02:29:12 <denkenz> yep, mostly it can use ideas from the generic voicecall driver
Oct 17 02:30:10 <padovan> Sure.
Oct 17 02:32:46 <zhenhua> denkenz: do u see any issue with my patch, feel free to let me know
Oct 17 02:33:06 <denkenz> Ok, so lets talk about it
Oct 17 02:33:25 <denkenz> First off, I don't like the split that you did
Oct 17 02:33:46 <denkenz> drivers/hfpmodem/hfp.c needs to be moved into plugin/hfp.c
Oct 17 02:34:12 <zhenhua> let me check
Oct 17 02:35:08 <denkenz> essentially you need to merge those two files together for the most part
Oct 17 02:35:31 <zhenhua> right. but that would cause plugin/hfp.c a bigger file.
Oct 17 02:35:40 <denkenz> That is fine
Oct 17 02:35:51 <denkenz> Move AT+CHLD=? query to voicecall driver
Oct 17 02:36:13 <denkenz> Also feel free to create a shared structure between plugin/hfp and driver/hfp/*
Oct 17 02:36:28 <denkenz> e.g. something like struct hfp_data { };
Oct 17 02:36:41 <zhenhua> query CHLD after SLC is created? not after BRSF?
Oct 17 02:37:03 <zhenhua> why need move CHLD to voicecall.
Oct 17 02:37:03 <denkenz> Query CHLD when you initialize the voicecall driver
Oct 17 02:37:11 <denkenz> Because it logically belongs there
Oct 17 02:37:31 <zhenhua> okay
Oct 17 02:37:46 <zhenhua> but it makes someone may confuse.
Oct 17 02:37:56 <denkenz> Basically the plugin/hfp.c should setup things which are shared
Oct 17 02:37:59 <zhenhua> spec is define the handstake process
Oct 17 02:38:02 <denkenz> e.g. BRSF query
Oct 17 02:38:06 <denkenz> CIND query
Oct 17 02:38:15 <denkenz> SLC establishment
Oct 17 02:38:26 <zhenhua> so hfp.c is only a part of handshake process
Oct 17 02:38:57 <denkenz> I know, but the rest of the handshake can be separated into 2 aspects
Oct 17 02:39:01 <denkenz> netreg and voicecall
Oct 17 02:39:06 <zhenhua> yes.
Oct 17 02:39:25 <zhenhua> another point: feel free to create a shared structure between plugin/hfp and driver/hfp/*
Oct 17 02:39:47 <zhenhua> normally we don't share structure between plugins and driver
Oct 17 02:39:57 <zhenhua> because they should look transparently to user
Oct 17 02:40:15 <denkenz> We kinda do, check how quirks are done
Oct 17 02:40:16 <zhenhua> so i use struct gateway to hide some logic behind
Oct 17 02:40:50 <zhenhua> do u think we should keep struct gateway
Oct 17 02:41:00 <denkenz> But I say this because we need to share the BRSF results anyway
Oct 17 02:41:11 <zhenhua> which quirks we have? i don't find it
Oct 17 02:41:33 <denkenz> We share the quirks definition among multiple plugins
Oct 17 02:41:49 <zhenhua> i will check it later
Oct 17 02:42:02 <denkenz> See drivers/atmodem/vendor.h
Oct 17 02:42:19 <denkenz> The other thing is that the driver can simply copy the data it needs into its own structure
Oct 17 02:42:33 <denkenz> We don't need to use 1 monolithic struct
Oct 17 02:43:15 <denkenz> I'd rename struct gateway into struct hfp_data
Oct 17 02:43:18 <zhenhua> i will try to study that
Oct 17 02:43:33 <denkenz> The only thing you need out of that is GAtChat, int ag_features and GSList *indies
Oct 17 02:43:56 <zhenhua> and mpty_features too
Oct 17 02:44:11 <denkenz> No, that can be part of the voicecall data
Oct 17 02:44:23 <zhenhua> i see
Oct 17 02:44:47 <denkenz> I also suggest breaking GSList *indies into multiple index variables
Oct 17 02:44:58 <denkenz> e.g. roaming_index, signal_index
Oct 17 02:46:08 <denkenz> You need a handful only anyway, service, call, callsetup, callheld, signal, roam, batt
Oct 17 02:46:15 <denkenz> Easier than to parse the GSList every time
Oct 17 02:46:17 <zhenhua> GSList *indies is Mingjun's old code. so i don't change that part
Oct 17 02:46:25 <denkenz> Yah, get rid of it
Oct 17 02:46:40 <zhenhua> and put all into hfp_data?
Oct 17 02:46:45 <denkenz> yes
Oct 17 02:47:00 <zhenhua> no problem
Oct 17 02:47:09 <denkenz> The netreg driver can copy the necessary indices into its own structure if needed
Oct 17 02:47:15 <zhenhua> i still not get about vendor.
Oct 17 02:47:19 <denkenz> same with voicecall data
Oct 17 02:47:47 <denkenz> Basically you can share structs between drivers/plugins/etc
Oct 17 02:48:20 <zhenhua> drivers/atmodem/vendor.h is only a emum
Oct 17 02:48:28 <zhenhua> enum, not structure
Oct 17 02:48:45 <denkenz> yep, but the point is the enum is shared across multiple drivers
Oct 17 02:49:03 <denkenz> so there's no difference if it is a struct
Oct 17 02:49:08 <zhenhua> it's const value
Oct 17 02:49:36 <zhenhua> do you wanna a static structure that shared across multiple drivers?
Oct 17 02:50:12 <zhenhua> sorry for my stupid if my question is troubling you. :)
Oct 17 02:50:16 <denkenz> Put it this way: drivers/hfp/hfp.h should have struct hfp_data
Oct 17 02:50:26 <zhenhua> right
Oct 17 02:51:01 <denkenz> and you should do something like ofono_voicecall_create(modem, 0, "hfp", hfp_data)
Oct 17 02:51:04 <zhenhua> then we use memcpy passing it to different driver?
Oct 17 02:51:16 <denkenz> and in voicecall_probe you simply do:
Oct 17 02:51:25 <denkenz> struct hfp_data *hd = data
Oct 17 02:51:32 <zhenhua> okay. that should be work fine.
Oct 17 02:51:46 <denkenz> then g_new struct hfp_voicecall_data() and copy the data from hfp_data into voicecall_data as needed
Oct 17 02:51:48 <zhenhua> i am glad to do that. :)
Oct 17 02:52:36 <denkenz> get rid of is_rfcomm_tty function, its pointless
Oct 17 02:53:05 <denkenz> Get rid of all the pointless state tracking
Oct 17 02:53:06 <zhenhua> it exists because tty is got from bluez before
Oct 17 02:53:30 <denkenz> Doesn't matter, in fact on some systems it might not be called rfcomm0
Oct 17 02:53:43 <zhenhua> okay
Oct 17 02:53:55 <zhenhua> i am also worry about timeout. 
Oct 17 02:54:08 <denkenz> We don't worry about those details for now
Oct 17 02:54:14 <denkenz> Make the protocol work first
Oct 17 02:54:31 <denkenz> hfp_cleanup -> move everything over to hfp_remove
Oct 17 02:54:35 <zhenhua> and it works now. only code structure need change
Oct 17 02:54:49 <zhenhua> okay
Oct 17 02:55:24 <denkenz> Or hfp disable
Oct 17 02:55:45 <denkenz> Yeah, hfp_disable is what I meant
Oct 17 02:56:14 <zhenhua> any other thing?
Oct 17 02:57:03 <denkenz> get rid of hfp_service_level_connection
Oct 17 02:57:14 <denkenz> Simply initiate the BRSF part in hfp_enable or something
Oct 17 02:57:55 <denkenz> +	str = g_at_result_iter_raw_line(&iter);
Oct 17 02:57:56 <denkenz> +	while (str[i] != ')') {
Oct 17 02:57:58 <denkenz> +		if (str[i] == ',') {
Oct 17 02:57:59 <denkenz> +			value[index] = '\0';
Oct 17 02:58:00 <denkenz> +			ofono_debug("%s", value);
Oct 17 02:58:02 <denkenz> +			get_mpty_features(&mpty_feature, value);
Oct 17 02:58:04 <denkenz> +			index = 0;
Oct 17 02:58:05 <denkenz> +		}
Oct 17 02:58:07 <denkenz> +
Oct 17 02:58:11 <denkenz> +		if (((str[i] >= '0') && (str[i] <= '4')) || str[i] == 'x') {
Oct 17 02:58:13 <denkenz> +			value[index] = str[i];
Oct 17 02:58:15 <denkenz> +			index++;
Oct 17 02:58:17 <denkenz> +		}
Oct 17 02:58:19 <denkenz> +		i++;
Oct 17 02:58:21 <denkenz> +	}
Oct 17 02:58:23 <denkenz> yuck
Oct 17 02:58:25 <denkenz> why don't you use next_string here?
Oct 17 02:58:36 <zhenhua> this is Mingjun's code.
Oct 17 02:58:41 <zhenhua> i don't change that part
Oct 17 02:59:06 <zhenhua> he want to parse thing like 'CHLD=0, 1, 1x, 2, 2x'
**** ENDING LOGGING AT Sat Oct 17 02:59:57 2009