**** BEGIN LOGGING AT Fri Aug 27 02:59:57 2010
Aug 27 04:53:02 <e-yes> hi there. how to map signal strength to "signalStrength;  /* Valid values are (0-31, 99) as defined in TS 27.007 8.5 */ " ?   (at least coarse mapping, for signal bars)
Aug 27 05:14:09 <balrog-k1n> 31 is five bars, 0 is 0 bars
Aug 27 05:14:31 <balrog-k1n> ofono exposes it through dbus as 100 = five bars iirc
Aug 27 05:28:32 <e-yes> well, what 85 is in dBm?
Aug 27 05:29:22 <denkenz> use the source, Luke!
Aug 27 05:31:02 <e-yes> the source tells nothing. i'm looking into isimodem: it reported %%
Aug 27 05:31:24 <e-yes> i can patch it to report dBms, but it's not true:)
Aug 27 05:44:21 <e-yes> ok, another question. denkenz, 0-100 signal strength range used by ofono is linear or logariphmic? (or it's something i can't trust or implementation-dependant?)
Aug 27 05:44:53 <denkenz> up to the driver in the end
Aug 27 06:36:04 <akiniemi> e-yes: it's linear
Aug 27 06:36:30 <akiniemi> e-yes: oFono doesn't support dBm values, although isimodem driver has that available as well
Aug 27 06:37:22 <e-yes> akiniemi, so, 80 == 4 bars?
Aug 27 06:37:40 <akiniemi> e-yes: yup, that'll work
Aug 27 06:39:48 <e-yes> akiniemi, thanks, i'll give a try
Aug 27 07:52:51 <holtmann> denkenz: Btw. /lib/udev/rules.d/ is correct for packages.
Aug 27 14:15:20 <denkenz> holtmann: Not everywhere, remember I run exotic distros ;)
Aug 27 18:07:03 <denkenz> balrog-k1n: So I'm getting a Data Not Understood error when I try Set Up Call
Aug 27 18:11:42 <balrog-k1n> denkenz: is your card possibly specifying the subaddress thing?
Aug 27 18:11:49 <denkenz> No, this is on phonesim
Aug 27 18:12:15 <balrog-k1n> ah, let me check if i forgot to send something
Aug 27 18:14:08 <denkenz> Looks like phonesim doesn't set destination as type NETWORK
Aug 27 18:14:43 <denkenz> Do you have a patch handy?
Aug 27 18:35:24 <balrog-k1n> denkenz: right, this is the only change needed
Aug 27 18:35:26 <balrog-k1n> http://pastebin.ca/1927051
Aug 27 18:35:43 <balrog-k1n> sorry, i just updated my phonesim tree and couldn't get it to work
Aug 27 18:36:03 <denkenz> with that patch it works now
Aug 27 18:36:59 <denkenz> ofonod[369]: < \r\n+CSIM: 88,D02881030110008202818385184469616C696E67207468652054696D6520477579202E2E2E86038111499000\r\n\r\nOK\r\n
Aug 27 18:36:59 <denkenz> ofonod[369]: SimToolkitAgent /test/agent replied with error org.freedesktop.DBus.Python.NameError, Traceback (most recent call last):
Aug 27 18:36:59 <denkenz>   File "/usr/lib/pymodules/python2.6/dbus/service.py", line 702, in _message_cb
Aug 27 18:36:59 <denkenz>     retval = candidate_method(self, *args, **keywords)
Aug 27 18:37:00 <denkenz>   File "./test-stk-menu", line 126, in ConfirmCallSetup
Aug 27 18:37:00 <denkenz>     print "Information: (%s)" % (infor)
Aug 27 18:37:06 <denkenz> ofonod[369]: > AT+CSIM=30,A0C2000009D30782020181900103FF\r
Aug 27 18:37:06 <denkenz> ofonod[369]: < \r\n+CSIM: 4,6F00\r\n\r\nOK\r\n
Aug 27 18:37:06 <denkenz> ofonod[369]: Sending Menu Selection to UICC failed
Aug 27 18:37:20 <denkenz> I get that when the agent screws up and I try to select from the menu again
Aug 27 18:37:58 <balrog-k1n> denkenz: with current phonesim i get the same thing until i press "Abort" and "Start" in the phonesim ui
Aug 27 18:38:01 <balrog-k1n> in the "Sim" tab
Aug 27 18:38:30 <denkenz> Yeah, but it means we're not sending a final response if the agent screws up
Aug 27 18:40:22 <denkenz> You forgot an entry in agent_called again ;)
Aug 27 18:41:27 <balrog-k1n> yeah.. just noticed
Aug 27 18:41:57 <denkenz> however, this is nasty to fix
Aug 27 18:42:06 <balrog-k1n> the thing is the agent may unregister freely once it has confirmed the call
Aug 27 18:42:54 <balrog-k1n> a check like stk->cancel_cmd == stk_request_cancel would work
Aug 27 18:43:01 <balrog-k1n> but it's ugly
Aug 27 18:44:36 <denkenz> In theory we don't call Release until the dial finishes
Aug 27 18:50:03 <denkenz> balrog-k1n: We can try getting rid of agent_called and replacing with a simple boolean
Aug 27 18:50:16 <denkenz> However, it would need to be tracked all over the place
Aug 27 18:50:42 <denkenz> It also looks like your cancel_cmd needs to be set twice for set up call, once before agent and once after
Aug 27 18:50:49 <balrog-k1n> denkenz: we can go back to having a agent_busy public function in stkagent.c
Aug 27 18:51:01 <balrog-k1n> it is set twice AFAIR
Aug 27 18:51:55 <denkenz> Yes, you're right sorry
Aug 27 18:52:29 <denkenz> Btw, what if the SIM requests no user action?
Aug 27 18:52:38 <balrog-k1n> checking that stk->pending_cmd != NULL && agent_is_busy should suffice for Display Text, too
Aug 27 18:59:44 <denkenz> balrog-k1n: I don't think so, stk_respond sets pending_cmd to NULL
Aug 27 19:02:31 <balrog-k1n> denkenz: right, but once we respond, we don't need to send USER_TERMINATED
Aug 27 19:02:38 <balrog-k1n> or i'm misundarstanding the issue
Aug 27 19:03:09 <denkenz> I dunno, I'm actually seriously lost in there now
Aug 27 19:03:14 <denkenz> Not a good sign ;)
Aug 27 19:05:59 <balrog-k1n> ;)
Aug 27 19:06:15 <balrog-k1n> as far as i can tell stk->pending_cmd != NULL && agent_is_busy will have the same effect as the current code (without setup call)
Aug 27 19:06:19 <balrog-k1n> i gotta leave for now
Aug 27 19:06:56 <denkenz> nod
Aug 27 19:08:11 <denkenz> Unfortunately its too late to call anything on the agent at that point since it has been cleaned up
Aug 27 19:10:36 <balrog-k1n> oh right
Aug 27 19:10:48 <balrog-k1n> maybe the agent notify callback can take the boolean as a parameter
Aug 27 19:10:57 * balrog-k1n really afk now
**** ENDING LOGGING AT Sat Aug 28 02:59:57 2010