**** BEGIN LOGGING AT Tue Apr 13 02:59:56 2010 Apr 13 03:00:14 denkenz: So using AT*99* magic against AT server causes a busy loop. Check with gsmdial -l ;) Apr 13 03:00:23 Otherwise test-server fakes a modem now. Apr 13 03:17:49 holtmann: I see you've been busy Apr 13 03:18:48 holtmann: And you probably finished 1/4th of padovan's GSoC project :) Apr 13 03:19:35 hehe, that's nice Apr 13 03:19:56 where is that code? On connman repo? Apr 13 03:20:08 ofono/gatchat/test-server.c Apr 13 03:21:13 I'll take a look when I have time this week. Apr 13 03:37:28 holtmann: Fixed your busy loop Apr 13 04:25:54 denkenz: i have worked out an at emulator that could dial a call out. :-) Apr 13 06:18:15 denkenz: What do you mean busy. I got bored during the last two hours of flight. Apr 13 06:18:32 zhenhua: ??? Apr 13 06:18:50 You can run gsmdial against test-server now. Just PPP server is missing. Apr 13 06:19:26 holtmann: oh? i never try that way. i am trying to integrate gatserver with ofono core. Apr 13 06:19:39 to create an emulated modem. Apr 13 06:19:58 it's just a prototype now. Apr 13 06:20:50 will send patches out soon. Apr 13 06:22:44 so the DUN implement has nothing to do with ofono core. right? Apr 13 14:38:01 What does int status stand for in ofono_gprs_status_cb_t? Apr 13 14:38:28 * akiniemi finally has some time to progress some old patches Apr 13 14:52:40 akiniemi: link status? (wild guess, though) Apr 13 14:53:30 status is still the GPRS status as reported by CGREG Apr 13 14:54:15 I haven't finished re-working it to a boolean yet Apr 13 18:06:30 holtmann: ping. Apr 13 18:21:37 denkenz: do you have any deadline on DUN client. The GSoC timeline is about August 15th, but I really expect to have it done before that. Apr 13 18:36:49 padovan: No formal deadline Apr 13 18:37:10 padovan: holtmann would love to have it by end-of day on Friday though ;) Apr 13 18:37:43 hahah Apr 13 18:38:09 that I can't do Apr 13 18:38:11 :) Apr 13 18:38:44 darn ;) Apr 13 18:39:28 If we have it fully working by mid-Aug I'd actually be pleased Apr 13 18:40:42 denkenz: also where do you suggest to start the work? BlueZ will do mostly the service export, we can live without that for a while during implementation. So the beginning should be in oFono side with the pieces integration, right? Apr 13 18:41:08 that is where the tricky parts are, so yes Apr 13 18:41:16 The BlueZ side is copy-paste of Handsfree agent Apr 13 18:41:26 yes Apr 13 18:42:01 We can use the Serial API for that, but maybe would be good the same Agent scheme from HFP. Apr 13 18:42:31 Talk to holtmann, if we have fd passing then Serial API should probably be deprecated Apr 13 18:42:42 No sense in copying data around Apr 13 18:43:24 However, you can use the serial api for testing in a pinch Apr 13 18:43:32 denkenz: did dbus with fd-passing has been released finally? Apr 13 18:44:13 (this is not a very well constructed phrase I guess :/ ) Apr 13 18:44:58 Meego has pushed D-Bus daemon with fd passing support Apr 13 18:45:06 Not sure if it was 1.3 or 1.2 + patches Apr 13 18:45:19 So Meego is running oFono + BlueZ with that enabled Apr 13 18:45:55 denkenz: I also plan to create a generic code to handle agent stuff on BlueZ, so most of the code for HFP, DUN and SAP can be shared. Apr 13 18:45:57 from the d-bus website it seems no 1.4 yet :( Apr 13 18:46:05 so no main distros adoption Apr 13 18:46:46 padovan: Yep, good idea, not sure if Claudio ever reviewed your changes, he had something very similar Apr 13 18:46:59 jprvita: Well maybe DUN + HFP will serve as an extra push for it Apr 13 18:47:25 * jprvita hopes so Apr 13 18:53:22 denkenz: yes, I saw his code before start mine. Apr 13 20:40:24 holtmann: hdlc->channel = g_io_channel_ref(channel); Apr 13 20:40:29 why? Apr 13 21:03:52 holtmann, kristen: Btw, it is really pretty evil to take the io channel from gatchat and reset it with your own flags Apr 13 21:04:06 Namely because gatchat might be set blocking and you're resetting it to non-blocking, etc Apr 13 21:37:42 denkenz: I know this isn't the final solution, but it shouldn't be a problem right now because we are shutting down gatchat. Apr 13 21:38:12 its becoming a problem because I actually need to not shut it down ;) Apr 13 21:38:29 i guess it's time to fix that code then :). Apr 13 21:39:05 are you working on the gatchat integration now? Apr 13 21:39:35 not really, just thinking what would be a good solution Apr 13 21:40:53 I know months ago we discussed that perhaps the PPP code would own the io channel when in online mode. Maybe we can save the old channel config somehow and restore it when we switch out of online mode. Apr 13 21:41:31 The problem isn't really in the channel config Apr 13 21:41:39 The problem is that we use blocking mode for broken devices Apr 13 21:41:46 So saving the config won't help you Apr 13 21:42:15 maybe you need to export an API that would let PPP know whether blocking or nonblocking was allowed. Apr 13 21:42:30 it does know, via g_io_channel_get_flags Apr 13 21:44:13 does g_at_util_setup_io have the ablity to deny flags that are not supported? So you could for example, try to set NONBLOCK, and then if you fail, fall back to blocking? Apr 13 21:44:16 However, I still wonder whether all of the IO should go directly through gatchat, and ppp simply registers a feed function with chat Apr 13 21:44:38 not really the intention of that function Apr 13 21:45:47 there really should be two constructors, one from chat and the other from a raw IO Channel Apr 13 21:51:42 holtmann: Let me know if you're fundamentally opposed to driving ppp through gatchat Apr 13 21:52:17 holtmann: We could in theory optimize out the ppp receive ringbuffer, unless of course someone sets a HUGE mtu Apr 13 23:58:43 denkenz: In theory yes, I don't wanna have GAtChat required for PPP. Apr 13 23:59:06 Mainly for some things like LAN Access profile or Active Sync we need PPP without GAtChat. Apr 14 00:00:21 sure, but we could do two constructors easily **** ENDING LOGGING AT Wed Apr 14 02:59:56 2010