**** BEGIN LOGGING AT Thu Jun 16 02:59:57 2011 Jun 16 10:03:51 Hi Jun 16 10:17:57 I'm trying to listen to the CallAdded signal available in VoiceCallManager Interface Jun 16 10:18:09 But I'm not receiving any events... Jun 16 10:18:32 Even though the call is going through fine... Jun 16 14:20:53 denkenz: ping Jun 16 14:21:05 nbertrand: pong Jun 16 14:21:45 Hello, I've sent a patch the last week about call forward but it has'nt been applied. Is there any problem or do i need to simply resend it after a rebase? Jun 16 14:25:41 nope, I'm just too busy with some other stuff, I try to get to it today Jun 16 14:27:53 i did a mistake about // comment so I've updated my change with the right format, it could be simplier if i resend the patch Jun 16 14:29:12 that would be fine as well Jun 16 14:46:40 denkenz: Hi, I suppose also you didn't get time to read my answers/questions regarding your review of the patch v4 for STK class e? I'm trying to rework my patches according your comments but I miss some clarifications... Jun 16 14:47:20 pnunes: of course I did Jun 16 14:47:25 pnunes: Whats up? Jun 16 14:50:52 denkenz: Ok, I would like to clarify why you think we don't need to create a pri-context for stk? Jun 16 14:51:40 because pri_context is used to track properties settable on the context over D-Bus Jun 16 14:51:55 you have no need for that, you can simply activate the context with the settings provided by stk atom Jun 16 14:53:36 denkenz: precisely, how can I activate a context without referring to a pri-context. I missed something Jun 16 14:54:17 void (*activate_primary)(struct ofono_gprs_context *gc, Jun 16 14:54:17 const struct ofono_gprs_primary_context *ctx, Jun 16 14:54:18 ofono_gprs_context_cb_t cb, void *data); Jun 16 14:54:28 As you see, there's no pri-context there ;) Jun 16 15:07:42 denkenz: I thought that the gprs-context was linked to the resources of the modem. So, according to me, it was not possible to add new ones. You mean we can change the settings of an existing gprs_context ? Jun 16 15:08:34 The number of gprs-contexts is linked to the modem capability, yes Jun 16 15:08:46 But the _settings_ aren't Jun 16 15:09:05 All you're doing with stk is activating a context with new settings Jun 16 15:09:31 That is exactly what gprs.c does, it just stores _extra_ settings inside pri_context Jun 16 15:09:38 you don't need those extra settings Jun 16 15:13:29 denkenz: Ok, it's more clear. Thanks. I will rework my patch in consequence. An other point is the ring buffer you mentioned for the transmit buffer. Do you think this is really needed as I don't think we could store and send in the same time ? Jun 16 15:15:44 It depends on whether you want to be paranoid or not Jun 16 15:16:17 There are two things you can do: Jun 16 15:16:25 - Make the socket always non-blocking Jun 16 15:16:34 - Make the socket blocking after the connect phase Jun 16 15:16:59 In case the socket is non-blocking, you need to use some sort of temp buffer for the write Jun 16 15:17:16 For reading you can simply use ioctl to find the # of bytes available, and read directly when SIM requests it Jun 16 15:17:31 For the blocking case you don't need any buffers Jun 16 15:18:07 Since the traffic from the SIM is most likely very low, we can probably get away with that Jun 16 15:20:02 denkenz: Ok, I see. For GCF, tests are simple , just sending or receiving 200 bytes. And it's not dynamic. But I agree, in the real world, a ring buffer could be more safe. Jun 16 15:24:19 denkenz: Thanks for your clarification. Jun 16 15:26:36 its not any safer, just more efficient Jun 16 15:27:12 however, unless you're planning to do something like Sim Card Web Server, the level of traffic will be tiny Jun 16 15:27:28 So even blocking socket will be plenty **** ENDING LOGGING AT Fri Jun 17 02:59:56 2011