**** BEGIN LOGGING AT Fri Feb 11 02:59:57 2011
Feb 11 07:10:23 <Jeevaka> holtmann, denkenz: ping
Feb 11 07:10:33 <holtmann> Jeevaka: pong
Feb 11 07:12:17 <Jeevaka> holtmann: currently, get properties of radio settings will send failure reply if any one of the property query fails
Feb 11 07:14:04 <Jeevaka> holtmann: e.g: if the TechnologyPreference is success but if the band query fails, then we are ending up in sending failure report for the query
Feb 11 07:15:35 <Jeevaka> any specific reason behind this?
Feb 11 07:15:38 <holtmann> Yes, we know about that.
Feb 11 07:17:05 <holtmann> We might need to look at this again. I think nobody has really played with this in detail.
Feb 11 07:20:14 <Jeevaka> can I work on fixing this?
Feb 11 07:21:39 <Jeevaka> or send an rfc patch on this?
Feb 11 07:21:48 <holtmann> Have a look at it and propose something. I must admit that I haven't looked into radio settings for a while. Denis did the band review.
Feb 11 07:22:13 <Jeevaka> ok
Feb 11 14:18:31 <AnttiP> How would I formulate a DBus signature for method call that can return 1 to 3 arrays of dictionaries? 
Feb 11 14:18:56 <AnttiP> I mean in documentation
Feb 11 14:19:37 <AnttiP> Would aa{sv}aa{sv}aa{sv} be ok?
Feb 11 15:10:11 <fdanis> denkenz: ping
Feb 11 15:11:03 <denkenz> fdanis: pong
Feb 11 15:11:35 <fdanis> denkenz: I asked myself why fd is passed to ofono_emulator_register() instead of a GIOChannel ?
Feb 11 15:11:36 <fdanis> Bluetooth server part returns a GIOChannel to connection cb.
Feb 11 15:11:36 <fdanis> If we want to keep the connection up we need to ref this GIOChannel, while the ofono_emulator_register() will create a second GIOChannel on the same fd.
Feb 11 15:11:36 <fdanis> isn't it better to ditecly pass the GIOChannel to the emulator ?
Feb 11 15:11:59 <fdanis> s/ditecly/directly
Feb 11 15:12:15 <denkenz> fdanis: We have a rule of no-glib types/functions in the ofono public API
Feb 11 15:12:52 <denkenz> And the fd we pass is the one accepted from the server fd
Feb 11 15:13:01 <denkenz> so we don't actually create a GIOChannel needlessly
Feb 11 15:13:45 <fdanis> denkenz: ok, thanks
**** BEGIN LOGGING AT Fri Feb 11 15:15:53 2011
Feb 11 15:39:49 <OlivierG> Denis, regarding the emulator code and how AT commands have to be done, there's two options: 1)AT callbacks are in the emulator and each callback call atom's API  or 2) The callbacks are registered in each corresponding atom (e.g.: +CGDCONT  located in gprs atom). Having all AT related stuffs store in one component (emulator) make sense from architecture pov... on the other hand, separate each AT stuff in each atom make things more "iso
Feb 11 15:41:44 <denkenz> The current thought is to do much of the implementation in the individual atoms
Feb 11 15:42:19 <denkenz> the atom data structures are opaque, so without greatly expanding the internal APIs putting everything in emulator.c is not possible
Feb 11 15:42:34 <denkenz> And expanding internal APIs is something I do not want anyway
Feb 11 15:42:53 <OlivierG> make sense....;) 
Feb 11 15:44:04 <OlivierG> so we just need to add one API to each atom, to allow registering the callbacks...
Feb 11 15:45:13 <denkenz> The api will be added to emulator itself.  Right now I'm thinking of a simple facade around GAtServer
Feb 11 15:45:20 <denkenz> with maybe extra utilities as we have need for them
Feb 11 15:48:11 <OlivierG> something like g_at_server_register_atom() ?
Feb 11 15:48:44 <denkenz> the other way around, so each atom will do something like ofono_emulator_add_handler("+CFOO"..)
Feb 11 15:49:06 <wagi> padovan: I got HFP with PA working. I'm feeling extremly stupid
Feb 11 15:49:19 <wagi> padovan: It was soooo simple 
Feb 11 15:49:59 <wagi> padovan: PA suspends idle streams. So the bluez streams needs a client
Feb 11 15:50:22 <wagi> padovan: therefore a trick like this helps: pactl load-module module-loopback source="alsa_input.pci-0000_00_1b.0.analog-stereo" sink="bluez_sink.CC_08_E0_81_7B_73"
Feb 11 15:54:00 <Gzajac> denkenz, OlivierG: if I well understand, each atom (GRPS, voicecalll, ...) should look for emulator atom type and register its callbacks using an external emulator API such as ofono_emulator_add_handler("+CFOO"..) ?
Feb 11 15:54:22 <Gzajac> Then depending of the emulator type the right CB will be registered.
Feb 11 15:55:31 <denkenz> yep
Feb 11 15:55:52 <Gzajac> However for data call where should the CB be located ?
Feb 11 15:56:02 <Gzajac> for dun dial
Feb 11 16:01:39 <Jeevaka> denkenz: ping
Feb 11 16:04:10 <Gzajac> denkenz: I will think about it, I'll come back to you on monday.
Feb 11 16:09:15 <denkenz> Jeevaka: pong
Feb 11 16:09:46 <denkenz> Gzajac: Can be in gprs.c or emulator.c, no real difference
Feb 11 16:14:42 <fdanis> denkenz: for specific bluetooth AT commands, should I set them in emulator.c, hfp_ag.c (plugin) or in a new bluetooth atom ?
Feb 11 16:15:10 <denkenz> fdanis: Might depend on the command
Feb 11 16:15:25 <denkenz> e.g. BLDN might be easier done in voicecall
Feb 11 16:15:32 <fdanis> denkenz: like AT+BRSF, AT+BLDN
Feb 11 16:15:47 <denkenz> BRSF can be done in emulator
Feb 11 16:15:56 <fdanis> ok
Feb 11 16:19:19 <balrog-k1n> Jeevaka: i think the api definition needs to list errors that the clients need to be prepared to handle, not necessarily what the current implementation returns
Feb 11 16:20:01 <fdanis> denkenz: the difference between voice or data emulator will be done on ofono_emulator_type, right ?
Feb 11 16:20:22 <denkenz> fdanis: either that or on the atom type
Feb 11 16:20:42 <fdanis> there will be 2 atom type ?
Feb 11 16:20:59 <denkenz> fdanis: possibly, I need to think on what is better
Feb 11 16:21:12 <denkenz> Maybe we end up using the emulator type only
Feb 11 16:21:57 <Jeevaka> balrog-k1´n: yep, agree with you but the current ai document doesnt even cover tha case
Feb 11 16:22:19 <Jeevaka> balrog-k1n: yep, agree with you but the current ai document doesnt even cover tha case
Feb 11 16:22:36 <balrog-k1n> Jeevaka: true, i mean "in addition to what the implementation returns"
Feb 11 16:22:56 <Jeevaka> balrog-k1n: my intention is to start with the current one and end up with the final ones
Feb 11 16:23:05 <balrog-k1n> ah okay
Feb 11 16:23:33 <denkenz> balrog-k1n: Do you mean the D-Bus ones? like timedout and stuff?
Feb 11 16:24:00 <fdanis> denkenz: so, one atom type by connection type : DUN, HFP AG and USB
Feb 11 16:24:11 <balrog-k1n> denkenz: yep, or InvalidFormat in "SetProperty"
Feb 11 16:24:43 <denkenz> balrog-k1n: InvalidFormat definitely needs to be added to the doc.  I'm not so sure about org.freedesktop ones
Feb 11 16:25:04 <denkenz> fdanis: Perhaps, I'm not decided on this one, it is one idea
Feb 11 16:26:53 <Jeevaka> denkenz, balrog-k1n: patch i sent will atleast give a  view on where we are at the moment :)
Feb 11 16:27:07 <denkenz> The patch is a good start
Feb 11 16:27:16 <denkenz> let me do a brief check and I apply it
Feb 11 16:30:17 <Jeevaka> balrog-k1n: denkenz: GetIcon is seen in SimToolKit and also in SimManager interface
Feb 11 16:31:07 <fdalleau> denkenz: padovan: I have sent to the list the patch for using FindAdapter and AddRecord, it simplifies the code a bit but  in some cases there is an addional ipc. Not a big deal, feel free to have a look
Feb 11 16:31:35 <Jeevaka> atleast we need to remove it from stk-api.txt document as it is not implemented in SimTooKit interface
Feb 11 16:32:00 <balrog-k1n> Jeevaka: yes, good point
Feb 11 16:32:47 <denkenz> Jeevaka: wanna send a patch?
Feb 11 16:32:50 <Jeevaka> can i send a separate patch for that
Feb 11 16:32:52 <Jeevaka> doing it
Feb 11 16:33:01 <Jeevaka> will send it few minutes ;)
Feb 11 16:46:42 <Jeevaka> denkenz: i hope you expect me to rebase to the latest upstream
Feb 11 16:49:20 <Jeevaka> denkenz: may i know through which URC calling name comes for an waiting call?
Feb 11 16:50:02 <pnunes> denkenz: in the TODO file, I can read "Bluetooth SAP Client support" in the miscellaneous paragraph. I'm confused, I thought that the goal was to support the SAP server mode ?
Feb 11 16:50:32 <pnunes> In server mode, we could indeed establish a SAP connection with the Telit modem. Could you confirm the purpose of the Telit modem?
Feb 11 16:52:56 <Jeevaka> pnunes: SAP supports needs SAP to be supported in bluez and also support for sending the APDU to the sim should be supported
Feb 11 16:54:58 <Jeevaka> most of AT modems dont support CSIM. so atleast I dont know how this can be done for AT modems
Feb 11 16:55:52 <pnunes> jeevaka: as you know we just received a new SET of AT commands related to SAP for ifx (at least the documentation)
Feb 11 16:56:25 <pnunes> jeevaka: The client mode is not supported however. 
Feb 11 16:56:56 <pnunes> jeevaka: do we want to support also the SAP client for meego ivi ?
Feb 11 16:58:28 <Jeevaka> pnunes: i dont have any idea on support of this for meego ivi
Feb 11 16:59:33 <denkenz> pnunes: SAP server is not in scope for oFono, that is a backdoor to the modem
Feb 11 16:59:40 <denkenz> pnunes: SAP Client is very much like the HFP client
Feb 11 16:59:56 <denkenz> Jeevaka: URC for a waiting call?
Feb 11 17:00:28 <Jeevaka> as per the spec, calling name of an incoming call comes via CNAP
Feb 11 17:00:50 <Jeevaka> whats the case for waiting call?
Feb 11 17:00:57 <denkenz> Jeevaka: CNAP is not done for waiting calls AFAIK
Feb 11 17:01:33 <Jeevaka> but atleast the spec 3GPP TS 22.096 is commenting on the waiting call
Feb 11 17:02:03 <denkenz> 27.007 only mentions CNAP being done after RING/CRING
Feb 11 17:02:14 <denkenz> and CCWA does not have CNAP information
Feb 11 17:02:25 <Jeevaka> yes, thats my point
Feb 11 17:02:33 <Jeevaka> atleast AT spec is not clear
Feb 11 17:02:37 <pnunes> denkenz: precisely, ifx is about to support this feature. So the server mode is something we could consider with iCDK/nCDK boards and actually this feature is required by the vertical product.
Feb 11 17:03:17 <Jeevaka> denkenz: check 22.096 section 4.6.7
Feb 11 17:03:21 <denkenz> pnunes: My understanding of SAP server is that this physically bypasses half the modem fw implementation and gives direct control of the SIM card reader to the remote side
Feb 11 17:03:32 <denkenz> pnunes: So effectively oFono is not even running anyway
Feb 11 17:03:40 <denkenz> Or at least not managing the modem
Feb 11 17:04:29 <denkenz> Likely this has to be done as an IFX extension
Feb 11 17:04:52 <denkenz> Jeevaka: I believe you, but if 27.007 doesn't have it, then your guess is as good as mine ;)
Feb 11 17:05:03 <denkenz> Perhaps IFX has a separate URC for waiting calls?
Feb 11 17:05:34 <Jeevaka> denkenz: i haven't seen one for waiting call :)
Feb 11 17:05:49 <denkenz> Then it is probably yet-another-omission by 3GPP
Feb 11 17:06:25 <denkenz> Just like CLCC disaster, or the omission of SIM states
Feb 11 17:07:01 <Jeevaka> nod
Feb 11 17:07:24 <denkenz> Give a test if you can
Feb 11 17:07:30 <denkenz> Maybe CNAP is emitted after CCWA as well
Feb 11 17:09:02 <Jeevaka> network support for testing is another issue
Feb 11 17:09:30 <denkenz> Yep, this has to be done on the simulator or clarified with IFX
Feb 11 17:09:41 <denkenz> But at least according to 27.007, CNAP is not possible on waiting calls
Feb 11 17:09:59 <denkenz> And this is not the first time 22.0* and 27.007 disagree
Feb 11 17:19:34 <Jeevaka> denkenz: did you get my patch on CNAP support for ifx modem?
Feb 11 17:21:00 <Jeevaka> just to confirm that gmail hasnt played its part on this ;)
Feb 11 17:21:31 <denkenz> Yeah I have this one
Feb 11 17:24:17 <denkenz> happy now? ;)
Feb 11 17:25:32 <Jeevaka> yep, will be able to spend the weekend peacefully :)
Feb 11 17:28:16 <denkenz> hehe, glad to be of service ;)
Feb 11 17:51:50 <crevetor> Hello
Feb 11 17:51:50 <crevetor> I know that ofono isn't specifically tied to Nokia but how do you guys feel about it ?
Feb 11 17:53:20 <denkenz> crevetor: Please don't bother asking this question, the answer is no comment
Feb 11 17:54:02 <denkenz> oFono project continues as before
Feb 11 17:54:19 <crevetor> Hum ok...
Feb 11 17:55:03 <crevetor> As if nobody from Nokia is working on it..
Feb 11 18:56:37 <Jeevaka> denkenz: any reason behind GetProperties of RadioSettings interface returning error even if query of one property fails?
Feb 11 18:57:13 <denkenz> They are all local properties
Feb 11 18:57:16 <denkenz> they should not fail
Feb 11 18:57:46 <Jeevaka> hmm. even fast dormancy?
Feb 11 18:57:56 <denkenz> still a local setting
Feb 11 18:58:44 <denkenz> Its also only returning a failure if the original query failed
Feb 11 18:58:52 <denkenz> If you cache the setting then it won't fail after that
Feb 11 18:59:05 <denkenz> That seems to be a decent compromise
Feb 11 18:59:27 <denkenz> I don't really like introducing things like "unknown" and stuff
Feb 11 18:59:46 <Jeevaka> got the point
Feb 11 19:00:26 <Jeevaka> found one strange thing with respect to XRAT
Feb 11 19:01:09 <Jeevaka> as per the spec, SET command of XRAT is +XRAT=<ACT>[,<Pref.ACT]
Feb 11 19:02:06 <Jeevaka> if ACT=1, then pref.ACT is mandatory. but currently we are sending +XRAT=0,2 which doesnt make sense
Feb 11 19:02:58 <denkenz> I never looked at that part of the IFX spec, I think holtmann wrote that code
Feb 11 19:03:10 <denkenz> But if it doesn't sound right to you, then it probably isn't
Feb 11 19:03:32 <Jeevaka> seems to be working but what if this is fixed in the future modem releases then we are in trouble
Feb 11 19:04:09 <Jeevaka> currently, both works fine +XRAT=0,2 and +XRAT=0 :)
Feb 11 19:04:19 <denkenz> lol
Feb 11 19:04:42 <Jeevaka> i'll deliver a fix patch for this
Feb 11 20:33:43 <holtmann> We just released the magical 0.42 version of oFono. Have fun with it ;)
Feb 11 20:44:38 <padovan> A Release post on oFono.org would be good.
Feb 11 20:44:46 <padovan> :)
**** ENDING LOGGING AT Sat Feb 12 02:59:57 2011