**** BEGIN LOGGING AT Tue Feb 02 02:59:58 2010 Feb 02 10:03:47 denkenz: we might reuse the wakeup writer part for gatserver. it should be same but i really don't how to test that. Feb 02 10:04:54 denkenz: e.g. you write some data but for some reason, you need to write them again. Feb 02 22:13:31 Vudentz: using shutdown() like the code you mentioned fix the rfcomm issue on HFP. :-) Feb 02 22:18:04 denkenz: when hfpmodem is powered oFono is taking too long to shutdown when I hit Ctrl+C. Any ideia why does this happens? Feb 02 22:21:02 padovan, good, so you can by jprvita a beer since I own him one for dbus package :D Feb 02 22:21:10 /by/buy Feb 02 22:21:31 hahah Feb 02 22:21:33 ok Feb 02 22:21:53 padovan: oFono calls disable and waits about ~5 seconds before shutting down Feb 02 22:22:08 padovan: This allows the drivers to send the shutdown commands Feb 02 22:22:24 padovan: If the drivers finish earlier, it shuts down earlier Feb 02 22:22:43 denkenz: so, is it normal? Feb 02 22:22:59 padovan: Define normal, some modems take ~4 seconds to go from CFUN=1 to CFUN=4 Feb 02 22:23:59 padovan: On HFP I would not expect it to take that long Feb 02 22:27:02 denkenz: I mean: does wait 5 seconds is the normal behavior of ofono? Feb 02 22:27:30 padovan: waiting 5 seconds is, yes Feb 02 22:31:37 denkenz: ok, thanks. Feb 03 00:54:36 padovan: i might suggest u to fix one problem in bluez patch Feb 03 00:56:46 padovan: in manager.c hfp_hs_record(), we might pass guint feat like hfp_ag_record does. It's used to register SDP_ATTR_SUPPORTED_FEATURES for sdp record Feb 03 00:57:22 hi. after a while i try to get ofono working again, but nothing happens. how can i enable debug/ log options somehow. in th past it was just -d option, but now it requires an argument, but what? Feb 03 00:57:41 matgnt: try -nd * Feb 03 00:59:24 zhenhua: thanks. but unfortunately i can only see th ofono version. that is not much. Feb 03 01:00:45 matgnt: you need to run as root and kill existing ofonod if have. Feb 03 01:02:38 denkenz: can we reuse the wakup_writer from gatchat to gatserver? btw, the code in gatchat is complex and i could fully understand what is "for some reason, xxx" Feb 03 01:03:51 denkenz: s/could/couldn't Feb 03 01:08:49 zhenhua: We can use similar structure yes Feb 03 01:12:36 denkenz: i have some urgly copy of wakeup writer locally. but don't know whether it's right.:P Feb 03 01:12:55 denkenz: shall we put these stuff into gatutil.c? Feb 03 01:13:31 we'll have to see Feb 03 01:14:23 and i know it's not easy to integrate CME CMS. so i don't put them in my first patch. Feb 03 01:14:40 you need to integrate them into g_at_server_send_results Feb 03 01:15:24 for CME, how to know whether is the mt_error? i think it's from upper layer. Feb 03 01:16:00 don't know at this point, probably has to come directly from individual implementation Feb 03 01:17:27 ok Feb 03 01:18:26 how can i test non-blocking io? e.g. i can only write data when i got IO_OUT event Feb 03 01:19:29 follow what gatchat does :P Feb 03 01:19:41 In there there is some debugging code for partial writes Feb 03 01:20:01 used for 'stress' testing Feb 03 01:20:45 any test cases? or test scenario? Feb 03 01:21:01 i am headache for partial writes... Feb 03 01:24:13 just think a little more, all they are is a write where bytes written was less than asked for Feb 03 01:24:22 You simply have to account for it when designing the system Feb 03 01:25:10 so i need to cache my write if they couldn't be written fully. Feb 03 01:25:22 and keep the unwritten part until next chance. Feb 03 01:25:24 you need to buffer it yes Feb 03 01:25:25 right? Feb 03 01:25:33 ok. Feb 03 01:25:45 I suggest a two layer buffer Feb 03 01:26:01 something like a ring_buffer as the first layer, and a g_string for the second layer Feb 03 01:26:04 what? two layer? Feb 03 01:26:12 ... Feb 03 01:26:27 so whenever server writes something, it goes to layer 1 Feb 03 01:26:33 it makes more complex. why that? simply reuse writer is enough. Feb 03 01:26:34 When layer 1 overflows, we go to layer 2 Feb 03 01:26:48 Nope, anyway think about it some more Feb 03 01:27:15 Think about where gatchat stores the command strings being sent out too ;) Feb 03 01:27:36 simply a queue, right? command_queue Feb 03 01:28:04 and i don't fully understand about response_lines Feb 03 01:29:15 response lines are all matches lines for an executed command Feb 03 01:29:27 Modems can report 200+ lines Feb 03 01:31:03 okay Feb 03 01:33:16 let me try to understand your point. e.g., two cmds are pending to write. Feb 03 01:33:39 10 bytes for each command. and they are belongs to two g_strings. Feb 03 01:34:18 and if the first 5 bytes of first cmd is written, we need to write left 5 bytes first. Feb 03 01:34:32 then write the second command at next time. right? Feb 03 01:36:58 we can write second command the second time too Feb 03 01:37:07 assuming the socket allows us Feb 03 01:37:17 ok Feb 03 01:37:22 but yes you're getting the idea, except we should use 1 g_string Feb 03 01:37:55 1 g_string for two commands. right? Feb 03 01:38:22 so why not simply use g_string without ring_buffer Feb 03 01:38:44 faster, most of the time you won't be generating that much text Feb 03 01:39:00 so no need to grow the g_string, mallocing, etc Feb 03 01:40:05 maybe g_string is a bad idea too, maybe it should be ring_buffer + list of malloced strings Feb 03 01:40:07 i agree but it's less safe Feb 03 01:40:12 Some testing required Feb 03 01:40:19 less safe? Feb 03 01:40:30 just make code more complex Feb 03 01:40:38 and easy to have bug somewhere. Feb 03 01:40:48 nah, we've no bugs here ;) Feb 03 01:41:12 btw, why i don't see such code in qt extended? like AtFrontEnd Feb 03 01:41:32 did u write such code before? ;-) Feb 03 01:42:17 Qt uses a simple growable buffer for this stuff (e.g. g_string) Feb 03 01:42:25 But Qt has never been the pinnacle of efficiency Feb 03 01:43:05 got that Feb 03 01:44:29 i will try to write some codes first. but it's hard to test, for some corner cases. i think. **** ENDING LOGGING AT Wed Feb 03 02:59:56 2010