**** BEGIN LOGGING AT Wed Jan 27 02:59:57 2010
Jan 27 16:43:04 <denkenz> Sweet, we have dynamic debug now
Jan 27 16:43:13 <denkenz> Time to convert some drivers 
Jan 27 17:39:38 <holtmann> denkenz: What do you wanna convert. It is there.
Jan 27 17:40:24 <denkenz> holtmann: I was thinking each driver can set its own domain
Jan 27 17:40:30 <holtmann> just do "./src/ofonod -n -d 'plugins/ste.c' and you get all the debugs from that file. Or use *, ? glob matching. Multiple files can be separated by , or :
Jan 27 17:40:45 <holtmann> I didn't port the domain part. Pointless. File based works just fine.
Jan 27 17:40:54 <denkenz> Ah, in that case OK
Jan 27 17:41:31 <holtmann> Try "./src/ofonod -n -d '*ste*,*hso*' and get debug from all files with *ste* or *hso* file names.
Jan 27 17:42:11 <denkenz> It might be fun to assign domains too, e.g. to track what is going on in voice calls only
Jan 27 17:42:25 <denkenz> so I get debugs from src/voicecall and drivers/foo/voicecall
Jan 27 17:42:34 <holtmann> You can break this down to function name level.
Jan 27 17:43:13 <denkenz> Yeah I know
Jan 27 17:43:19 <denkenz> But that is painful
Jan 27 17:44:14 <holtmann> If we ever need it then I add it.
Jan 27 17:44:26 <holtmann> It is not that painful actually, just increases the binary size a bit.
Jan 27 17:45:11 <holtmann> That is why I haven't done it. Since I never used it. Even the domain pieces are not used in ConnMan.
Jan 27 17:45:13 <denkenz> Oh? I thought most of the cost was incurred by per function data anyway?
Jan 27 17:45:28 <holtmann> Yes, but you need to store the function name.
Jan 27 17:45:56 <holtmann> We currently don't store it.
Jan 27 17:46:12 <denkenz> Ah ok, now I got ya
Jan 27 17:46:59 <holtmann> As long as this work, we should be fine. If at some point we need more, then I extend it.
Jan 27 17:47:52 <denkenz> Nod, I just remember connman's debug stuff had lots of interesting possibilities :)
Jan 27 18:00:58 <holtmann> You have the same possibilities. We just don't exercise them.
Jan 27 19:30:06 <padovan> jhe: denkenz: new patches for hfp on the mailling lists.
Jan 27 19:40:46 <denkenz> padovan: Are you sure your reference counting is working properly?
Jan 27 19:40:56 <denkenz> That would explain why the rfcomm link isn't dropped
Jan 27 19:42:25 <padovan> let me check.
Jan 27 19:43:03 <denkenz> padovan: Once holtmann adds the necessary automake magic for DBus 1.3 I'll start merging your changes
Jan 27 19:44:04 <denkenz> Btw, have we actually tested this stuff works? :)
Jan 27 19:44:53 <padovan> denkenz: the load/remove of devices?
Jan 27 19:45:35 <denkenz> I was more asking in general, but that too ;)
Jan 27 19:46:14 <padovan> yes, I have tested it a lot here. I think we are in a good shape now.
Jan 27 19:46:41 <padovan> in the audio part we still have that bug we discussed other day.
Jan 27 19:46:54 <denkenz> Ok, the last version looked good, so I will do another review this week and hopefully get it merged
Jan 27 19:47:39 <padovan> Nice.
Jan 27 20:00:40 <holtmann> denkenz: So how do you wanna deal with the autoconf magic?
Jan 27 20:00:54 <holtmann> Check for D-Bus 1.3, if available, enable plugin. Otherwise don't?
Jan 27 20:01:09 <holtmann> Or have the checks inside the code and just fail gracefully.
Jan 27 20:01:11 <denkenz> holtmann: That's what I was thinking
Jan 27 20:01:21 <denkenz> holtmann: There's no point for the plugin if no DBus 1.3 present
Jan 27 20:01:26 <holtmann> What? Disable plugin!
Jan 27 20:01:40 <denkenz> holtmann: Yes, disable plugin
Jan 27 20:02:13 <holtmann> So I prefer that we can compile the plugin even on a system without 1.3 present. That makes it easier from an release engineering point of view.
Jan 27 20:02:36 <denkenz> holtmann: How can we without necessary defines?
Jan 27 20:03:08 <holtmann> We just fake them. However I can do dummy compilation.
Jan 27 20:03:30 <holtmann> It is just important that everybody working on this always compiles the whole code basis. Otherwise things slip through the cracks.
Jan 27 20:03:55 <denkenz> holtmann: I'm fine with that, we can always just not register the driver if we detect no DBus 1.3
Jan 27 20:04:39 <denkenz> But whatever the defines used by the plugin need to be defined by your autoconf magic
Jan 27 20:05:13 <holtmann> + *  Copyright (C) 2009-2009  Zhenhua Zhang <zhenhua.zhang@intel.com>
Jan 27 20:05:28 <holtmann> This one has to go btw. Just add 2009-2010 Intel corp after the Nokia copyright.,
Jan 27 20:06:39 <holtmann> Where is the oFono part of this code?
Jan 27 20:06:47 <holtmann> I only see the BlueZ changes.
Jan 27 20:06:56 <padovan> holtmann: patch 3
Jan 27 20:07:00 <denkenz> Add HFP Support through BlueZ
Jan 27 20:09:00 <holtmann> +#ifndef DBUS_TYPE_UNIX_FD
Jan 27 20:09:00 <holtmann> +#define DBUS_TYPE_UNIX_FD -1
Jan 27 20:09:00 <holtmann> +#endif
Jan 27 20:09:30 <holtmann> We have that. And if we do inside the plugin init function. Just check if (DBUS_TYPE_UNIX_FD < 0) return -EIO; we should be good.
Jan 27 20:09:40 <holtmann> Let me try that.
Jan 27 20:10:18 <denkenz> Ok
Jan 27 20:10:39 <padovan> sounds good :)
Jan 27 20:11:13 <holtmann> denkenz: Are you okay with this patch? Then I apply it and fix it up.
Jan 27 20:11:35 <denkenz> I haven't reviewed it properly, I looked at the previous version
Jan 27 20:11:55 <denkenz> But either way we can merge it, worst case we fix afterwards
Jan 27 20:12:03 <holtmann> Okay. Then I merge it.
Jan 27 20:13:05 <padovan> Guys, I guess a I forgot my copyright note on hfp.c
Jan 27 20:18:09 <denkenz> holtmann: I merged the STE GPRS stuff, funny how it is almost identical to MBM
Jan 27 20:18:28 <holtmann> Pushed.
Jan 27 20:18:31 <denkenz> holtmann: Just need their voicecall stuff submitted and ideally some hardware for us to play with ;)
Jan 27 20:19:04 <holtmann> I have the hardware, but I don't get it to run.
Jan 27 20:19:16 <denkenz> Yeah :(
Jan 27 20:22:06 <denkenz> padovan: Feel free to send the updated copyright in a patch
Jan 27 20:22:49 <padovan> denkenz: ok, I'll do that.
Jan 27 20:23:12 <padovan> denkenz: btw, I don't have my name in the AUTHORS file.
Jan 27 20:23:42 <denkenz> padovan: Oops, my bad
Jan 27 20:23:45 <denkenz> padovan: lemme fix it
Jan 27 20:37:21 <denkenz> padovan: Ok should be all good now
Jan 27 20:39:46 <padovan> Thanks :)
Jan 27 22:25:08 <denkenz> padovan: In hfp_agent_new_connection, lets make sure we handle the error cases from service_level_connection
Jan 27 22:25:24 <denkenz> padovan: e.g. by returning an error to the agent method call
Jan 27 22:32:59 <denkenz> padovan: Also, in hfp_agent_release, calling ofono_modem_remove should be sufficient
Jan 27 22:33:22 <denkenz> That one will take care in calling disable, let me know if that doesn't work
Jan 27 22:38:23 <denkenz> padovan: Other than that looks good, lets get the BlueZ side fixed
Jan 27 22:40:28 <padovan> denkenz: yes, BlueZ side need some work yet. Valgring is reporting some errors on BlueZ, maybe the rfcomm issue is caused by that erros.
Jan 27 22:43:10 <denkenz> padovan: Nod, well track it down and get with jhe to resolve the sco audio issue
Jan 27 22:44:00 <denkenz> Then the real testing begins :)
Jan 27 22:44:26 <padovan> =)
Jan 27 22:45:08 <padovan> I'll ask jprvita to send the pulseaudio patch to the mailing list, so everyone can track the audio issue.
Jan 28 01:44:15 <zhenhua> holtmann: without dbus 1.3, plugins/hfp.c will get compile failed, so we should disable it.
Jan 28 01:44:35 <zhenhua> holtmann: DBUS_TYPE_UNIX_FD is undefinied. something like this.
Jan 28 01:46:17 <zhenhua> denkenz: any comments for modem emu patches?
Jan 28 02:04:38 <zhenhua> sorry, maybe i am wrong. let me doubt check that on my netbook.
Jan 28 02:18:53 <zhenhua> denkenz: here?
Jan 28 02:37:00 <padovan> zhenhua: we redefine DBUS_TYPE_UNIX_FD if we don't have dbus 1.3, so the code compiles.
Jan 28 02:42:03 <zhenhua> padovan: ok. that's fine.
Jan 28 02:43:51 <zhenhua> padovan: for audio part, if we need to add patch in pulseaudio, please also Zhen, Huan, our audio expert in the mail loop.
Jan 28 02:46:20 <padovan> zhenhua: ok, we'll cc him.
Jan 28 02:46:31 <zhenhua> padovan: thanks. ;-)
**** ENDING LOGGING AT Thu Jan 28 02:59:56 2010