**** BEGIN LOGGING AT Mon Sep 13 02:59:57 2010
Sep 13 07:39:04 <damunix> morning
Sep 13 07:39:46 <damunix> I have a little question : could anyone tell me where I can find the doc/dataconnectionmanager-api.txt file ? I'm trying to create a context, and I cannot make it work...
Sep 13 07:41:14 <akiniemi> damunix: it was renamed connman-api.txt
Sep 13 07:41:37 <akiniemi> damunix: you could also try the scripts under test/
Sep 13 07:41:59 <damunix> ok akiniemi, that's what I'm trying to use, but it doesn't do anything
Sep 13 07:54:49 <akiniemi> damunix: is your modem online?
Sep 13 07:56:02 <damunix> ok find why it don't work : I'm using the "generic" modem config, and there are no "Interface" property
Sep 13 07:56:14 <damunix> It's a Device
Sep 13 08:14:51 <damunix> Do you know what's the difference between Interface and Device ? I would think that Interface is for phones that have integrated modem, is that true ? 
Sep 13 08:24:24 <pessi> modems.conf?
Sep 13 08:25:10 <pessi> the Interface is there for modems that use isi protocol (and phonet network interface on top of special serial port)
Sep 13 08:25:44 <pessi> Device is for modems that talk AT commands on top of normal tty serial line
Sep 13 16:31:32 <Jeevaka> denkenz: you there
Sep 13 16:51:55 <denkenz> jeevaka: Yep
Sep 13 16:53:26 <Jeevaka> Wanted to confirm on the UCS2 case, dcs from network is 7-bit and the chosen TE is UCS2, then the modem converts the received 7-bit data into UCS2 format 
Sep 13 16:53:41 <Jeevaka> am I correct?
Sep 13 16:53:46 <denkenz> At least one modem I know does that
Sep 13 16:54:00 <denkenz> So yeah, you're correct
Sep 13 16:55:29 <Jeevaka> what about if the dcs is ucs2 and the character set chosen is 7-bit? also what about the dcs is UCS2 and character set is UCS2( this is not currently handled)?
Sep 13 16:58:36 <denkenz> I believe if the dcs is ucs2, it would just be done in hex
Sep 13 16:58:53 <denkenz> At least if I were interpreting the spec, that is what I would do
Sep 13 16:59:03 <denkenz> Someone with a network simulator needs to confirm though
Sep 13 17:00:45 <denkenz> Jeevaka: And btw, that is what 27.007 actually says
Sep 13 17:00:47 <denkenz> -	if <dcs> indicates that 16-bit data coding scheme (UCS2) is used: MT/TA splits the 16 bits into two 8-bit octets. Each of those octets are converted as per the 8-bit data coding scheme, with the most significant octet first (e.g. decimal value 4906 is presented to TE as four characters 132A (IRA 49, 51, 50 and 65))
Sep 13 17:03:01 <Jeevaka> I dont see this info in v8
Sep 13 17:03:19 <Jeevaka> I mean, I dont find this info in 27.007 v8
Sep 13 17:03:38 <denkenz> 3GPP TS 27.007 V10.0.0 (2010-06)
Sep 13 17:03:45 <Jeevaka> ok
Sep 13 17:04:36 <denkenz> HEX is really the most sensible way of doing it anyway
Sep 13 17:04:54 <denkenz> If some modem does it differently, we can quirk later
Sep 13 17:09:15 <Jeevaka> so, if I understand correctly, we will use g_at_result_iter_next_hexstring instead of  g_at_result_iter_next_string for getting the ussd data itself
Sep 13 17:09:44 <denkenz> yep
Sep 13 17:10:09 <Jeevaka> ok, thank you.
Sep 13 17:10:10 <denkenz> Which is kinda tricky since string comes before the DCS
Sep 13 17:10:18 <Jeevaka> s
Sep 13 17:10:37 <denkenz> You might have to grab the string, then use decode_hex_own_buf on it
Sep 13 17:10:40 <Jeevaka> thats why I wanted to discuss withyou
Sep 13 17:11:17 <denkenz> Alternatively, skipping the string, grabbing the dcs, then re-initing the iter is an option
Sep 13 17:11:24 <denkenz> But probably more work
Sep 13 17:14:03 <Jeevaka> I would prefer the 2nd option, whats your view?
Sep 13 17:15:35 <denkenz> Honestly, grabbing the string + decode_hex_own_buf would probably be more efficient and result in less code
Sep 13 17:16:38 <Jeevaka> but incase of UCS2 its possible to have 00 in the content
Sep 13 17:17:20 <Jeevaka> decode_hex_own_buf uses strlen to find the length of the string
Sep 13 17:18:53 <denkenz> Then we probably need to add iter_next_ucs2_string to GAtResult that also returns the length
Sep 13 17:19:21 <Jeevaka> yep
Sep 13 17:20:52 <denkenz> That is fine
Sep 13 17:21:06 <denkenz> CUSD is about the only place that raw UCS2 is likely
Sep 13 17:22:29 <Jeevaka> also need to provide utility function for converting the UCS2 to GSM
Sep 13 17:23:51 <denkenz> Yep, but that is actually easy
Sep 13 17:24:21 <Jeevaka> I have provided already, just wanted to keep you informed
Sep 13 17:24:46 <denkenz> nod
Sep 13 17:24:52 <Jeevaka> but, since I was not clear I thought the function might not be needed
Sep 13 17:25:01 <Jeevaka> now its clear
Sep 13 17:28:13 <denkenz> Jeevaka: Actually, we don't need a next_ucs2_string
Sep 13 17:28:23 <denkenz> "UCS2"	16-bit universal multiple-octet coded character set (see ISO/IEC10646 [32]); UCS2 character strings are converted to hexadecimal numbers from 0000 to FFFF; e.g. "004100620063" equals three 16-bit characters with decimal values 65, 98 and 99.
Sep 13 17:29:03 <denkenz> They're still hex
Sep 13 17:29:35 <Jeevaka> yes, but how will we know the length of the hex coded string
Sep 13 17:30:16 <denkenz> strlen
Sep 13 17:30:18 <Jeevaka> when it reaches us, it will be 004100620063
Sep 13 17:30:20 <denkenz> '0' is not NULL
Sep 13 17:30:45 <denkenz> See drivers/atmodem/phonebook.c for details
Sep 13 17:31:46 <Jeevaka> they are using the next_hexstring that will return the length
Sep 13 17:32:06 <denkenz> Yeah, but you're confusing yourself
Sep 13 17:32:27 <denkenz> Remember, you get 12 bytes for 3 16-bit characters
Sep 13 17:32:37 <denkenz> they're hex-strings, not raw bytes
Sep 13 17:32:42 <denkenz> They don't contain NULLs
Sep 13 17:33:32 <denkenz> next_hexstring is equivalent to:
Sep 13 17:33:34 <denkenz> next_string
Sep 13 17:33:39 <denkenz> decode_hex(string)
Sep 13 17:35:40 <Jeevaka> ok
Sep 13 18:04:26 <Jeevaka> denkenz: any review comments for (PATCH 04/13)USSD atom driver changes to read current character setting
Sep 13 18:15:08 <denkenz> I think its fine
Sep 13 18:19:03 <Jeevaka> ok
Sep 13 23:07:01 <Jeevaka> denkenz: have sent the patches with your review comments which also contains the UCS2 handling and unit test functions for newly added utility function
Sep 14 01:35:27 <zhenhua_home> denkenz: ping
Sep 14 02:28:06 <zhenhua_home> denkenz: dun_gw part is little bit tricky. we have 1:N relationship, e.g. one DUN server port against N modems in ofono.
Sep 14 02:29:15 <zhenhua_home> denkenz: so there're two steps actually
Sep 14 02:29:48 <zhenhua_home> denkenz: step1: catch ModemAdded signal and get modem by object path, add state watch to the modem itself.
Sep 14 02:30:16 <zhenhua_home> denkenz: step2: get online state change and create the emulator on the modem.
Sep 14 02:31:40 <zhenhua_home> denkenz: in anyway, i have to add a function like ofono_modem_get_modem_by_path to get modem from modem object path. Actually i don't like it much.
Sep 14 02:32:25 <zhenhua_home> denkenz: any comments are welcome
Sep 14 02:37:20 <denkenz> I can see doing it two ways
Sep 14 02:37:33 <denkenz> The first way is to follow the whole idea of history/nettime plugins
Sep 14 02:37:46 <denkenz> Simply probe() whenever a modem is added
Sep 14 02:38:03 <denkenz> Then have the plugin install a modem state watch, sim state watch, etc
Sep 14 02:38:30 <denkenz> Then you don't need to listen to anything or modem_get_modem_by_path
Sep 14 02:39:20 <denkenz> The probe() can even check modem plugin type and ignore the ones it doesn't care about, e.g. hfp
Sep 14 02:39:21 <zhenhua_home> hmm...will looks history plugin in details
Sep 14 02:39:46 <zhenhua_home> the problem is plugin always loaded before any modem exists
Sep 14 02:39:59 <denkenz> That is ok, just look at history
Sep 14 02:40:07 <denkenz> it uses create_context or something like that
Sep 14 02:40:20 <zhenhua_home> oh... i know, add some callback in modem.c
Sep 14 02:40:30 <zhenhua_home> like __ofono_history_probe_drivers
Sep 14 02:41:56 <denkenz> yep
**** ENDING LOGGING AT Tue Sep 14 02:59:57 2010