**** BEGIN LOGGING AT Thu Jan 21 02:59:56 2010 Jan 21 03:00:43 zhenhua: Eventually we will create ptys with DBus API, we can then track client's lifetime and destroy the pty when/if the client exits Jan 21 03:01:05 One thing you can try is setting ECHO to off on the client fd Jan 21 03:06:28 denkenz: yeah, i will seek the way to set echo off. it's just a GIOChannel. i have no idea to do it yet. Jan 21 03:08:10 in openpty you get back a slavefd, use tcsetattr on it Jan 21 03:08:31 will do Jan 21 03:09:50 Don't invest much time into it, sockets are way easier anyway Jan 21 03:10:06 we can always come back to it later Jan 21 03:11:55 socket already work now. any comments on extra_line? Jan 21 03:12:46 i add some codes to save unread bytes after AT+FOO\r. Jan 21 03:13:49 I haven't looked at that part in detail yet Jan 21 03:14:02 fine Jan 21 05:28:12 denkenz: I don't have much to add to my last email on the subject, i.e. I don't have a particularly strong opinion either way Jan 21 05:31:04 denkenz: per-device would make the API cleaner (one less interface on bluetoothd side and less parameters in the agent calls), but it would cause one extra roundtrip to bluetoothd every time a new device with HFP support is created. It also means that bluetoothd would need to accept HFP connections even though there's no agent registered (due to the otherwise potential risk of race condition between connection creation handsfree agent registration right after Jan 21 05:32:24 s/connection creation handsfree agent registration/connection creation *and* handsfree agent registration/ Jan 21 05:33:20 jhe: I'm not so concerned about round trip time, connman does this with PAN as well Jan 21 05:34:06 jhe: And I do think the cleaner API outweighs all other disadvantages, the main one being the race condition between agent registration & remote side connecting Jan 21 05:34:31 ok, so then we do per-device Jan 21 05:34:38 which I guess padovan's patches already assume Jan 21 05:35:00 Yep Jan 21 05:35:13 Can you review them at some point? I'm not the expert there Jan 21 05:35:22 it probably means we should have a timer for letting a connection hang around on the bluetoothd side when there's no agent registered and then disconnect when the timer expires Jan 21 05:36:15 jhe: Yeah I think the race can be solved, in fact we can even guess somewhat reliably if we should wait Jan 21 05:36:41 jhe: e.g. if other hfp agents are registered, then we know we will get one soon for the newly created device Jan 21 05:37:47 I don't think we need to make the logic so complicated. E.g. just wait 5 seconds and then disconnect if no agent appears. Jan 21 05:37:50 anyway, I'll try to take a look at the patches later today Jan 21 05:38:09 Nod, the ofono side is actually almost ready Jan 21 05:38:30 So if we can get the BlueZ side semi-working and start testing, that would be nice Jan 21 05:39:06 one thing that I havent checked is it if the patches compile with the current stable D-Bus version (which doesn't have fd-passing support) Jan 21 05:39:13 if they don't compile it'd need to be fixed Jan 21 05:39:35 e.g. with #ifndef DBUS_TYPE_FD #define DBUS_TYPE_FD ... #endif Jan 21 05:39:42 The patches assume D-Bus 1.3 support Jan 21 05:39:48 They're useless without it Jan 21 05:40:21 yeah, but any new bluez realease should be compilable with the current stable dbus branch Jan 21 05:40:45 I vote for simply disabling the hfp device plugin if 1.3 is not available Jan 21 05:41:03 Probably do the same in oFono Jan 21 05:41:12 sure. though holtmann will then get to do the necessary autotools magic :) Jan 21 05:41:38 That's the easy part Jan 21 05:44:06 yeah, though holtmann always seems to find something to improve or correct with that stuff Jan 21 05:44:38 jhe: He's a perfectionist :) Jan 21 05:45:05 yep Jan 21 05:45:08 And the current patch set doesn't touch Makefile.am/configure so he definitely has to do that Jan 21 05:49:17 padovan: Btw, I don't see any patches from you today, mail server trouble? Jan 21 06:02:42 denkenz: just forward it to u in case you haven't it. Jan 21 06:04:24 i resolve the problem of echo back by tcsetattr:) Jan 21 06:05:28 Interesting, GMail is just acting weird losing Email left and right Jan 21 06:05:57 tcsetattr is to set the port as raw mode. Jan 21 06:06:32 historically, all types(tty, tcp, unix socket) need to set to raw mode. Jan 21 06:06:56 There you go :) Jan 21 06:07:11 openpty is a craptastic API actually Jan 21 06:07:12 then, i think we should to change g_io_channel_unix_new() to have (int fd) parameter instead of (GIOChannel *io) Jan 21 06:07:18 what do u think? Jan 21 06:07:25 g_io_channel? Jan 21 06:07:32 sorry Jan 21 06:07:36 g_at_server_new Jan 21 06:07:44 Nah Jan 21 06:07:52 now we have g_at_server_new(GIOChannel *io) Jan 21 06:08:13 and setting raw mode should be set in g_at_util_setup_io Jan 21 06:08:35 Nope, that part is common to all channels Jan 21 06:08:44 or, only set raw mode for openpty also works fine for me Jan 21 06:08:44 The tty specific stuff belongs in g_at_tty Jan 21 06:08:59 that's fine too Jan 21 06:16:15 padovan: Looks good to me, you still need to account for new / removed devices Jan 21 06:18:24 padovan: You can in fact just copy plugins/bluetooth.c from connman, they're doing nearly identical things Jan 21 16:27:51 zhenhua: good to know that the packages worked for you! Now I have to start planning a pub crawl around the world I guess :) **** ENDING LOGGING AT Fri Jan 22 02:59:57 2010