**** BEGIN LOGGING AT Thu Feb 11 02:59:57 2010 Feb 11 06:37:29 jebba: hrm... i dont know yet if i should consider that good news Feb 11 18:44:05 denkenz: hi. i try to create my own modem for the wavecom fix. as you said i used the g1 implementation as example, but i have a problem when i try to enable the modem. i cannot query modem properties like "Device". do you have a hint for me what the problem could be? Feb 11 18:49:38 matgnt: Did you set the Device in your modem.conf? Feb 11 18:49:54 matgnt: And you also need to modify plugins/modemconf.c to support your driver Feb 11 18:50:52 matgnt: e.g. add "wavecom" to setup_helpers Feb 11 18:55:33 denkenz: thanks. it was the modemconf.c. i greped for "g1" to find some place where it is activated, but it seems i read over the line. Feb 11 18:58:45 nod, once you make it work, submit the patch to the mailing list Feb 11 19:30:38 denkenz: now i get the VoiceCallManger but when i dial i get an error. the AT-Trace includes some errors after cpin. are this errors after cpin part of the special wavecom-fix? Feb 11 19:30:43 http://pastebin.com/m1aa8ad6 Feb 11 19:32:08 matgnt: If your PIN query fails then there two possible causes: Feb 11 19:32:15 You don't have a SIM in Feb 11 19:32:29 Your modem has not initialized the SIM yet Feb 11 19:33:17 Also, please initialize the wavecom with ATE0, the echo is making my head hurt Feb 11 21:08:38 denkenz, ping Feb 11 21:26:39 krau: pong Feb 11 21:29:17 hi Denis I am trying to implement the sim access plugin, I need your opinion. hfp and sim access have a similar implementation, both need to call BlueZ methods to retrieve the supported uuids. Can I move this functions to a new file: bluetooth.c and bluetooth.h Feb 11 21:29:51 and create a bluetooth device driver, similar to BlueZ device driver concept. Feb 11 21:31:07 hfp and sim access will need to register their "drivers", being probed for the devices which support the wanted service. Does it make sense? Feb 11 21:32:08 krau: Yeah it is fine to share a file for common routines Feb 11 21:33:12 Not sure if I would go as far as creating a bluetooth device driver concept Feb 11 21:33:15 denkenz, about the path that I sent to the BlueZ ML. Any comments? Feb 11 21:33:32 which one? Feb 11 21:33:38 sim access Feb 11 21:34:15 I only saw your git branch one Feb 11 21:35:12 was there another one? Feb 11 21:35:13 denkenz, yes, this one. There is one thing that I left on purpose, DBUS_TYPE_UNIX_FD checking. Feb 11 21:38:39 if DBUS_TYPE_UNIX_FD is not defined, maybe we could simply ignore the plugin. I mean, don't declare it: conditional compilation Feb 11 21:38:51 Don't we already do this? Feb 11 21:39:08 denkenz: hey, you mentioned there were some plugins that stored SMSes into e-d-s - is that code around anywhere? Feb 11 21:39:10 The oFono side simply doesn't register one Feb 11 21:39:41 Robot101: AFAIK it is not upstream, but you can dig around the moblin repositories Feb 11 21:40:03 Robot101: It would be called something obvious, like call-history Feb 11 21:40:19 denkenz, it tries to initialize the plugin, I mean you can avoid the plugin declaration Feb 11 21:40:29 denkenz: the MID stuff disappeared from the public git earlier this year :/ Feb 11 21:40:54 krau: The ofono side does something like: Feb 11 21:40:55 static int hfp_init() Feb 11 21:40:57 { Feb 11 21:40:58 int err; Feb 11 21:41:00 if (DBUS_TYPE_UNIX_FD < 0) Feb 11 21:41:02 return -EBADF; Feb 11 21:41:03 krau: I assumed BlueZ side did too Feb 11 21:41:18 yes, the same thing Feb 11 21:41:20 denkenz: It does too. Feb 11 21:41:39 denkenz: anyway, no worries. will ping some people for it. cheers. Feb 11 21:41:58 Robot101: I don't really follow that stuff closely, but I'd assume it will be released soon if it isn't already Feb 11 21:42:25 krau, padovan: So I'm ok with that Feb 11 21:42:52 Also, are there any fixes in your version that can be incorporated into the hfp one? Feb 11 21:43:55 I will basically move some functions of hcp.c to a bluetooth.c Feb 11 21:44:38 I actually meant the BlueZ side too Feb 11 21:47:36 I didn't Feb 11 21:52:19 krau: did you sent the SAP patch to bluez ML? I'm not seeing it here. Feb 11 21:53:57 krau: The reason I'm asking is things like commit 8ef5f9f1d8a09309eefd19e4f9bf01df761eb36a Feb 11 21:54:26 It might be a good idea to sync the implementations in BlueZ too Feb 11 21:55:55 padovan, yes, I did. Feb 11 21:58:08 denkenz, I agree, I will review the code. See the commit date: Dec 04 ;-) Feb 11 21:59:48 Yeah, that's the issue, you guys developed the same freaking thing indepedently :P Feb 11 22:00:36 padovan: and I'm still waiting for the final version of the connect patch ;) Feb 11 22:01:48 denkenz: yes, I'll work on it later today. I didn't forget it. :) Feb 11 22:02:28 padovan: ok, no hurry Feb 11 22:03:23 krau: Also we have Disconnect function on the SAP agent Feb 11 22:04:06 krau: What are your thoughts on how it will work? Who's going to call it and when? Feb 11 22:06:54 padovan, jhe: Conversely, how do does oFono get notified if someone else uses Disconnect on the gateway Feb 11 22:08:53 denkenz, iirc when we discussed about it last year, we were considering an applet managing connections Feb 11 22:09:47 for a sap client initiated disconnection Feb 11 22:09:57 I realize the need, but for some reason we didn't include it in HFP Feb 11 22:10:12 So either we didn't think of it, or there's some other mechanism (e.g. ofono gets HUP) Feb 11 22:14:11 denkenz: I think we can listen the State property. Feb 11 22:16:57 padovan: I would check whether you get a HUP on the read watch first Feb 11 22:17:42 your idea is better than mine. Feb 11 22:24:09 Robot101: does eds or eds-dbus support the flexibility needed to make that work? Feb 11 22:24:17 particularly with a tinymail ui Feb 11 22:28:19 tmzt: I don't know how it works, thats why I want to see the code :P Feb 11 22:28:30 tinymail is unconnected to eds at all Feb 11 22:28:43 and, not how I'd build a e-mail client now, its not very well maintained Feb 11 22:28:46 yeah, wonder why that is Feb 11 22:29:07 hmm, why? it's imap seems to be well thought out Feb 11 22:29:28 I need something that can grab sms without X running Feb 11 22:29:36 so I can do live testing Feb 11 22:33:21 well it was funded by nokia and they stopped now Feb 11 22:33:47 we actually did most of the work necessary to port the evo mail to eds Feb 11 22:34:08 in terms of refactoring evo so the mail was clean of ui code Feb 11 22:34:40 we didn't actually do the dbus bit Feb 11 22:35:54 but ouy client got distracted by a bee so we had to stop Feb 11 22:38:34 hmm Feb 11 22:38:46 you don't like tinymail for storage backend? Feb 11 22:39:29 evolution mail backend has more developers backing it, novell, redhat, etc Feb 11 22:39:37 supports mapi too Feb 11 22:41:10 it's supposed to be getting better Feb 11 22:41:15 is it right for mobile? Feb 11 22:53:11 denkenz: patch sent. Feb 11 23:39:23 krau: we can merge most part of the bluez side. Since I based my agent code on yours there are similar code on both. Feb 11 23:56:33 s/agent/agent related/g Feb 12 00:12:54 tmzt: I think there's more future in evolution because it has more developers involved with it - it can be made better as necessary. tinymail was forked off evolution's e-mail library (camel) and it's not clear it was forked for good reasons, and has less people working on it now. Feb 12 00:15:55 seemed to me pvanhoof was building it to constrain ram usage Feb 12 00:16:57 at the time camel had corba in it didn't it? Feb 12 00:18:03 camel itself? I don't think so Feb 12 00:18:16 I might be wrong but I thought the corba-ectomy was on higher levels of evo's stack Feb 12 00:18:30 and yes, constraining ram usage isn't an orthogonal goal to upstream maintenance of evolution **** ENDING LOGGING AT Fri Feb 12 02:59:56 2010