**** BEGIN LOGGING AT Wed Sep 01 02:59:57 2010
Sep 01 08:58:52 <pessi> denkenz: which is this way? I'd prefer separate emergency bit because even after the e-call has ended, the related localtion lookup via supplementary service messages might be ongoing
Sep 01 09:32:41 <zapp42> Hi All
Sep 01 09:33:40 <zapp42> I am having a hard time getting connman + ofono to connect via different 3G sticks or a bluetooth connected n900. 
Sep 01 09:33:59 <zapp42> Is this the place to ask for help or shall I better use the mailing lists?
Sep 01 09:34:26 <wagi> you can ask here, but you might have to stay long enough
Sep 01 09:35:20 <zapp42> wagi: OK, no problem. Thanks.
Sep 01 09:36:02 <zapp42> So... My setup: Meego netbook 1.0.x / updated connman (0.59) / updated ofono (git)
Sep 01 09:36:45 <zapp42> 3G USB devices: Huawei K3715 and E172
Sep 01 09:37:16 <zapp42> Is this setup supposed to work at all?
Sep 01 09:37:47 <wagi> ofono has recently changed it's API
Sep 01 09:37:54 <zapp42> Is the Meego GUI capable of setting up 3G connections?
Sep 01 09:38:18 <wagi> you might want to use an tagged version of ofono together with connman 0.59
Sep 01 09:38:26 <zapp42> wagi: Yes, I have see a long list of patches on the connman list...
Sep 01 09:38:38 <zapp42> wagi: So 0.26 then?
Sep 01 09:39:04 <zapp42> I have tried this w/o any success before I switched to the git version.
Sep 01 09:40:02 <zapp42> So in general there is a setup where this can work? No missing parts in connman or ofono?
Sep 01 09:40:27 <wagi> not sure but 0.26 seems okay from reading the changelog
Sep 01 09:41:16 <wagi> the first thing you have to check if ofono detects your modems
Sep 01 09:41:43 <wagi> can you do a "ofono -n -d 2> log" and then attache the modem?
Sep 01 09:41:51 <wagi> and post the log to pastebin?
Sep 01 09:42:24 <zapp42> wagi: Yes, give me a minute to switch back to 0.26...
Sep 01 09:42:26 <wagi> Some Huaweis do work
Sep 01 09:47:08 <zapp42> http://pastebin.com/uEC8N9FN
Sep 01 09:48:00 <zapp42> Which the git version of ofono I get to a point where I need to enter the pin (which works)
Sep 01 09:48:31 <zapp42> Which 0.26 I do not see the PIN request...
Sep 01 09:48:49 <wagi> ah, I see
Sep 01 09:48:56 <zapp42> I used the ofono "enter-pin" test script for this.
Sep 01 09:49:06 <wagi> so the git version supports this modem
Sep 01 09:49:10 <wagi> but the 0.26 not yet
Sep 01 09:49:32 <wagi> but connman can handle the newer API of the git version of ofono
Sep 01 09:50:12 <zapp42> can it? 
Sep 01 09:50:19 <wagi> not yet, it will.
Sep 01 09:50:37 <zapp42> I see.
Sep 01 09:50:40 <wagi> s/can/cannot/
Sep 01 09:51:36 <zapp42> Let's assume the connman-ofono-my-modem connection works as it should...
Sep 01 09:51:53 <zapp42> Is there a GUI for setting things up?
Sep 01 09:55:28 <pessi> I have heard rumors ;)
Sep 01 09:56:47 <zapp42> pessi: Rumors that there is a GUI with 3G support or that there will be one?
Sep 01 09:57:15 <pessi> that there is gui
Sep 01 09:57:46 <zapp42> pessi: Meego / carrick? 
Sep 01 11:03:07 <akiniemi> pessi: ping
Sep 01 11:04:46 <pessi> pong?
Sep 01 11:07:17 <akiniemi> in the g_isi_send() patch: why return NULL if opaque is NULL but notify is non-NULL?
Sep 01 11:13:19 <pessi> as explained in evil parts
Sep 01 11:13:21 <pessi> In the same vein, if the opaque
Sep 01 11:13:22 <pessi> data is NULL but destroy notify is non-NULL, the g_isi_send() just returns
Sep 01 11:13:34 <pessi> NULL but does not set errno.
Sep 01 11:13:41 <pessi> So, we can do something like
Sep 01 11:13:48 <pessi> if (!g_isi_send(clnt, msg, len, resp_cb, isi_cb_data_new(cb, data), g_free)) CALLBACK_WITH_FAILURE(cb, data);
Sep 01 11:16:00 <akiniemi> pessi: g_free() to a NULL is a no-op
Sep 01 11:16:12 <akiniemi> So "in the same vein" doesn't tell me much
Sep 01 11:16:30 <pessi> sure, but if isi_cb_data_new() returns NULL, that is an error
Sep 01 11:17:20 <akiniemi> Not a very explicit way to catch mem allocation failure...
Sep 01 11:18:32 <pessi> that is why it is in the evil parts ;)
Sep 01 11:20:23 <akiniemi> It's saving two lines, and maybe gaining a honorable mention in the obfuscated C contest, but not very clear since g_isi_send() isn't failing, really. Me not like.
Sep 01 11:20:49 <akiniemi> Otherwise, looks good :)
Sep 01 11:23:40 <akiniemi> I'll push unless others have any comments
Sep 01 11:24:42 <akiniemi> Then I think we need to move all the drivers to using g_isi_send() and g_isi_vsend() and get rid of the old API
Sep 01 11:25:29 <akiniemi> pessi: any ideas about g_isi_verify(), we need to make that handle many concurrent users of the same client instance
Sep 01 11:27:49 <pessi> one socket to rule them all, one socket to find them
Sep 01 11:30:21 <pessi> akiniemi: do you want to push the evil one or a more conventional one?
Sep 01 11:31:32 <akiniemi> pessi: the more conventional one, but I can commit amend. No need to resubmit.
Sep 01 11:33:13 <pessi> I've already amended it
Sep 01 11:36:10 <akiniemi> pessi: allright, throw 'em over the cubicle and I'll push ;)
Sep 01 11:49:59 <pessi> our ussd timeout is ... short
Sep 01 11:58:09 <pessi> oopsiedaisie
Sep 01 11:59:44 <pessi> the ussd patch was a missing a v
**** BEGIN LOGGING AT Wed Sep 01 12:36:30 2010
Sep 01 12:54:09 <zapp42> Hi again
Sep 01 12:54:53 <zapp42> Update on quest from earlier today...
Sep 01 12:55:38 <zapp42> I now see the 3G USB device in connman and the Meego GUI. So Yes, there is support for this.
Sep 01 12:56:16 <zapp42> However it only works if I boot into ubuntu first and use network manager to provide the PIN. 
Sep 01 12:58:00 <zapp42> Without this the usb device will not show up in Meego / connman at all. Last thing in the ofono log is "src/sim.c:ofono_sim_add_state_watch() 0x..."
Sep 01 12:59:02 <zapp42> wagi: Thanks for your help.
Sep 01 13:00:43 <pessi> zapp42: I suppose there is no GUI for modems, like PIN code query
Sep 01 13:01:20 <pessi> you can disable the pin with ofono test/unlock-pin
Sep 01 13:01:47 <zapp42> pessi: Yes, maybe, but there is something wrong with ofono, too. I am not able to use the test scripts to enter the pin
Sep 01 13:02:05 <pessi> hm?
Sep 01 13:02:21 <zapp42> It works with the git version (but then again I have a connman API problem), but not with 0.26
Sep 01 13:02:30 <pessi> perhaps your modem does not support sim manager interface
Sep 01 13:02:48 <zapp42> Yes, it does. ofono-git works.
Sep 01 13:03:09 <zapp42> pessi: You did the API patches for connman, right?
Sep 01 13:03:23 <zapp42> Maybe I should try these?
Sep 01 13:03:55 <zapp42> to be able to use ofono head with connman...
Sep 01 13:04:25 <pessi> go ahead... and report the problems if you notice anything
Sep 01 13:04:44 <pessi> ofono-refactor-v2 and service-leak patches
Sep 01 13:05:00 <zapp42> pessi: Will do. The patches haven't been applied to connman git, right?
Sep 01 13:05:39 <pessi> ofono-refacor-v2 01 and 02 might be, other, no.
Sep 01 13:05:41 <pessi> +s
Sep 01 13:10:01 <wagi> zapp42: you're welcome
Sep 01 13:54:51 <zapp42> pessi: Things are improving: connman-git + service-leak + ofono-refactor-v2 + ofono-git...
Sep 01 13:55:14 <zapp42> enter-pin needs to be done on the command line, but then the 3G modem appears 
Sep 01 13:55:51 <zapp42> Next stop: Get it to actually connect.
Sep 01 14:25:13 <zapp42> 3G connected. Nice.
Sep 01 14:25:23 <zapp42> pessi: Thanks for your help.
Sep 01 14:36:51 <kvalo> zapp42: if you are an ubuntu user: https://wiki.ubuntu.com/ConnMan
Sep 01 14:40:59 <zapp42> kvalo: Thanks, I found this already. There is loads of stuff in LP, too. Quite helpful. I will try the connman hardware test stuff later...
Sep 01 14:50:39 <denkenz> pessi, akiniemi: My preference is for the non-evil version, it is much easier to read the code without having to wonder wtf does the cleanup
Sep 01 14:51:01 <denkenz> That is also the general idiom inside GAtChat and oFono core itself
Sep 01 14:51:54 <kvalo> zapp42: cool, thanks
Sep 01 14:52:32 <denkenz> pessi: And you have to explain your ss e911 comment
Sep 01 14:52:47 <denkenz> pessi: Once the emergency call has ended, how do we know we're still in emergency mode?
Sep 01 15:10:07 <zapp42> kvalo: ping
Sep 01 15:10:31 <kvalo> zapp42: hi
Sep 01 15:10:51 <zapp42> kvalo: I just stumbled upon Bug 624601...
Sep 01 15:11:26 <zapp42> Am I right, that the N900 is supposed to be recognized as USB modem when connected via USB and in PC Suite mode?
Sep 01 15:11:57 <zapp42> Because I don't see it in ofonos "list-modems".
Sep 01 15:12:12 <kvalo> yes, you are correct
Sep 01 15:12:22 <zapp42> And I see the following in dmesg: "cdc_acm 1-6:1.6: This device cannot do calls on its own. It is not a modem."
Sep 01 15:12:32 <zapp42> Any idea?
Sep 01 15:13:14 <kvalo> the kernel needs some nokia magic as well. what kernel are you using?
Sep 01 15:13:27 <kvalo> I have no idea what that error message is about
Sep 01 15:13:43 <zapp42> meego 2.6.33.5-24.1-netbook
Sep 01 15:13:55 <kvalo> you need phonet module
Sep 01 15:13:56 <zapp42> kvalo: OK, thanks, I will try this in Ubuntu
Sep 01 15:14:04 <zapp42> phonet?
Sep 01 15:14:09 <zapp42> a kernel driver?
Sep 01 15:14:12 <kvalo> yeah
Sep 01 15:14:16 <zapp42> ic
Sep 01 15:15:08 <kvalo> and most probably something else as well
Sep 01 15:16:09 <kvalo> ubuntu 10.04 kernel has it, even though it was buggy for me. but I was able to get an internet connection through my n900
Sep 01 15:16:18 <zapp42> kvalo: OK, and n900 via bluetooth? Will this work as a modem?
Sep 01 15:26:19 <kvalo> zapp42: you need bt dun profile for that. ofono doesn't support that yet, but hopefully within few months
Sep 01 15:26:48 <kvalo> zapp42: I'm eagerly waiting for bt dun support, I hate cables :)
Sep 01 15:27:24 <zapp42> ah, yes, I remember having read about some gsoc project...
Sep 01 16:37:50 <GNUtoo|laptop> hi, it seem that there is some support for voicecalls for the n900(maybe I'm wrong) in ofono, so how does the audio routing or audio path works? for instance if someone has only alsa
Sep 01 16:38:14 <GNUtoo|laptop> is there some sort of support commited?
Sep 01 16:59:08 <denkenz> audio routing is not part of the oFono list of responsibilities
Sep 01 16:59:16 <denkenz> In the case of the N900, it is handled by PulseAudio
Sep 01 17:19:16 <GNUtoo|laptop> ok
Sep 01 17:19:39 <GNUtoo|laptop> I just saw that it was handled by the ssi speach driver
Sep 01 17:19:50 <GNUtoo|laptop> then ofono uses that
Sep 01 17:19:59 <GNUtoo|laptop> I'm downloading the kernel to look at that
Sep 02 02:05:16 <yang_office> denkenz: Can we discuss on the send ss patch? It's OK to write the stk version of __ofono_ussd_recognized_control_string(), and omit the DBusMessage parameter. 
Sep 02 02:06:09 <yang_office> But for me, not only I want to reuse the function in ussd.c, but also I want to reuse the functions in call-barring.c, call-forwarding.c, call-settings.c. 
Sep 02 02:07:49 <yang_office> Take call barring for example, I want to reuse its functions: cb_ss_control() and cb_ss_passwd(). Current problem is that all these functions take the assumption that the request is from D-Bus. 
Sep 02 02:09:53 <yang_office> I just want to break this assumption, and make these functions accept the request from stk. In future, we may also have the request from at server.
Sep 02 02:31:08 <denkenz> yang_office: That's fine, just didn't see this happening in your patch
Sep 02 02:32:31 <denkenz> However, just as a word of caution, if the logic starts getting hairy....
Sep 02 02:32:36 <denkenz> Well its already hairy
Sep 02 02:32:49 <denkenz> but anyway, you might want to break the path for stk and for USSD.Initiate up a bit
Sep 02 02:35:48 <yang_office> denkenz: Do you have some idea how to break the path?
Sep 02 02:36:16 <denkenz> perhaps split out the core logic and the response handling
Sep 02 02:37:33 <yang_office> But when handing the core logic, we need to do some response or send the dbus message back.
Sep 02 02:37:55 <yang_office> Such that the atom is busy, the format is not correct, etc.
Sep 02 02:38:32 <yang_office> It's hard to split them. So I embed the switch inside the core logic.
Sep 02 02:39:36 <denkenz> It isn't really that hard to split them
Sep 02 02:40:15 <denkenz> Just return an appropriate error and let the main logic deal with it
Sep 02 02:40:40 <yang_office> yeah, I see your point.
Sep 02 02:41:15 <yang_office> Do you have a better idea to handle the parameter dbusmessage?
Sep 02 02:41:34 <denkenz> I'd suggest doing two sets of functions
Sep 02 02:41:42 <denkenz> one to register with ussd atom, and one to register with stk atom
Sep 02 02:41:59 <denkenz> common core that checks formatting + execution
Sep 02 02:42:12 <denkenz> and slightly different callbacks depending on the caller (stk vs ussd)
Sep 02 02:42:52 <denkenz> use errno creatively in the main logic
Sep 02 02:43:03 <denkenz> e.g. bad_format -> EINVAL, not supported -> ENOTSUPP, etc
Sep 02 02:43:42 <denkenz> See how other parts of the code do this
Sep 02 02:43:59 <yang_office> yes, this would work. I will have a try.
Sep 02 02:44:44 <yang_office> Another question is: Can we merge different ss atoms and ussd atom to one?
Sep 02 02:45:34 <yang_office> The problem for current code: If we send call-forwarding control string from ussd_initiate(), we will check if ussd is busy.
Sep 02 02:46:08 <yang_office> But if we call the API from call-forwarding atom, we will not check if ussd is busy.
Sep 02 02:46:28 <yang_office> However, this is easy to fix, and keep the logic identical.
Sep 02 02:46:48 <denkenz> Then check whether USSD is busy and report the appropriate error
Sep 02 02:47:52 <yang_office> The question is: when sending a call-forwarding string, do we need to check if call-barring is busy?
Sep 02 02:48:14 <denkenz> The most likely answer is no
Sep 02 02:48:37 <denkenz> Most modems only allow 1 CCFC/CCWA, etc operation outstanding
Sep 02 02:48:55 <denkenz> So unless the modem has a multiplexer, these queries are serialized underneath
Sep 02 02:49:13 <denkenz> I doubt we ever meet this issue
Sep 02 02:49:38 <yang_office> If the answer is no, I'm fine with current solution.
Sep 02 02:49:55 <denkenz> Check whether USSD is busy in call-forwarding, call-barring, call-settings
Sep 02 02:50:14 <denkenz> But don't bother doing cross-atom checks, like call-barring, call-settings in call-forwarding, etc
Sep 02 02:50:28 <denkenz> If we find that is needed, we'll come back to it
Sep 02 02:50:38 <yang_office> I see. I will provide the patch to check ussd.
Sep 02 02:51:18 <yang_office> As to the phonesim part, I will make the change to follow your advice.
Sep 02 02:52:40 <yang_office> Actually in my patch, I already have such kind of menu to include call-barring, call-forwarding and call-settings.
Sep 02 02:52:52 <yang_office> I will add other ss.
**** ENDING LOGGING AT Thu Sep 02 02:59:58 2010