**** BEGIN LOGGING AT Mon Feb 01 02:59:56 2010 Feb 01 03:30:57 zhenhua: have you tried 'git am' to apply the patches? Feb 01 15:02:14 martin_office: New ofono-0.17 waits for packaging ;) Feb 01 17:48:16 holtmann: Can we add a helper function to gdbus to parse the property changed signals and getproperties dicts? Feb 01 17:50:30 We might. Check what I have done inside connman and also tools/supplicant-dbus.c Feb 01 17:52:05 Yeah the foreach is nice for getproperties type of thing Feb 01 17:52:42 There's also tons of code in ofono/src/dbus.c which can probably be made shared Feb 01 17:55:03 Look at it and send some patches as proposal to the mailing list for review. Feb 01 18:20:10 padovan: and get rid of the dbus_message_get_args block too Feb 01 18:23:16 denkenz: ok. Feb 01 18:49:04 denkenz: wait for merge the last patch I sent, I guess I found a issue. Feb 01 18:49:35 padovan: nod, I haven't yet Feb 01 21:08:15 jhe: ping Feb 01 21:44:19 padovan: pong Feb 01 21:45:50 padovan: btw, why are you listening for the Paired property? Shouldn't Adapter.PropertyChanged("Devices", ...) and Device.PropertyChanged("UUIDs", ...) be enough? Feb 01 21:46:27 jhe: that's my question. with Paired it's not working Feb 01 21:46:47 I need to add a sleep after receive the signal, then it works. Feb 01 21:47:43 So let me try listen the UUIDs Feb 01 21:49:56 jhe: did you look to the bluez? I would like some hint to solve the rfcomm problem there. The link is not getting disconecteda after agent call Disconnect. Feb 01 21:53:42 padovan: not yet. but sounds like a reference counting bug. Feb 01 21:54:38 padovan: the bt_io_* functions will set the "close on unref" flag for the GIOChannel so if you do the refcounting right then the connection should get dropped at the appropriate moment. Feb 01 21:58:06 I already checked the reference counting, I'll check it again. Feb 01 22:09:34 padovan, jhe, maybe it is because we are not doing shutdown on the socket on the daemon side, we had the very same problem on audio socket when there are more than one process holding a reference to the same socket. Feb 01 22:21:04 padovan, maybe that not the real problem, but anyway we should always call shutdown when we are about to close a socket and it has been shared somehow with another process since this will guarantee that either the socket will be closed and any process polling that socket got notified. Feb 01 22:26:45 padovan, btw that code I was mentioning is in audio/avdtp.c:615, so BtIO alone won't guarantee that since it only call close on the socket which doesn't reflect in other processes. Feb 02 00:00:30 padovan: rebase & resubmit gatchat lint patches from connman to oFono Feb 02 00:01:16 denkenz: have you applied both? Feb 02 00:01:40 padovan: So the first one had to be separate anyway, and AFAIK we already fixed it in oFono Feb 02 00:02:00 padovan: The second one the prefix assignments were unneeded, but the other one was a different bug Feb 02 00:03:57 zhenhua: I pushed the initial gatserver support after cleaning it up Feb 02 00:04:33 zhenhua: The command line parsing still needs alot of work, and you need to enable a queue for pending data ala gatchat Feb 02 00:04:46 zhenhua: You can't just write to the socket when it is set non-blocking Feb 02 00:32:47 denkenz: the whole report from clang is here: http://local.profusion.mobi:8081/~padovan/scan-build/ take a look if you want. Feb 02 01:13:21 denkenz: when can i write data into a non-blocking socket? Feb 02 01:16:23 zhenhua1: When you get POLLOUT. Feb 02 01:17:02 holtmann: ok, i will check that. thanks. Feb 02 01:18:45 If you use write() on a non-blocking socket that is not ready then you get EAGAIN. Feb 02 01:19:49 so we need a queue to put pending data there and wait for POLLOUT event. Feb 02 01:20:46 Yes. Feb 02 01:20:59 What is this for? GAtChat already does it. Feb 02 01:24:20 it's for GAtServer. Need the same work. Feb 02 01:32:34 Yes. You need a similar write queue like GAtChat uses for the client. **** ENDING LOGGING AT Tue Feb 02 02:59:58 2010