**** BEGIN LOGGING AT Mon Oct 19 02:59:59 2009 Oct 19 09:15:48 well, I had this with 0.7 but it's defaulting to isimodem again no matter what I put in plugins/modem.conf Oct 19 09:17:40 dilinger: still here? Oct 19 09:18:24 oh, it's using local plugins but modem.conf from /usr/local/etc/modem.conf Oct 19 09:18:30 right Oct 19 09:19:05 i used --prefix= to get the right path Oct 19 09:19:26 I see, I read README and it said that was done Oct 19 09:20:04 i thought it kind of strange. Hadn't used such a prefix before Oct 19 09:23:37 segfaulted Oct 19 09:30:58 i'll give it a shot Oct 19 09:31:41 got it, modemconf.c strings was wrong Oct 19 09:31:45 but Oct 19 09:31:51 after a make it didn't segfault again Oct 19 09:33:13 ofonod[7022]: src/modem.c:set_modem_property() modem (nil) property Device Oct 19 09:33:13 Segmentation fault Oct 19 09:33:23 must have done that last time for some reason Oct 19 09:34:20 [qualcomm_msm_cdma] Oct 19 09:34:20 Driver=qualcomm_msm_cdma Oct 19 09:34:21 Device=/dev/smd0 Oct 19 09:34:52 what do I use for debugging in modemconf.c? Oct 19 09:35:02 not very familiar with glib Oct 19 09:39:21 oh, modem is NULL Oct 19 09:39:23 of course Oct 19 09:39:26 but why? Oct 19 09:40:20 i am afraid that is where i am now. Finding the correlation between the modem and the driver, etc. Oct 19 09:40:47 holtmann: if it works better for you, please add "qualcomm_msm" and "qualcomm_msm_cdma" as copies of g1 and I can just pull that Oct 19 09:41:05 I am on git now but I am afraid I'm missing something Oct 19 09:41:49 wait Oct 19 09:41:58 I didn't include a header for my modem? Oct 19 09:44:10 extern struct ofono_plugin_desc ofono_plugin_desc Oct 19 09:44:16 so it's in the builtin list Oct 19 10:06:22 it's too long? Oct 19 10:06:38 what is the length limit for on the modem type? Oct 19 10:06:51 guess it's raph800 for now Oct 19 10:07:08 also, a warning or error would be nice Oct 19 10:07:24 if (strlen(type) > 16) return NULL; Oct 19 11:19:21 well, my basic plugin works! the name no longer matches the internal name Oct 19 11:19:35 so I will probably change to qcom_msm_cdma Oct 19 11:19:40 or qct_msm_cdma Oct 19 11:19:47 if the size limit does not change Oct 19 11:20:27 the atmodem is not compatible with mine though, I'm getting quite a few errors and unhandeled unsols Oct 19 11:21:12 is there a null sim implementation? Oct 19 11:22:01 CFUN=1 CRC=1 CLIP=1 all OK Oct 19 11:22:11 COLP=1 CCWA=1 not supported Oct 19 11:22:46 and of course, CGMI, CPIN, CRSM (??) are not either Oct 19 11:23:39 the rest are custom CSQs 3g status and timezone data Oct 19 12:22:50 well, calls seem to work anyway :) Oct 19 12:23:14 what is the policy for audio routing in ofono? I guess I should look at isimodem or someting else to get an idea? Oct 19 12:24:02 rraasch: oh, you writing a plugin for something? I missed that earlier Oct 19 12:34:24 tmzt: Yea. I am using the siemens mc75, and having a time just getting the serial port etc. hooked up right. I am trying to use the dbus-send to set Powered property to true to initialize serial port Oct 19 12:34:38 ah Oct 19 12:34:52 trry test/enable-modem Oct 19 12:35:05 Don't have python on platform. Oct 19 12:35:26 fso people did a lot of research on that modem for gta03 or whatever Oct 19 12:35:26 ah, ok Oct 19 12:35:29 and the mainloop and gobject are not support in the python i do use Oct 19 12:35:33 I like qdbus though Oct 19 12:35:42 but that's heavier Oct 19 12:35:43 i am using the e_dbus Oct 19 12:35:53 e17? Oct 19 12:35:55 yea Oct 19 12:36:06 from c? Oct 19 12:36:10 yea Oct 19 12:36:23 I don't know, the python example seems simple enough Oct 19 12:36:30 but dbus can be hard to work with Oct 19 12:37:35 should i start by writing a plugin or a driver for the mc75 Oct 19 12:37:47 hadn't quite figured out the exact difference Oct 19 12:37:58 ? Oct 19 12:45:49 possibly, why are you having trouble talking to it? Oct 19 12:46:33 well, after some debugging, it seems that the line feed is not sent Oct 19 12:46:48 ofonod[423]: > AT+CRC=1\r Oct 19 12:47:04 the modem needs a \r\n Oct 19 12:47:05 yeah, not sure why that would be Oct 19 12:47:18 are you using atmodem? Oct 19 12:47:40 yes Oct 19 12:47:56 ofonod[423]: src/modem.c:ofono_modem_create() atgen Oct 19 12:48:19 src/modem.c:ofono_devinfo_driver_register() driver: 0x72214, name: atmodem Oct 19 12:52:33 where is this syntax stuff set? Oct 19 12:52:42 i tested with just AT Oct 19 12:52:49 same result AT\r Oct 19 12:54:47 I don't know, look at plugins/atmodem.c Oct 19 12:55:37 ok. thanks Oct 19 17:05:45 tmzt: mm? Oct 19 22:02:29 :( Oct 19 22:03:29 Is there reason for your unhappiness? Oct 19 22:03:41 setting Powered=false, SubscriberNumbers never changes; instead, the Interfaces property just empties out Oct 19 22:04:30 Beats spamming everyone with weird values Oct 19 22:04:59 i would've expected an unwinding of values Oct 19 22:05:10 What's the point? Oct 19 22:05:41 principle of least surprise? Oct 19 22:05:52 Not only is that error prone since you're faking it anyway, but Interfaces changing does it just as well Oct 19 22:07:38 i'm not sure how that's considered faking it (your SubscriberNumbers property is becoming empty as the modem powers down), but *shrug* Oct 19 22:08:17 Well no it doesn't, besides there are plenty of values which have no sensible defaults Oct 19 22:08:44 i don't particularly feel like arguing about it Oct 19 22:08:50 you want to know why i was unhappy Oct 19 22:09:27 i'm unhappy because i have to write additional code to deal w/ something that, had i not tried something unusual, i would've never even guessed would happen Oct 19 23:25:03 I suspect you will have much unhappiness then, I already told you that SubscriberNumbers is not meant to be used that way ;) Oct 19 23:40:39 holtmann: I wait until Aki has a chance to comment. Doubt he cares, but anyway... I apply it tomorrow Oct 20 00:05:33 denkenz: so i'm stuck listening for SubscriberNumbers, Interfaces, and Modems to determine if ofono is actually (and powered up) there or not Oct 20 00:37:21 denkenz: ping denis Oct 20 01:14:09 zhenhua: Pong Oct 20 01:14:41 dilinger: Actually I'm trying to save you lots of grief. That attribute is only used for display in GSM, it is useless otherwise Oct 20 01:16:19 dilinger: You might as well use a random number for what you're trying to accomplish Oct 20 01:20:10 denkenz: the most concern is still cind_val and cind_pos Oct 20 01:20:37 i need to filt call, callsetup and callheld in later voicecall. because I only care about their val Oct 20 01:20:54 e.g., CIEV:1,1 means call=1 Oct 20 01:21:04 so? Oct 20 01:21:07 first 1 is index Oct 20 01:21:11 you have this info Oct 20 01:21:39 i need for loop to find index value of call, right Oct 20 01:21:39 it's inefficent Oct 20 01:21:45 rather than strcmp Oct 20 01:22:01 for () if(cind_pos[i] == index) break; Oct 20 01:22:26 if you stored strings you'd need to loop over anyway, but do strcmp too Oct 20 01:22:29 not sure if you understood, i could make more example if you want Oct 20 01:22:56 no, why need loop Oct 20 01:23:13 Because you didn't use a hash table ;) Oct 20 01:23:44 right. but g_new0 keep the index from 1 to max. Oct 20 01:24:13 sigh, you have char **cind_names; Oct 20 01:24:25 How will you get the information without a loop? Oct 20 01:24:37 yeah, i plan to use hash table original, but hash table doesn't guarantee the insert order Oct 20 01:24:53 Yah, so forget all of this, you don't need to loop anyway Oct 20 01:25:00 in your voicecall cind do something like: Oct 20 01:25:14 if cind_pos[call] == index -> do stuff Oct 20 01:25:22 else if cind_pos[callheld] == index -> do stuff Oct 20 01:25:27 else if .. Oct 20 01:25:52 errr... looks possible. ;-) Oct 20 01:26:01 you care about 3 indicators in voice call and 3 in netreg Oct 20 01:26:09 of course Oct 20 01:26:16 Why use a big hammer like the HashTable when 6 ifs will do ;) Oct 20 01:26:43 char ** doesn't look urgly i think Oct 20 01:27:27 btw, marcel suggest we do not use guint, instead, we should use unsigned int Oct 20 01:27:53 and why cind_value is gint instead of unsigned int Oct 20 01:28:25 dunno, theoretically the indicator can be negative Oct 20 01:28:42 doesn't matter ;) Oct 20 01:29:04 Feel free to send a patch using unsigned int / int instead of gint guint Oct 20 01:29:10 i forgot to change one thing but minor, i should rename drivers/hfpmode/hfp.c to hfpmode.c Oct 20 01:29:13 hfpmodem.c Oct 20 01:29:47 it's small thing. we can fix them with other component togethter Oct 20 01:30:14 i want to discuss voicecall.c logic with u Oct 20 01:30:59 i use heuristic way in mutlicall handling Oct 20 01:30:59 denkenz: i understand it, but i don't know how to get the phone number otherwise Oct 20 01:31:44 dilinger: The point is you don't, the GSM spec is fucked. I'm serious, I can set the EFmsisdn to 911 or some other random number Oct 20 01:31:51 denkenz: again, there are two separate things i want; the first is notification when stuff is finished powering up, or is on the way to powering down (the only way i'm aware of to get that is by watching SubscriberNumbers, Interfaces, and Modems) Oct 20 01:32:03 denkenz: the second is the phone number Oct 20 01:33:08 dilinger: And I'm telling you that your approach is misguided, oFono doesn't work this way Oct 20 01:33:16 denkenz: i know that, but telepathy does Oct 20 01:34:03 dilinger: I know it does, but oFono was never meant to be wrapped, in fact we'll do our darnest to make wrapping a stupid thing to do Oct 20 01:34:54 zhenhua: Go on Oct 20 01:35:40 anotehr question Oct 20 01:35:45 why use ofono_debug instead ofono_info in hfp_debug. Oct 20 01:35:57 _info is always printed Oct 20 01:35:58 looks other plugin also use info Oct 20 01:36:10 which ones? Oct 20 01:36:18 right, but you see atgen.c Oct 20 01:36:39 denkenz: if ofono were to export a telepathy interface, it would still need this knowledge (when it's done powering up, etc) Oct 20 01:38:49 zhenhua: I think it should be debug for all of them actually Oct 20 01:39:52 denkenz: that's fine for me. Oct 20 01:39:56 holtmann: Any particular reason why ofono_info is used when OFONO_AT_DEBUG is set? Oct 20 01:41:00 dilinger: We're not doing telepathy though ;) Oct 20 01:46:42 denkenz: can we esitmate the schedule for voicecall part Oct 20 01:46:45 denkenz: yes, but there are others who want to do telepathy Oct 20 01:47:28 zhenhua: Sure, when can you do it? :) Oct 20 01:47:56 give me 5 days for single call, and another 5 days for multicall Oct 20 01:48:08 the basic code is there. need bug fixing now Oct 20 01:48:19 including testing Oct 20 01:48:28 dilinger: And that is fine, but we're not bastardizing our API for that, our focus is the various UIs, not yet another communications framework Oct 20 01:49:14 zhenhua: Sounds fine to me Oct 20 01:49:33 and for checkin plan, can you have a rough estimate Oct 20 01:49:53 maybe i should give you a prototype for review first.:) Oct 20 01:50:06 zhenhua: As soon as its ready is the checkin plan, but if you submit nice patches like the last one in small chunks, it should be fast Oct 20 01:50:38 okay. thanks Oct 20 01:50:42 denkenz: don't any other ofono clients need to know when it's finished powering up? Oct 20 01:51:25 Not really, I've yet to see an argument from UI perspective Oct 20 01:52:06 denkenz: i'm assuming you already have a UI somewhere? Oct 20 01:52:48 yep Oct 20 01:55:43 in fact the whole point is for ui not to know that so the user in't blocked in any way **** ENDING LOGGING AT Tue Oct 20 02:59:57 2009