**** BEGIN LOGGING AT Fri Feb 04 02:59:57 2011
Feb 04 07:46:19 <jussi_> Hey, could Marcel or somebody else comment back the mail "Re: [PATCH] plugins:ste:preparation for hotswap" I sent in last Monday 10:45:47 so I could change the patch?
Feb 04 13:20:46 <Jeevaka> denkenz, holtmann: ping
Feb 04 13:21:28 <holtmann> Jeevaka: pong
Feb 04 13:22:41 <Jeevaka> currently, we are using call status values in drivers/atmodem/voicecall.c and few other laces 
Feb 04 13:23:09 <Jeevaka> eg: g_slist_find_custom(vd->calls, GINT_TO_POINTER(5), at_util_call_compare_by_status
Feb 04 13:23:32 <Jeevaka> can we change it to the defined enums?
Feb 04 13:23:32 <holtmann> Jeevaka: You really wanna talk to Denis about this one.
Feb 04 13:24:02 <Jeevaka> will discuss with him
Feb 04 13:25:01 <Jeevaka> holtmann: next question might be a dump question
Feb 04 13:26:11 <Jeevaka> generic at command doesn't provide a way to reject an incoming call. does it mean that no atmodems is providing support for incoming call reject?
Feb 04 13:26:39 <Jeevaka> considering no proprietary command is provided
Feb 04 13:27:09 <holtmann> All AT modem voicecall stuff is Denis expertise area. I would need to go back and read the specs.
Feb 04 13:27:46 <holtmann> Generally speaking. The AT commands for voice call handling are a disaster area.
Feb 04 13:27:58 <holtmann> Someone really needs to start fixing the specification there.
Feb 04 13:28:25 <holtmann> oFono has a specific voicecall driver for every single modem supporting it.
Feb 04 13:28:55 <Jeevaka> yep, noticed it
Feb 04 14:18:29 <mr_amit> hi all
Feb 04 14:19:20 <mr_amit> I have sent a patch to ofono mailing list for Linktop LW273/LW272 modems
Feb 04 14:19:56 <mr_amit> but it seems it is waiting for moderator's approval 
Feb 04 14:21:06 <mr_amit> if any admin/moderator here
Feb 04 14:21:16 <mr_amit> would you please check for that?
Feb 04 14:23:40 <mr_amit> okay, it's there in archive 
Feb 04 14:23:42 <mr_amit> http://lists.ofono.org/pipermail/ofono/2011-February/008501.html
Feb 04 14:24:14 <mr_amit> however, there is no inputs from ofono team
Feb 04 14:25:48 <mr_amit> this patch adds support for Linktop LW273/LW272 devices
Feb 04 14:26:06 <mr_amit> distributed by BSNL in India (with Teracom brand name)
Feb 04 14:27:05 <mr_amit> the device seems to be based on ST-Ericsson chipset but `ste` plugin doesn't work with these devices
Feb 04 14:30:09 <mr_amit> I will post device related information to that thread, if required
Feb 04 14:30:16 <mr_amit> please review it let me know
Feb 04 14:39:32 <holtmann> mr_amit: Just re-send the patch.
Feb 04 14:39:48 <holtmann> Make sure you are subscribed to the mailing list with the email address you are sending the patch from.
Feb 04 14:40:45 <mr_amit> holtmann: it here http://lists.ofono.org/pipermail/ofono/2011-February/008501.html
Feb 04 14:41:17 <mr_amit> I missed the mail (may be I deleted it from my mail box)
Feb 04 14:41:49 <mr_amit> so I thought it may be waiting for approval
Feb 04 14:42:12 <holtmann> Just create a brand new patch and send it.
Feb 04 14:42:23 <mr_amit> holtmann: ok
Feb 04 14:48:35 <demarchi> holtmann: denkenz: what's the purpose of the cb in a tx_queue_entry?
Feb 04 14:48:54 <demarchi> should i call the callback when message is cancelled?
Feb 04 14:50:36 <mr_amit> holtmann: done
Feb 04 14:51:12 <mr_amit> holtmann: with subject `[PATCH] plugin: add plugin for Linktop/Teracom LW273 data card`
Feb 04 15:08:01 <balrog-k1n> demarchi: if it's cancelled before being sent to network, then no
Feb 04 15:08:02 <balrog-k1n> iirc
Feb 04 15:09:44 <balrog-k1n> or actually.. it might make more sense to call it with ok==FALSE
Feb 04 15:14:37 <balrog-k1n> demarchi: it's used when the SIM card requests a message to be sent
Feb 04 15:15:15 <balrog-k1n> the response ofono returns to the SIM depends on whether the message could be submitted to network
Feb 04 15:41:28 <demarchi> balrog-k1n: humn.... i've just sent the patch series
Feb 04 15:41:52 <demarchi> balrog-k1n: currently i don't call
Feb 04 15:42:12 <demarchi> balrog-k1n: could you take a look?
Feb 04 15:47:04 <fdanis> padovan: ping
Feb 04 15:47:14 <denkenz> Jeevaka: what is meant by reject an incoming call?
Feb 04 15:47:29 <denkenz> Jeevaka: Is there a reason why Hangup doesn't work for you?
Feb 04 15:48:30 <fdanis> denkenz: I sent the fixed version of bluetooth server support
Feb 04 15:50:15 <denkenz> padovan: ^^^^
Feb 04 15:50:20 <denkenz> Is the new version all good with you?
Feb 04 15:53:41 <demarchi> denkenz: currently there's a bug in src/sms.c:tx_next(). We deref entry and after check if it's NULL. As far as I could see, there's no chance to call tx_next() with entry == NULL
Feb 04 15:53:54 <demarchi> are you against just deleting the check for NULL?
Feb 04 15:56:04 <denkenz> demarchi: go ahead, but please eyeball it some more to make sure
Feb 04 15:56:54 <demarchi> denkenz: ok... but i'm almost sure it will conflict with my last patches... so i'll send on top of them, ok?
Feb 04 15:59:00 <denkenz> yeah that should be ok
Feb 04 16:38:27 <Jeevaka> denkenz: ping
Feb 04 16:38:38 <denkenz> Jeevaka: pong
Feb 04 16:39:51 <Jeevaka> my question is about the user busy for an incoming call
Feb 04 16:40:18 <denkenz> no AT modem supports udub on incoming
Feb 04 16:40:23 <denkenz> That is ISI magic
Feb 04 16:41:21 <Jeevaka> agree. does it mean that no at modems provide even proprietary cmd for that case
Feb 04 16:42:18 <padovan> fdanis: denkenz: ok, I'll look to it in a bit.
Feb 04 16:42:37 <denkenz> Jeevaka: I have never seen one
Feb 04 16:43:04 <denkenz> It might be different between manufacturers as well
Feb 04 16:43:13 <denkenz> e.g. some might choose to send user busy, others user release, etc
Feb 04 16:44:53 <Jeevaka> you will see one soon :) ifx modem provides an AT cmd, will send a patch on that
Feb 04 16:45:29 <denkenz> How does that help you?
Feb 04 16:45:45 <denkenz> The core used to have UDUB on Incoming calls, but I removed that since no modem actually supported it
Feb 04 16:46:27 <Jeevaka> same like the way I did for isimodem
Feb 04 16:47:36 <Jeevaka> in driver side hangup code depending on the status, we can trigger the at command
Feb 04 16:47:39 <denkenz> So instead of calling ATH you will call the vendor command?
Feb 04 16:47:51 <denkenz> Seems silly, why not just make IFX use the right response code on ATH ;)
Feb 04 16:48:34 <Jeevaka> still going to call the ATH
Feb 04 16:49:03 <Jeevaka> before ATH, we need to issue vendor specific at command for setting the cause
Feb 04 16:49:14 <denkenz> why bother?
Feb 04 16:49:28 <denkenz> Seriously, if UDUB on incoming is what you want, just make IFX always do that
Feb 04 16:51:42 <Jeevaka> ok, will verify that
Feb 04 16:52:31 <Jeevaka> by the way, we are currenlty using call status values directly in atmodem/voicecall.c and few more places
Feb 04 16:52:48 <denkenz> yes yes, another one
Feb 04 16:53:03 <Jeevaka> can we make use of the defined enums?
Feb 04 16:53:33 <denkenz> yes you can use common.h defines
Feb 04 16:53:50 <denkenz> ;)
Feb 04 16:54:03 <Jeevaka> yep, that my idea as well
Feb 04 17:45:00 <padovan> fdanis: +#define TIMEOUT (60) 
Feb 04 17:45:07 <padovan> no parenthesis here
Feb 04 20:12:54 <padovan> fdanis: no need for resend your patches, I fixed them for you.
Feb 04 20:43:23 <holtmann> +               (0x1 << CALL_STATUS_INCOMING) | (0x1 << CALL_STATUS_WAITING);
Feb 04 20:43:39 <holtmann> Jeevaka: I actually prefer (1 << x) style here and not 0x1.
Feb 04 20:45:18 <holtmann> denkenz: Any reason why you are doing 0x1 for the bit shift here?
Feb 04 20:46:03 <denkenz> no particular reason
Feb 04 20:46:12 <denkenz> Probably had hexmode turned on in the brain
Feb 04 20:50:24 <holtmann> We should fix these.
Feb 04 21:43:33 <padovan> denkenz: how do you like resends? I like to resend everything even if the change was in only patch.
Feb 04 21:45:06 <denkenz> resends are fine
Feb 04 21:46:17 <padovan> ok, done
**** ENDING LOGGING AT Sat Feb 05 02:59:57 2011