**** BEGIN LOGGING AT Wed Feb 23 02:59:56 2011
Feb 23 05:41:44 <denkenz> Jeevaka: https://bugs.meego.com/show_bug.cgi?id=13677
Feb 23 05:42:05 <denkenz> This one is caused by +CLIP=1 failing when we're pin locked
Feb 23 05:42:28 <denkenz> we need a way to tell the voicecall driver to initialize after pin is entered
Feb 23 05:50:15 <Jeevaka> denkenz: CLIP setting should work even if the pin is locked
Feb 23 05:50:59 <denkenz> ofonod[366]: Voice: > AT+CLIP=1\r
Feb 23 05:51:00 <denkenz> ofonod[366]: Aux: < \r\n
Feb 23 05:51:00 <denkenz> ofonod[366]: Aux: < +XDRV: 40,4,0,0\r\n\r\nOK\r\n
Feb 23 05:51:00 <denkenz> ofonod[366]: Aux: > AT+XDRV=40,5,3,0,0,0,9,0,2,0,0,0,0\r
Feb 23 05:51:01 <denkenz> ofonod[366]: Voice: < \r\n+CME ERROR: 11\r\n
Feb 23 05:51:01 <denkenz> ofonod[366]: Voice: > AT+COLP=1\r
Feb 23 05:51:01 <denkenz> ofonod[366]: Aux: < \r\n
Feb 23 05:51:01 <denkenz> ofonod[366]: Aux: < +XDRV: 40,5,0,0\r\n\r\nOK\r\n
Feb 23 05:51:02 <denkenz> ofonod[366]: Voice: < \r\n+CME ERROR: 11\r\n
Feb 23 05:51:02 <denkenz> ofonod[366]: Voice: > AT+CNAP=1\r
Feb 23 05:51:03 <denkenz> ofonod[366]: Aux: > AT+XCTMS=?\r
Feb 23 05:51:03 <denkenz> ofonod[366]: Voice: < \r\n+CME ERROR: 11\r\n
Feb 23 05:51:22 <denkenz>         { 11,   "SIM PIN required" },
Feb 23 05:51:25 <denkenz> It doesn't
Feb 23 05:51:51 <Jeevaka> actually it was a bug in ifx modem which got fixed in latest modem fw
Feb 23 05:52:04 <denkenz> hah, okay
Feb 23 05:52:51 <Jeevaka> not only CLIP, COLP, CCWA, CNAP were failing
Feb 23 05:53:02 <denkenz> Btw, it looks like CRING is repeating in the log
Feb 23 05:53:10 <denkenz> is this because CLIP is off?
Feb 23 05:54:01 <denkenz> Or am I confusing myself
Feb 23 05:54:24 <denkenz> There was some notification which wasn't supposed to repeat
Feb 23 05:54:36 <Jeevaka> CCWA
Feb 23 05:55:11 <Jeevaka> thats the notification which is not supposed to repeat and it doesn't repeat as well
Feb 23 05:57:14 <Jeevaka> even if cring repeats in ifx, there wont be any issues as the call creation and notification is not done in cring notification handling
Feb 23 05:57:32 <denkenz> yep, ok, its CCWA and CLIP that aren't supposed to repeat
Feb 23 08:07:58 <zma> Is there any audio format (for example RAW PCM) that could be easily interfaced with Ofono, so that the content of audio file could be sent instead of user's speech during phone call?
Feb 23 12:29:52 <akiniemi> padovan: thanks for the review, btw
Feb 23 15:30:22 <fdanis> denkenz: ping
Feb 23 15:30:33 <denkenz> fdanis: pong
Feb 23 15:33:32 <fdanis> denkenz: about indicator list, I think that GSList is better than GHashtable as we need 2 ways to access the list : name and index in the list
Feb 23 15:34:26 <fdanis> GHashtable will be hard to construct CIND answers correctly
Feb 23 15:34:29 <denkenz> why do you need the index?
Feb 23 15:35:48 <fdanis> ind in CIEV is the order of the indicator in the CIND reply, so I need the index to construct CIND and CIEV replies
Feb 23 15:37:19 <denkenz> The question is what do you want to optimize
Feb 23 15:37:25 <denkenz> setting the index or the query
Feb 23 15:38:33 <denkenz> for HFP my feeling is that the query will be done once
Feb 23 15:38:42 <denkenz> Then the headset relies solely on URCs
Feb 23 15:39:02 <fdanis> URC ?
Feb 23 15:39:14 <denkenz> unsolicited result code
Feb 23 15:40:28 <denkenz> You probably just want to store the index in the hashtable node to make the query part easier
Feb 23 15:40:44 <fdanis> yes, but when ofono_emulator_set_indicator() is called we need to find the entry by name, but we also need to know the index to send the correct CIEV
Feb 23 15:40:44 <denkenz> And we don't really care about removing indicators at runtime
Feb 23 15:42:32 <fdanis> so, for CIND we will parse the GHashtable for each index in order, right ? 
Feb 23 15:45:33 <denkenz> gah ok, forget what I said
Feb 23 15:45:47 <denkenz> just do a GList and use a linear search
Feb 23 15:45:54 <denkenz> GSList rather
Feb 23 15:46:16 <denkenz> but do g_strdup the name of the indicator inside the list node structure
Feb 23 15:46:25 <fdanis> yes
Feb 23 16:05:27 <denkenz> fdanis: some comments
Feb 23 16:05:29 <denkenz> +               if (!strcmp(ind->name, name)) {
Feb 23 16:05:34 <denkenz> Please use g_str_equals
Feb 23 16:05:47 <denkenz> +                       if ((ind->value == value) || (value < ind->min)
Feb 23 16:05:47 <denkenz> +                                       || (value > ind->max))
Feb 23 16:06:01 <denkenz> The extra parens around each expression are not needed
Feb 23 16:06:13 <fdanis> ok
Feb 23 16:07:59 <fdanis> in emulator_unregister, a simple while(em->indicators) should be better, right ?
Feb 23 16:09:35 <denkenz> yep, or alternatively you can do g_slist_free later
Feb 23 16:11:35 <denkenz> without using remove that is
Feb 23 16:15:00 <denkenz> +               size = 7 + (g_slist_length(em->indicators) * 4) + 1;
Feb 23 16:15:14 <denkenz> For stuff like this, it might be helpful to have a quick comment about your assumptions
Feb 23 16:15:40 <denkenz> e.g. CIND: + terminating null + max of 3 digits in the value + separator
Feb 23 16:16:33 <denkenz> +                       size += strlen(ind->name) + 15;
Feb 23 16:16:38 <denkenz> I'm a bit lost why that is 15
Feb 23 16:17:35 <fdanis> 15 = ,("",(000,000))
Feb 23 16:18:50 <denkenz> ah I see, ok that makes sense, but a comment might be nice
Feb 23 16:18:57 <fdanis> right
Feb 23 16:19:25 <denkenz> +               g_at_server_send_info(em->server, buf, FALSE);
Feb 23 16:19:29 <denkenz> Shouldn't that be TRUE?
Feb 23 16:21:53 <fdanis> if it's TRUE, there will be 2 "\r\n" between info and OK strings (=> one empty line)
Feb 23 16:22:39 <denkenz> yep, thats the way its supposed to be
Feb 23 16:22:51 <denkenz> \r\nRESP\r\n\r\nOK\r\n
Feb 23 16:23:45 <fdanis> ok
Feb 23 16:25:01 <denkenz> ok, so fix that up and resend 2 & 3
Feb 23 16:25:06 <denkenz> I think we're good after that
Feb 23 19:06:07 <fdalleau> denkenz: ping
Feb 23 19:19:54 <denkenz> fdalleau: pong
Feb 23 19:20:07 <fdalleau> hi
Feb 23 19:20:45 <fdalleau> is there any interest in hsp in ofono?
Feb 23 19:22:13 <denkenz> holtmann was advocating it, but this might have to be thought about pretty hard
Feb 23 19:22:28 <denkenz> There's lots of interaction between HSP and HFP, and SCO socket management in particular
Feb 23 19:23:21 <fdalleau> with the emulator and hfp written, it is one AT command away +CKPD=200
Feb 23 19:25:35 <fdalleau> in fact, while fdanis is working on hfp, i started an hsp. This allowed me to try to establish the sco connection.
Feb 23 19:26:37 <fdalleau> but this is raising some issues like : where to get the adresses to connect the sco channel to/from
Feb 23 19:27:09 <fdalleau> should the emulator do some bluetooth (btio calls?)
Feb 23 19:27:47 <denkenz> fdalleau: I haven't really thought about it, there's also the problem that you have to expose the CKPD clicks somehow
Feb 23 19:28:16 <denkenz> But the real trickiness is in the sco socket management and who gets the socket when both hfp and hsp are connected
Feb 23 19:29:51 <fdalleau> all hsp devices I ever had where also doing hfp, this is usually exclusive once one device is connected
Feb 23 19:30:01 <fdalleau> i meant one profile
Feb 23 19:31:21 <denkenz> that could be one approach
Feb 23 19:31:36 <denkenz> I think there's a BT whitepaper on these types of interactions
Feb 23 19:31:58 <denkenz> There's also interaction between HFP/HSP and A2DP
Feb 23 19:32:36 <denkenz> Certainly we can push in an experimental plugin and see how it works out
Feb 23 19:32:41 <denkenz> I have nothing against it really
Feb 23 19:35:38 <fdalleau> ok that's good to know
Feb 23 19:40:03 <denkenz> +               sprintf(buf, "+CMER: (0,3),(0),(0),(0,1),(0)");
Feb 23 19:40:30 <denkenz> fdanis: Do we really care about the mode?  We'll never go into online state with HFP
Feb 23 19:43:18 <denkenz> ah ok, you're going after the subset in HFP 1.5
Feb 23 19:43:23 <denkenz> nevermind then
Feb 23 19:48:39 <demarchi> denkenz: so... i did the C client you asked for the gps task... maybe I could record some data and implement the location-reporting atom in phonesim... what do you think?
Feb 23 19:49:21 <denkenz> yeah, or just generate random values every n seconds ;)
Feb 23 19:49:29 <denkenz> sounds like a good idea to me
Feb 23 20:33:18 <denkenz> demarchi: ping
**** BEGIN LOGGING AT Wed Feb 23 22:23:30 2011
Feb 24 02:20:31 <demarchi> denkenz: pong
Feb 24 02:54:29 <chxie> hi, can somebody tell me how to route my music audio to ofono(the receiving phone), thanks
**** ENDING LOGGING AT Thu Feb 24 02:59:57 2011