**** BEGIN LOGGING AT Tue Jun 22 02:59:56 2010 **** BEGIN LOGGING AT Tue Jun 22 10:15:29 2010 Jun 22 13:49:45 kvalo: what does your huawei report for bInterfaceNumber? Jun 22 13:50:00 Seems they all should report ff, and mine does at least Jun 22 13:54:04 denkenz: I saw numbers 0, 1, 2, 3 and 4. I don't know yet which is which Jun 22 13:54:47 class, subclass and protocol are 255, though Jun 22 13:55:12 interesting Jun 22 13:55:47 ok, first three are the tty ports, last two are mass storage Jun 22 13:56:13 disclaimer: I know nothing about usb Jun 22 13:56:48 here's the first one: Jun 22 13:56:53 Interface Descriptor: Jun 22 13:56:53 bLength 9 Jun 22 13:56:53 bDescriptorType 4 Jun 22 13:56:53 bInterfaceNumber 0 Jun 22 13:56:53 bAlternateSetting 0 Jun 22 13:56:53 *checks again* Jun 22 13:56:55 bNumEndpoints 3 Jun 22 13:56:58 bInterfaceClass 255 Vendor Specific Class Jun 22 13:57:00 bInterfaceSubClass 255 Vendor Specific Subclass Jun 22 13:57:03 bInterfaceProtocol 255 Vendor Specific Protocol Jun 22 13:57:22 should it be bInterfaceClass? Jun 22 13:57:56 yeah, this is obviously wrong Jun 22 14:12:46 kvalo: Try this Jun 22 14:12:47 -SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="ff", ENV{OFONO_IFACE_NUM}="$attr{bInterfaceNumber}" Jun 22 14:12:49 +SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*", ATTRS{bInterfaceClass}=="ff", ENV{OFONO_IFACE_NUM}="$attr{bInterfaceNumber}" Jun 22 14:17:05 denkenz: sure, give me few mins Jun 22 14:35:01 denkenz: works for me Jun 22 14:45:54 ok, i push it then Jun 22 14:46:06 great, thanks Jun 22 15:30:37 denkenz: hi, I'd like to ping you about my second patch on the tech thingy Jun 22 15:33:05 wagi: I looked at it but had a few concerns Jun 22 15:33:14 denkenz: I assumed so :) Jun 22 15:34:50 +static void set_gprs_technology(struct ofono_gprs *gprs, int technology) Jun 22 15:34:52 +{ Jun 22 15:34:53 + const char *str_technology = Jun 22 15:34:55 + registration_tech_to_string(technology); Jun 22 15:34:56 + const char *path = __ofono_atom_get_path(gprs->atom); Jun 22 15:34:58 + DBusConnection *conn = ofono_dbus_get_connection(); Jun 22 15:34:59 + Jun 22 15:35:01 + gprs->technology = technology; Jun 22 15:35:02 + ofono_dbus_signal_property_changed(conn, path, Jun 22 15:35:04 I'd not emit property changed if technology becomes -1 Jun 22 15:35:44 also, there's a disconnect between gprs detach and technology Jun 22 15:35:46 I was not sure how to handle this situation Jun 22 15:36:04 what we do today is simply not emit, so do that for now Jun 22 15:36:38 what do you mean with 'disconnect between gprs detach and technology'? Jun 22 15:36:55 that the signals do not appear together? Jun 22 15:37:12 yeah, if we detach we probably should set tech to -1 Jun 22 15:37:46 but I don't know whether its necessary, etc Jun 22 15:38:29 There's also a question of reporting tech before you're attached Jun 22 15:38:36 Not sure that makes sense Jun 22 15:40:49 Okay, doesn't seem to complicated to get this into the patch. Anything else I should improve? Jun 22 15:43:24 otherwise looks ok Jun 22 15:44:14 is it okay to store the state in gprs_data? Jun 22 15:48:32 I'm still not sure why you bother storing those variables Jun 22 15:48:40 Can't you report tech directly ? Jun 22 15:50:41 I don't think so. The problem is that the signals appear independent and to dicede what the current tech is I have to look at the other values Jun 22 15:52:28 btw my question was if it's okay to store the CGATT status in gprs_data. Jun 22 15:52:52 on second though, I could just disable the notifaction if we are not attached Jun 22 15:53:53 sorry, I didn't get this part Jun 22 15:53:57 elaborate? Jun 22 15:54:58 You have suggested to enable/disable the tech updates when the gprs context is attached or detached Jun 22 15:55:12 so I try to figure out how to do this Jun 22 15:55:28 currently the notification are enabled all the time Jun 22 15:55:36 detachment / attachment is reported through creg Jun 22 15:55:55 cgreg that is and you might get octi/owcti before cgreg Jun 22 15:57:30 argh! I start to hate this modem Jun 22 15:58:35 now back to the question. Since I have to know when cgreg reports state I need to know it when the octi etc appear Jun 22 15:59:10 so it's okay to store this state in gprs_data? Jun 22 15:59:38 I don't know, it might be this is better handled in core Jun 22 16:02:41 int ofono_gprs_get_status()? Jun 22 16:10:15 I was more thinking the core takes care of holding on to tech before an attach Jun 22 16:10:22 Honestly I don't know, play with it :) Jun 22 17:41:27 good idea. that's exactly why I have posted the question :) Jun 22 22:32:21 balrog-k1n: So I'm confused, if you want to keep them local, why a command registration framework Jun 22 22:32:35 balrog-k1n: Much easier to simply use a switch/case Jun 22 22:46:03 denkenz: yes, probably could use a switch/case but this seemed easier actually Jun 22 22:46:18 and in theory it's faster than a switch/case Jun 22 22:46:55 heh Jun 22 22:47:17 switch/case is easier to read and you don't need to allocate 128 pointer table Jun 22 22:47:42 However, I do believe we might need proactive command handling outside the stk atom Jun 22 22:47:55 e.g. send sms, setup call Jun 22 22:48:08 However, for now I would lean towards just making this a switch / case Jun 22 22:49:09 ok, i can make it a switch, i didn't make it a switch so far because this way you can register and unregister handler when you get notified that a certain atom was created or removed etc Jun 22 22:49:31 also frees you from adding forward declarations or keeping the switch after all the called functions Jun 22 22:50:30 if an atom becomes available then it should probably handle stk commands directly Jun 22 22:50:57 e.g. in the case of setup call Jun 22 22:51:33 so my preference is a switch / case or a formal public API Jun 22 22:51:45 switch / case is just easier for now though Jun 22 22:51:47 ok, let's have a switch Jun 23 00:55:28 denkenz: why static IP netmask in mbm is 255.255.255.248? I think it should be 255.255.255.255. right? Jun 23 01:09:30 zhenhua: Don't know, ask holtmann Jun 23 01:17:28 i have sent a patch. hope holtmann could review it. Jun 23 01:17:51 I doubt its correct btw ;) Jun 23 01:19:43 :-) **** ENDING LOGGING AT Wed Jun 23 02:59:56 2010