**** BEGIN LOGGING AT Thu Dec 16 02:59:57 2010
Dec 16 08:48:04 <chris81> Hello @all
Dec 16 08:48:39 <chris81> Can some tell me how I add my 3g modem to ofonos udev list?
Dec 16 08:51:01 <chris81> I located /lib/udev/rules.d/97-ofono.rules
Dec 16 08:54:05 <chris81> the kernel finds my modem I got a /dev/ttyACM0 device
Dec 16 11:01:22 <chris81> Hello @all
Dec 16 11:01:36 <chris81> Is someone there who can help me?
Dec 16 11:01:46 <chris81> I want to activate my modem with ofono
Dec 16 11:09:36 <Jeevaka> balrog-k1n: ping
Dec 16 11:45:05 <balrog-k1n> pong Jeevaka 
Dec 16 11:53:19 <zrafa>  /names
Dec 16 12:21:46 <Jeevaka> balrog-k1n:we may have issues on the null text string object in stk
Dec 16 12:28:32 <balrog-k1n> Jeevaka: but i thought we never send null text to the core
Dec 16 12:29:27 <balrog-k1n> stkutil.c replaces null with ""
Dec 16 12:31:44 <Jeevaka> for Display Text and Set up Idle mode text, if text string object is present with len = 0(null text string), then ME should sent TR with command data not understood
Dec 16 12:33:27 <Jeevaka> refer ETSI TS 102 384 27.22.4.1 Expected Sequence 1.9
Dec 16 12:34:18 <Jeevaka> empty text string is basically, text string object with len=1, only dcs but no text string value
Dec 16 12:36:25 <balrog-k1n> Jeevaka: TS 102 223 6.6.22 explictly allows text object with len=0
Dec 16 12:38:45 <balrog-k1n> but yeah, for Display Text we probably need to return command not understood
Dec 16 12:38:55 <Jeevaka> but TS 102 384 27.22.4.22.2 expected sequence 2.4 is not matching with that
Dec 16 12:40:39 <Jeevaka> is the 27.22.4.22.2 expected sequence 2.4 is failing due to empty text string when the icon is not self-explanatory 
Dec 16 12:41:36 <balrog-k1n> yeah, i wonder if it is because of the icon
Dec 16 12:42:27 <balrog-k1n> then perhaps in stkutil.c we need to differentiate between NULL and "" and actually return the correct value, instead of always return ""
Dec 16 12:48:07 <Jeevaka> yep, note: len=1 means empty text string
Dec 16 12:49:36 <balrog-k1n> Jeevaka: but do you agree that we don't need to treat empty text string specially?
Dec 16 12:50:13 <balrog-k1n> i don't see any note about text string with len=1 in TS 102 223
Dec 16 12:50:19 <balrog-k1n> it's just a text with 0 characters
Dec 16 12:52:22 <Jeevaka> yep, agree we dont need to have special handling for empty text string
Dec 16 12:58:23 <Jeevaka> balrog-k1n: due to the set up idle mode text case, i think the fix might be a little bit tricky
Dec 16 13:01:51 <balrog-k1n> yes, maybe we should do the checks in parse_display_text and in parse_setup_idle_mode in stkutil.c
Dec 16 13:02:16 <balrog-k1n> Jeevaka: i'll try to fix this scenario and the Display Text scenario and send a patch tomorrow because i won't have any time to code today
Dec 16 13:03:17 <balrog-k1n> unless you want to do it
Dec 16 13:04:11 <Jeevaka> balrog-k1n: if you haven't started on this, then I can do it. I'm ok with either way
Dec 16 13:04:25 <balrog-k1n> i haven't started
Dec 16 13:05:03 <Jeevaka> ok, i'll start working on it. Thanks for your time
Dec 16 13:08:22 <balrog-k1n> thanks for noticing the issue :)
Dec 16 13:08:41 <balrog-k1n> i probably need to go through every test case and figure out if we comply
Dec 16 13:54:02 <pessi> chenmin: the n900 modem barfs if you have ALS line 2 enabled
Dec 16 14:00:33 <chris81> May someone tell me how I use the enter-pin script?
Dec 16 14:01:01 <chris81> it says something like ./enter-pin [PATH] pin_type pin
Dec 16 14:01:19 <chris81> but what is pin_type? Is PATH /dev/ttyACM0 ?
Dec 16 14:16:55 <balrog-k1n> chris81: path is the dbus path to modem object
Dec 16 14:17:12 <balrog-k1n> chris81: type is one of "pin", "puk", "pin2" etc
Dec 16 14:17:43 <balrog-k1n> you can just skip the PATH iirc
Dec 16 14:17:48 <chris81> i got it now
Dec 16 14:45:53 <chris81> How do I now connect to the internet? I hgot my modem with list-modem and an can enter my pin with enter-pin
Dec 16 14:53:31 <chris81> A voicecall does not work with test-voicecall
Dec 16 14:57:50 <balrog-k1n> what is the error?
Dec 16 14:58:05 <balrog-k1n> running ofono with -n -d \* would give you some more info in the console about what failed
Dec 16 15:03:24 <chris81> ok
Dec 16 15:04:16 <chris81> Voicecall proberty 'State' changed to 'disconnected'
Dec 16 15:04:23 <chris81> Call list modification>
Dec 16 15:04:30 <chris81> No calls in systems
Dec 16 15:04:36 <chris81> Hanging up
Dec 16 15:04:51 <chris81> perhaps i can test with sending an sms
Dec 16 15:05:07 <chris81> how do I use the 'send-sms' script?
Dec 16 16:01:05 <pessi> send-sms number content ?
Dec 16 18:24:55 <Jeevaka> denkenz: ping
Dec 16 18:25:36 <denkenz> pong
Dec 16 18:25:45 <Jeevaka> any comments on the cfis
Dec 16 18:27:23 <denkenz> i still think you can get rid of the cfis string in call forwarding data and instead call the sim writer only when the voice unconditional attribute is changed in set_new_cond
Dec 16 18:31:00 <Jeevaka> do you mean the cfu_number?
Dec 16 18:31:41 <denkenz> yeah
Dec 16 18:33:19 <Jeevaka> thats the number read from sim
Dec 16 18:35:20 <denkenz> I know, but the only reason you added it was to check that number changed when writing to sim
Dec 16 18:36:05 <Jeevaka> s
Dec 16 18:36:39 <Jeevaka> ok, i got the the point
Dec 16 18:38:58 <Jeevaka> this will require the additional check in sim write function to be removed
Dec 16 18:39:42 <denkenz> I know, but this should all turn out cleaner
Dec 16 18:39:54 <denkenz> all it requires is 2-3 extra ifs in set_new_cond
Dec 16 18:40:17 <denkenz> and maybe 1 extra boolean parameter to that function
Dec 16 18:40:55 <Jeevaka> ok
Dec 16 19:46:58 <kvalo> denkenz: hi. my huawei is not working with 2.6.37-rc5, but works with older kernels. have you heard anything related?
Dec 16 19:47:21 <denkenz> nope
Dec 16 20:19:50 <mickeyl> is there a way to forward the PHONET protocol so that one could run gisi on the PC talking to a N900 connected via USB?
Dec 16 20:20:52 <holtmann> mickeyl: It does that anyway via the phonet-gadget and usbpn driver.
Dec 16 20:21:03 <holtmann> Just not all ISI services are available.
Dec 16 20:21:38 <mickeyl> holtmann: thanks, sounds good. do you have a link offhand for how to set this up properly?
Dec 16 20:21:40 <holtmann> Check oFono since we actually do support that.
Dec 16 20:21:56 <mickeyl> ok, will take a look. thanks.
Dec 16 20:21:57 <holtmann> Nothing to set up. ISI does that internally inside the kernel.
Dec 16 20:22:15 <holtmann> We just need an udev rule for mapping that interface properly.
Dec 16 20:22:22 <mickeyl> hmm, well i don't run maemo on the n900, so that could be a problem
Dec 16 20:22:59 <holtmann> As far as I recall, with the right kernel drivers this works out of the box.
Dec 16 20:23:10 <mickeyl> awesome. will check that out
Dec 16 20:23:16 <holtmann> However you need the Nokia gadget that include f_phonet. Otherwise it is not shared.
Dec 16 20:23:22 <mickeyl> ah, right
Dec 16 20:23:48 <holtmann> The ISI modem has an internal firewall. So not sure what is exposed over USB in the end. Compared to what is exposed internally to the device.
Dec 16 20:25:08 <mickeyl> *nod* there may be limitations. but getting SIM and network and perhaps even call handling would be sufficient for a start. 
Dec 16 20:25:21 <mickeyl> i just don't fancy cross-compiling for every little change
Dec 16 20:25:44 <holtmann> I work on Intel hardware, I don't have to ;)
Dec 16 20:25:51 <mickeyl> heh
Dec 16 20:26:21 <mickeyl> oh the joy of developer boards :)
Dec 16 21:14:58 <Jeevaka> denkenz: ping
Dec 16 21:15:08 <denkenz> yep?
Dec 16 21:16:19 <Jeevaka> fix provided for the null text string handling will not fulfill all the cases
Dec 16 21:20:08 <denkenz> Then send a patch and make sure balrog-k1n sees it
Dec 16 21:20:41 <Jeevaka> we have already discussed that today morning
Dec 16 21:21:05 <denkenz> and the outcome?
Dec 16 21:22:39 <Jeevaka> i deliver the fix patch which is done now
Dec 16 21:23:32 <denkenz> ok, then I let you two figure this out
Dec 16 21:23:38 <denkenz> You know this stuff as well as me by now
Dec 16 21:24:35 <Jeevaka> now i have few questions on the user activity and language selection event downloads
Dec 16 21:25:05 <Jeevaka> do i need to discuss this as well with balrog-k1n
Dec 16 21:26:08 <denkenz> These are basically pointless
Dec 16 21:26:38 <denkenz> Just accept the setup event with these, but we'll never act on them
Dec 16 21:27:06 <Jeevaka> so, there is no plans for providing support for this
Dec 16 21:27:24 <denkenz> I don't really see a point
Dec 16 21:27:33 <Jeevaka> ok
Dec 16 21:29:45 <denkenz> so we are waffling back to using NULL for empty strings eh?
Dec 16 21:31:28 <denkenz> You guys should really make up your mind ;)
Dec 16 21:33:42 <Jeevaka> i think we have made up our mind now ;)
Dec 16 21:34:24 <Jeevaka> User activity, language selection and idle screen available are mandatory ones
Dec 16 21:34:54 <denkenz> But are still utterly pointless
Dec 16 21:39:56 <Jeevaka> I dont know the use of user activity, but language selection and idle screen available seems to have some usage
Dec 16 21:41:27 <denkenz> user activity we're just not doing ever, that is beyond silly
Dec 16 21:41:53 <denkenz> idle screen I can maybe swallow
Dec 16 21:43:02 <denkenz> But I still want to see how that is used in actual applications
Dec 16 21:43:44 <denkenz> hm, I'm not particularly fond of patch #2 fixes
Dec 16 21:43:52 <denkenz> Why are we allowing null strings for display text?
Dec 16 22:00:08 <Jeevaka> do you want me to send only the 2nd patch or the as usual complete set of patches
Dec 16 22:12:05 <denkenz> so here's what I think, tell me if I'm wrong
Dec 16 22:13:07 <Jeevaka> ok
Dec 16 22:13:19 <denkenz> we should not allow len == 0 for get_inkey, get_input or display_text
Dec 16 22:14:16 <denkenz> for set_idle_text we allow it if icon is also not present
Dec 16 22:14:33 <denkenz> these checks should be done inside stkutil themselves
Dec 16 22:15:04 <denkenz> now, I'm still questioning len == 1 validity for get_inkey, get_input and display_text
Dec 16 22:15:32 <denkenz> sounds like those should be allowed, but we use g_new0(char, 1) for that
Dec 16 22:16:56 <Jeevaka> len == 0 is valid case for get inkey and get input
Dec 16 22:17:43 <denkenz> sigh, then the test spec is weird
Dec 16 22:18:21 <denkenz> This entire STK spec is designed by monkeys, why do they even bother allowing len == 1 case
Dec 16 22:19:34 <Jeevaka> empty string(len=1), null string(len=0) is the same.
Dec 16 22:20:18 <Jeevaka> node
Dec 16 22:20:46 <denkenz> not really, remember you also have the case of the object not being present
Dec 16 22:21:24 <denkenz> So if they were sane they'd do empty == len 0, null == object not present
Dec 16 22:21:29 <denkenz> and len = 1 is invalid
Dec 16 22:21:45 <Jeevaka> Text string is mandatory for most of this pcmds
Dec 16 22:21:56 <denkenz> Yes, because the original spec was sane
Dec 16 22:22:03 <denkenz> Then they went stupid and added class c
Dec 16 22:23:58 <denkenz> so does display text ever have empty / null whatever strings?
Dec 16 22:25:21 <Jeevaka> Display text without text. I think not
Dec 16 22:26:27 <denkenz> shrug, you never know with these things
Dec 16 22:26:34 <denkenz> Why is get_input allowing empty strings then ;)
Dec 16 22:27:35 <Jeevaka> bez its valid, get input main purpose is to get the input. Text is an addition info
Dec 16 22:28:00 <denkenz> Shrug, then they should have made the object optional, just like 'default text'
Dec 16 22:28:48 <denkenz> however, they did not
Dec 16 22:29:56 <denkenz> anyway, the question is how to fix this madness in a good way
Dec 16 22:31:37 <denkenz> since its too late to hit the guys who slept CS 101 and wrote the test spec with a clue by four
Dec 16 22:36:28 <denkenz> so here's what I propose
Dec 16 22:36:39 <denkenz> parse_dataobj_text should treat len == 0 as NULL
Dec 16 22:36:42 <denkenz> len == 1 as empty
Dec 16 22:38:12 <denkenz> for display_text, get_input and get_inkey we 'fixup' the null case and turn it into the empty case
Dec 16 22:38:35 <denkenz> for idle_mode_text we check for null and icon being present and fail that one
Dec 16 22:38:50 <denkenz> For cases where text is optional, we add a has_text parameter
Dec 16 22:39:16 <denkenz> And then someone has the homework assignment of checking whether the test spec screws with 'default text' in the same manner
Dec 16 22:43:16 <Jeevaka> hmm, isnt the patch takes care of this cases in a different way. may i know what is the benefit if we do it this way?
Dec 16 22:45:26 <balrog-k1n> yeah, parse_dataobj_text needs to differentiate between empty and NULL but in the parse_display_text and parse_setup_idle_mode_text we can handle all the error cases so stk.c doesn't have to check
Dec 16 22:45:42 <denkenz> yes, what andrew just said
Dec 16 22:46:15 <Jeevaka> ok
Dec 16 22:48:08 <balrog-k1n> len == 1 doesn't need to be special-cased as far as i can see, only the handling of NULL is different in each command and depends on whether we have a self-explanatory icon too
Dec 16 22:50:14 <denkenz> the reason I want that special cased is to be able to re-encode the decoded pdu 1:1 to the original
Dec 16 22:50:29 <denkenz> Hence we must make a distinction between len == 0, len == 1 and object not being present
Dec 16 22:51:30 <denkenz> while the 'fixing' up stage in stkutil will undo this goal
Dec 16 22:51:42 <denkenz> It is easy to remove if the original parser is sane
Dec 16 22:52:58 <denkenz> but either way, doing this in stkutil is preferred
Dec 16 22:53:07 <Jeevaka> where are we going to add the has_text?
Dec 16 22:54:32 <denkenz> to the weird class c ones
Dec 16 22:55:19 <denkenz> e.g. launch browser and open channel
Dec 16 22:55:26 <denkenz> or class c & e rather
Dec 16 22:56:55 <Jeevaka> ok I'll do it tomorrow already very late
Dec 16 22:59:30 <denkenz> nod
**** ENDING LOGGING AT Fri Dec 17 02:59:59 2010