**** BEGIN LOGGING AT Fri Jun 11 02:59:57 2010
**** BEGIN LOGGING AT Fri Jun 11 04:19:31 2010
Jun 11 14:20:48 <denkenz> kvalo: I pushed some fixes to your crash problem
Jun 11 14:21:03 <denkenz> holtmann: see my comment on git HEAD
Jun 11 14:21:26 <denkenz> holtmann: You might want to test your Novatel atchat disconnect handler behavior
Jun 11 14:24:30 <wagi> I'm having troubles with the compound command getting to work. 
Jun 11 14:24:49 <denkenz> what kind of troubles
Jun 11 14:24:49 <wagi> now I have simplified to a single command and still my parsing fails
Jun 11 14:25:11 <denkenz> paste the output and your code snippet
Jun 11 14:25:16 <wagi> right
Jun 11 14:25:22 <wagi> 		g_at_chat_send(nd->chat, "AT_OCTI?;_OUWCTI?", none_prefix,
Jun 11 14:25:23 <wagi> 				option_tech_cb, cbd, g_free);
Jun 11 14:25:54 <wagi> ah I post it on pastebin
Jun 11 14:26:07 <denkenz> I already see your problem
Jun 11 14:26:16 <denkenz> none_prefix is wrong there
Jun 11 14:26:28 <denkenz> You want the _OCTI: and _OUWCTI: prefixes in there
Jun 11 14:27:01 <wagi> http://pastebin.com/UkfFVBsy
Jun 11 14:28:36 <denkenz> yeah, so something like static const char *hso_techs_prefix[] = { "_OCTI:", "_OUWCTI:", NULL }; is what you want
Jun 11 14:29:01 <wagi> cool, now it works. thanks!
Jun 11 14:29:30 <wagi> I tried that prefix trick today but it did not work. Propably a stupid typo
Jun 11 14:29:34 <wagi> too hot today
Jun 11 14:30:13 <denkenz> heh
Jun 11 14:34:01 <wagi> not relying on the notification seems anyway a good idea. 
Jun 11 14:35:59 <denkenz> depends, it is a good idea if the modem firmware is sane
Jun 11 14:36:26 <denkenz> however, they're all pretty much crap
Jun 11 14:36:58 <wagi> now I have only to track the octi/ouwcti output
Jun 11 14:37:17 <wagi> and both report something with AT_OCTI?
Jun 11 14:37:26 <wagi> while AT_OSSYSI? didn't
Jun 11 14:37:55 <denkenz> probably just do something like if (octi == 0 && owcti == 0) tech = -1
Jun 11 14:38:03 <denkenz> if (octi > 0) ..
Jun 11 14:38:08 <denkenz> if (owcti > 0) ..
Jun 11 14:38:39 <denkenz> don't even really need to track them 
Jun 11 15:16:52 <wagi> denkenz: just send a new version of the patch. it needs more testing
Jun 11 15:17:38 <wagi> do like the the general structure of it? it's a bit more complicated than I hoped 
Jun 11 15:28:05 <denkenz> wagi: I think its a bit too complicated
Jun 11 15:28:41 <denkenz> wagi: for creg_query, I'd just send owcti/octi query and set tech as before
Jun 11 15:30:02 <denkenz> and there's no need to put the parser into atutil, doesn't really belong there
Jun 11 15:35:24 <wagi> yeah, I though about that. but I'd like to have only one option_tech_cb function
Jun 11 15:35:51 <wagi> right, I update the patch 
Jun 11 15:39:54 <denkenz> so do all the parsing + conversion in one function
Jun 11 15:40:00 <denkenz> but two callbacks
Jun 11 16:20:02 <holtmann> denkenz: I am not sure if I have enough time for the release. So it might end up being done tomorrow.
Jun 11 16:20:12 <holtmann> So feel free to get the tech reporting for HSO merged.
Jun 11 16:21:25 <denkenz> holtmann: Its not ready yet anyway
Jun 11 16:21:50 <holtmann> You have another 24 hours. Since I will not get to it earlier.
Jun 11 16:23:03 <denkenz> its Daniel who has 24 hours ;)
Jun 11 16:26:56 <wagi> yeah :)
Jun 11 16:27:11 <wagi> another version is ready
Jun 11 16:27:44 <holtmann> I let you guys sort this ;)
Jun 11 16:29:42 <wagi> have to leave
Jun 11 16:55:23 <wagi> back online
Jun 11 16:59:39 <denkenz> +       switch (ouwcti) {
Jun 11 16:59:40 <denkenz> +       case 1: /* UMTS */
Jun 11 16:59:42 <denkenz> +       case 2: /* HSDPA */
Jun 11 16:59:43 <denkenz> +       case 3: /* HSUPA */
Jun 11 16:59:44 <denkenz> +       case 4: /* HSPA */
Jun 11 16:59:46 <denkenz> You might as well parse that properly
Jun 11 17:00:07 <wagi> :)
Jun 11 17:00:30 <denkenz> +       case OFONO_VENDOR_OPTION_HSO:
Jun 11 17:00:32 <denkenz> +               /*
Jun 11 17:00:33 <denkenz> +                * Send AT_OCTI?;_OUWCTI? to find out the current tech, it will be
Jun 11 17:00:35 <denkenz> +                * intercepted in option_tech_notify
Jun 11 17:00:36 <denkenz> +                */
Jun 11 17:00:38 <denkenz> +               g_at_chat_send(nd->chat, "AT_OCTI?;_OUWCTI?", 
Jun 11 17:00:39 <denkenz> +                       option_tech_prefix, NULL, NULL, NULL);
Jun 11 17:00:46 <denkenz> That comment is wrong, it actually won't be intercepted in option_tech_notify
Jun 11 17:00:55 <denkenz> especially since you set the option_tech_prefix
Jun 11 17:02:12 <denkenz> +               g_at_chat_register(nd->chat, "AT_OCTI?;_OUWCTI?", option_tech_notify,
Jun 11 17:02:13 <wagi> I registered the option_tech_notify at_creg_set_cb
Jun 11 17:02:13 <denkenz>                                         FALSE, netreg, NULL);
Jun 11 17:02:24 <denkenz> That is actually wrong too ;)
Jun 11 17:02:32 <wagi> oh damn 
Jun 11 17:02:57 <denkenz> I'd just do it this way:
Jun 11 17:03:11 <denkenz> query_creg -> send octi?owcti? to one callback
Jun 11 17:03:20 <denkenz> Set the tech in there, then creg? will fire
Jun 11 17:03:27 <denkenz> then in creg_notify:
Jun 11 17:03:48 <denkenz> if option quirk -> create a structure with status/lac/ci and fire off octi?owcti to another callback
Jun 11 17:04:01 <denkenz> Then report back to netreg in that one
Jun 11 17:04:27 <denkenz> No need to mess with g_at_chat_register or add status/lac/ci tracking into the netreg_data
Jun 11 17:05:15 <denkenz> e.g. struct tech_query { int status, lac, ci; struct ofono_netreg *netreg };
Jun 11 17:06:50 <wagi> thanks
Jun 11 17:07:51 <denkenz> I'm going to add a concept of transactions to GAtChat
Jun 11 17:08:21 <denkenz> so you can do multiple commands and carry along a single data object through all of them
Jun 11 17:08:47 <denkenz> We do this kinda in some circumstances, but it becomes extremely ugly to make sure the data object is destroyed properly
Jun 11 17:09:58 <denkenz> So things like registration_status implementation will be much easier to do
Jun 11 17:10:53 <wagi> sounds like a good plan to me :)
Jun 11 17:16:51 <wagi> sorry to ask again. me feeling stupid... I have not yet understood where this "query_creg" comes in play. My guess is to add this additional inderection for octi/ouwcti in at_registration_status.
Jun 11 17:17:22 <denkenz> yeah, that's what queries creg
Jun 11 17:17:56 <denkenz> sorry, I'm taking shortcuts in my explanations ;)
Jun 11 17:18:33 <wagi> no problem. you know sometimes I'm slow in understanding. so I always asume that the problem is on my side
Jun 11 17:43:58 <kvalo> denkenz: nice, thanks. I'll test your fixes next week
Jun 11 18:31:45 <wagi> argh, those *!#@+ zerocd thing makes me mad. I'm unable to disable it here at home. usb_switchmode doesn't do the trick
Jun 11 18:33:52 <denkenz> google ozercdoff
Jun 11 18:35:43 <wagi> already tried that one. at work ozerocdoff worked but here not. there must be some gremling going around
Jun 11 18:36:02 <denkenz> sometimes unplug / replug helps
Jun 11 18:36:10 <denkenz> but ozercdoff does the trick for me
Jun 11 18:38:09 <wagi> usbcore: registered new interface driver hso
Jun 11 18:38:09 <wagi> usb 2-1: hso received invalid serial state notification
Jun 11 18:38:09 <wagi> usb-storage: device scan complete
Jun 11 18:38:09 <wagi> scsi 49:0:0:0: Direct-Access     SD       HSUPA Modem           PQ: 0 ANSI: 2
Jun 11 18:38:09 <wagi> sd 49:0:0:0: Attached scsi generic sg3 type 0
Jun 11 18:38:11 <wagi> sd 49:0:0:0: [sdb] Attached SCSI removable disk
Jun 11 18:38:35 <wagi> that's what I see after ozerocdoff
Jun 11 18:38:48 <wagi> it's also the same logs for usb_modeswitch
Jun 11 18:39:01 <denkenz> funny, probably the option driver in the kernel is screwing up
Jun 11 18:39:11 <denkenz> *reboot*? :)
Jun 11 18:40:05 <wagi> "ein reboot tut immer gut" works only in german but it says "a fresh boot is always good"
Jun 11 18:40:08 <wagi> :)
Jun 11 18:41:47 <wagi> anyway the patch looks really nice now. but I can't test it right now
Jun 11 18:42:09 <denkenz> heh, send it anyway
Jun 11 18:42:47 <wagi> okay
Jun 11 18:50:08 <denkenz> +       struct ofono_error error;
Jun 11 18:50:09 <denkenz> +
Jun 11 18:50:11 <denkenz> +       decode_at_error(&error, g_at_result_final_response(result));
Jun 11 18:50:12 <denkenz> +
Jun 11 18:50:14 <denkenz> why bother ? :)
Jun 11 18:50:48 <denkenz> +       if (g_at_chat_send(nd->chat, "AT+CREG?", creg_prefix,
Jun 11 18:50:49 <denkenz> +                               at_creg_cb, cbd, g_free) > 0)
Jun 11 18:50:51 <denkenz> +               return;
Jun 11 18:50:53 <denkenz> +
Jun 11 18:51:02 <denkenz> And I'd actually just send the CREG as before
Jun 11 18:51:13 <denkenz> If the parser fails, just set tech to -1
Jun 11 18:52:03 <denkenz> same thing here:
Jun 11 18:52:04 <denkenz> +       struct ofono_error error;
Jun 11 18:52:06 <denkenz> +       int tech;
Jun 11 18:52:07 <denkenz> +
Jun 11 18:52:09 <denkenz> +       decode_at_error(&error, g_at_result_final_response(result));
Jun 11 18:52:10 <denkenz> +
Jun 11 18:52:12 <denkenz> no use decoding the error
Jun 11 18:52:19 <denkenz> +       if (!ok)
Jun 11 18:52:20 <denkenz> +               return;
Jun 11 18:52:29 <denkenz> That is actually bad, simply report creg but with -1 for tech
Jun 11 18:52:42 <wagi> okay
Jun 11 18:53:16 <denkenz> +               tq = g_new0(struct tech_query, 1);
Jun 11 18:53:18 <denkenz> +               if (!tq)
Jun 11 18:53:19 <denkenz> +                       return;
Jun 11 18:53:21 <denkenz> +
Jun 11 18:53:22 <denkenz> +               tq->status = status;
Jun 11 18:53:24 <denkenz> +               tq->lac = lac;
Jun 11 18:53:25 <denkenz> +               tq->ci = ci;
Jun 11 18:53:27 <denkenz> +               tq->netreg = netreg;
Jun 11 18:53:28 <denkenz> +
Jun 11 18:53:30 <denkenz> +               cbd = cb_data_new(NULL, tq);
Jun 11 18:53:31 <denkenz> +               if (!cbd) {
Jun 11 18:53:33 <denkenz> +                       g_free(tq);
Jun 11 18:53:34 <denkenz> +                       return;
Jun 11 18:53:36 <denkenz> +               }
Jun 11 18:53:37 <denkenz> +
Jun 11 18:53:39 <denkenz> Ok, there's no need to actually do both
Jun 11 18:53:40 <denkenz> creating tq is enough
Jun 11 18:54:24 <denkenz> and if tq creation fails, might be a good idea to simply signal creg
Jun 11 18:54:38 <denkenz> as returning is also kinda bad
Jun 11 18:54:55 <denkenz> But I think this is basically the approach I like
Jun 11 18:55:05 <denkenz> Just clean it up some more and I'll merge it
Jun 11 18:55:27 <wagi> okay, thanks for your input!
Jun 11 19:07:34 <wagi> argh forgot to put v4 through checkpatch
Jun 11 19:07:39 <wagi> of course a trailing space
Jun 11 19:09:22 <denkenz> +       if (g_at_chat_send(nd->chat, "AT+CREG?", creg_prefix,
Jun 11 19:09:23 <denkenz> +                               at_creg_cb, cbd, g_free) > 0)
Jun 11 19:09:25 <denkenz> +               return;
Jun 11 19:09:26 <denkenz> +
Jun 11 19:09:28 <denkenz> +       if (cbd)
Jun 11 19:09:29 <denkenz> +               g_free(cbd);
Jun 11 19:09:35 <denkenz> send the CREG in at_registration_status
Jun 11 19:10:15 <denkenz> or actually just remove it, since you're doing it twice it seems
Jun 11 19:11:05 <denkenz> rest looks good
Jun 11 19:11:23 <wagi> right
Jun 11 19:13:03 <wagi> soon a friend will pick me up for a party
Jun 11 19:13:11 <wagi> this has to fixed till then :)
Jun 11 19:14:23 <denkenz> lol
Jun 11 19:18:16 <wagi> have a nice weekend, cu
**** ENDING LOGGING AT Sat Jun 12 02:59:56 2010