**** BEGIN LOGGING AT Wed Sep 15 02:59:57 2010
Sep 15 07:26:02 <yang_office> balrog-k2n: Do you think if there is a need to check if atom is busy with request from stk when handling the request from dbus? For example, in manager_dial() of voicecall.c, vc->dial_req may be checked to see if the atom is busy. 
Sep 15 11:31:55 <pessi> anyone knows how to reboot/reset mbm (3507) in case it is installed in mini-pci slot?
Sep 15 11:51:54 <balrog-k2n> pessi: AT+CFUN=0,1 does it on my (usb) mbm
Sep 15 11:52:11 <balrog-k2n> so does AT*E2RESET or something similar
Sep 15 11:52:25 <balrog-k2n> yang_office: yes, i think we should maybe do that
Sep 15 11:52:58 <balrog-k2n> yang_office: well, not in manager_dial, but perhaps in the methods related to SS
Sep 15 11:53:08 <pessi> balrog-k2n: but nothing if it just dies?
Sep 15 11:53:44 <balrog-k2n> pessi: that i don't know.. i'd try the files in /sys related to the device
Sep 15 11:54:18 <pessi> balrog-k2n: have you have any progress with dial strings from the sim?
Sep 15 11:55:16 <balrog-k2n> pessi: in Set Up Call? no, not yet
Sep 15 11:55:25 <balrog-k2n> i'm on vacation atm
Sep 15 11:55:32 <pessi> ack
Sep 15 11:57:10 <pessi> we hould probably decide on the format
Sep 15 12:09:26 <pessi> +s
Sep 15 14:17:12 <akiniemi> pessi: so you took the leap of faith ;)
Sep 15 14:40:49 <pessi> akiniemi: you mean the expensive brick on my desk?
Sep 15 14:41:00 <pessi> can you run meego on it, btw? ;-)
Sep 15 14:44:04 <pessi> akiniemi: do you use your dual sim on it or did you just tested with the primary one?
Sep 15 14:45:36 <pessi> hm, the modem slot was under the kb?
Sep 15 15:57:03 <akiniemi> pessi: I was using my dual SIM for it, but will switch a different one in as soon as I find one :)
Sep 15 15:57:30 <akiniemi> pessi: and yeah, the modem slot is under the kb, and a bit of a tight spot
Sep 15 15:57:43 <akiniemi> pessi: SIM card reader is under the battery
Sep 15 15:57:54 <akiniemi> pessi: better google for the HW manual, page 77 ;)
Sep 15 16:01:59 <pessi> kalle's ubuntu connman works like a charm, just put m2m as ap and shoot
Sep 15 16:03:55 <akiniemi> pessi: ooh, better give it a spin, then
Sep 15 16:34:01 <pessi> n900 patches seem to work
Sep 15 17:12:29 <Jeevaka> pessi: I have one review comment for patch 4/5
Sep 15 17:13:23 <pessi> Jeevaka: go ahead?
Sep 15 17:13:59 <Jeevaka> in n990.c, mtc_state_query_cb did you miss any if loop
Sep 15 17:14:17 <Jeevaka> n900.c*
Sep 15 17:15:38 <pessi> startup synq?
Sep 15 17:16:05 <pessi> it should be in its own function, I think
Sep 15 17:17:01 <Jeevaka> yes, startup syng
Sep 15 17:17:48 <Jeevaka> In reachable_cb,w e have something like /* XXX */
Sep 15 17:24:14 <Jeevaka> Denis: Isn't the error code ofono_erro::error sent is the error code from the netwpok
Sep 15 17:33:30 <denkenz> Jeevaka: Not really, and besides you can't rely on it not clashing with ECANCELD and ETIMEDOUT
Sep 15 17:40:12 <denkenz> If you want to do this properly, send a patch that sets '0' (No cause given) in additional information
Sep 15 17:41:00 <denkenz> Or you can go into 24.080 and map our error codes to the one USSD expects
Sep 15 17:41:24 <Jeevaka> ok
Sep 15 17:42:16 <Jeevaka> I think phonesim patch has not been reviewed/taken after the whitespace error fix
Sep 15 17:43:01 <denkenz> Which patch?
Sep 15 17:46:44 <Jeevaka> [PATCH 2/7] phonesim changes for setting TE character s
Sep 15 17:48:00 <denkenz> I don't have that patch
Sep 15 17:49:33 <Jeevaka> http://lists.ofono.org/pipermail/ofono/2010-September/004534.html
Sep 15 17:53:52 <denkenz> Actually I don't like the way its done
Sep 15 17:53:58 <denkenz> Using pre_sim for this is actually a bad idea
Sep 15 17:55:49 <denkenz> Simply sending CSCS="GSM" in phonesim_enable might be a better idea
Sep 15 18:00:22 <Jeevaka> ok, I can do that
Sep 15 18:01:43 <Jeevaka> I need to discuss few things about the language notification proactive command 
Sep 15 18:04:48 <denkenz> go ahead
Sep 15 18:05:06 <Jeevaka> As per the 3gpp specification, we have to send TERMINAL RESPONSE (OK) as soon as we get the proactive command even if the terminal doesn't recognize the language
Sep 15 18:05:43 <Jeevaka> Do we need to store the language for feature text displaying
Sep 15 18:06:34 <denkenz> We can handle it as a property
Sep 15 18:07:13 <Jeevaka> so, you believe some application will make use of this language?
Sep 15 18:08:27 <denkenz> No ;)
Sep 15 18:09:13 <denkenz> It seems a completely silly feature, especially since we can't ask the SIM for the current language
Sep 15 18:10:01 <Jeevaka> I also believe the same. and also specification has "The Terminal may use the language included in LANGUAGE NOTIFICATION" as appropriate
Sep 15 18:10:14 <Jeevaka> may use*
Sep 15 18:11:05 <denkenz> Exactly
Sep 15 18:11:09 <denkenz> So here's what I suggest
Sep 15 18:11:37 <denkenz> Handle the command and store the language, but don't expose it over D-Bus for now (Maybe just some DBG or ofono_info statement)
Sep 15 18:11:50 <denkenz> If someone actually has a usecase, then we can figure out the API
Sep 15 18:12:13 <Jeevaka> so we can store the language as part of of the ofono_stk structure
Sep 15 18:12:32 <denkenz> yep
Sep 15 18:12:50 <Jeevaka> ok
Sep 15 18:15:46 <denkenz> yang_office, balrog-k2n, Jeevaka: 3GPP 31.111 talks of Additional Information that needs to be returned in certain cases.  Can you double check that this is being handled appropriately?  Issuing a 'No specific cause can be given' seems a fine approach if we don't retrieve the information from the modem
Sep 15 18:16:08 <denkenz> akiniemi, pessi: The latest USSD changes touched the ISI drivers, you might want to double check they're still working fine
Sep 15 18:16:59 <denkenz> yang_office, balrog-k2n, Jeevaka: Refer to Section 8.12.1-8.12.8
Sep 15 18:19:26 <Jeevaka> spec also has "The coding '00' shall only be used by the ME if no others apply"
Sep 15 18:20:52 <denkenz> In which case you have to look at the modem error (if any) and convert it
Sep 15 18:21:19 <denkenz> In the case of Send USSD, you'd need to pass the raw error info up
Sep 15 18:23:01 <balrog-k2n> denkenz: we do return the additional information where it's mandated by the spec and where the tests in 31.124 do this
Sep 15 18:24:26 <denkenz> balrog-k2n: I actually don't see you doing this for Send SMS
Sep 15 20:06:54 <e-yes> guys, what is correct marshaller (dbus-glib) for oa{sv} signal? (stuck in coding VoiceManager.CallAdded handler)
Sep 15 20:10:22 <pessi> dbus_g_type_get_struct("GValueArray", DBUS_TYPE_G_OBJECT_PATH, MODEM_TYPE_DBUS_DICT, G_TYPE_INVALID);
Sep 15 20:10:48 <pessi> dbus dict is dbus_g_type_get_map("GHashTable", G_TYPE_STRING, G_TYPE_VALUE);
Sep 15 20:13:15 <pessi> uh-oh, and marshaller is void:string,boxed
Sep 15 20:13:35 <e-yes> ah, thank you indeed, pessi. i tho it's packed structure, but i suppose correct dbus signature is (oa{sv}), right?
Sep 15 20:14:31 <pessi> the struct was from my GetCalls type
Sep 15 20:33:48 <e-yes> for GetCalls it works, not for signal CallAdded
Sep 15 20:34:01 <e-yes> http://pastebin.com/MLG6AkNK - i missed something?
Sep 15 20:37:58 <e-yes> callback is called when i pass DBUS_TYPE_G_OBJECT_PATH, type_a_sv, G_TYPE_INVALID to dbus_g_proxy_add_signal
Sep 15 20:38:48 <pessi> http://pastebin.com/LLqJJuZk
Sep 15 20:38:57 <pessi> ...but you figured it out already
Sep 15 20:42:36 <pessi> hmph, n900 plugin does not handle disable
Sep 15 20:43:05 <pessi> and meego hsi driver gets hosed once modem resets itself ;-/
Sep 15 20:43:27 <pessi> deja vu
Sep 15 20:43:33 <e-yes> yea, but not sure about marshaller (VOID:STRING,BOXED ?). and not sure about prototype for callback, (char *objPath, GHashTable *dict)
Sep 15 20:44:37 <pessi> worksforme
Sep 15 20:51:21 <e-yes> i'm asshole. i forget about DBusGProxy *proxy, ... and ... , gpointer user_data
Sep 15 20:51:55 <e-yes> pessi, thank you, man. sorry, for stolen time
Sep 15 20:52:19 <pessi> denkenz: the ussd stuff seems fine
Sep 15 20:53:04 <denkenz> good, btw, you might want to audit the code for const correctness to avoid some nasty casts
Sep 15 20:53:21 <denkenz> At least localize them to a few functions
Sep 15 20:58:05 <pessi> e-yes: are you updating the dialer?
Sep 15 20:58:43 <pessi> denkenz: which casts you are talking about?
Sep 15 20:59:26 <denkenz> For instance:         if (ussd_send(ud->client, dcs, (guint8 *) pdu, len, cbd, g_free))
Sep 15 20:59:26 <denkenz>                 return;
Sep 15 20:59:56 <e-yes> pessi, what dialer?
Sep 15 21:00:33 <pessi> e-yes: my words exactly ;)
Sep 15 21:01:33 <pessi> denkenz: I see
Sep 15 21:03:22 <e-yes> it's not only dialer, but modem/data 'enabler' too:)
Sep 15 21:03:50 <pessi> hm, core is now supposed to work with notifys and requests?
Sep 15 21:04:43 <denkenz> yes
Sep 15 21:05:01 <denkenz> At least it does on AT modems
Sep 15 21:05:35 <pessi> ooh
Sep 15 21:07:11 <denkenz> And btw, your patch 5/5 is mangled
Sep 15 21:07:23 <pessi> does not compile? 
Sep 15 21:07:34 <pessi> I'm a bit surprised ;)
Sep 15 21:07:46 <denkenz> No, as in it didn't come through right
Sep 15 21:08:19 <denkenz> I'm getting 400 lines removed from drivers/isimodem/isimodem.c
Sep 15 21:08:30 <denkenz> Could be my email client is screwy of course ...
Sep 15 21:08:45 <pessi> there is now isigen
Sep 15 21:08:52 <pessi> liek atgen
Sep 15 21:08:58 <pessi> but they are screwed
Sep 15 21:09:17 <pessi> I'll resubmit them tomorrow ;-/
Sep 15 21:09:36 <denkenz> nod
**** BEGIN LOGGING AT Wed Sep 15 23:16:14 2010
Sep 16 02:55:53 <denkenz> yang_office: Can you break up your send ss patch a bit?
Sep 16 02:57:19 <denkenz> Also, I'm thinking that cb/cf/cs should register separate handlers for STK, rather than trying to re-use stuff in ussd.c
Sep 16 02:58:32 <denkenz> Perhaps a main logic function to initiate the ss request, and a callback that either composes a DBus reply or an STK reply
**** ENDING LOGGING AT Thu Sep 16 02:59:57 2010