**** BEGIN LOGGING AT Tue Feb 09 02:59:56 2010
Feb 09 15:42:06 <holtmann> denkenz: ping
Feb 09 15:42:24 <denkenz> holtmann: pong
Feb 09 15:42:27 <holtmann> My MBM 37xx card in my X200 keeps crashing now when doing GPRS.
Feb 09 15:42:40 <holtmann> Worked fine once, then I ran Carrick and its 3G setup and it crashes.
Feb 09 15:42:54 <denkenz> crashes at what point?
Feb 09 15:42:55 <holtmann> I assume the problem is the username/password setup.
Feb 09 15:43:19 <holtmann> I don't have traces yet. Was in a meeting and couldn't get it to work.
Feb 09 15:43:29 <denkenz> hmm, my MD300 worked just fine
Feb 09 15:43:38 <denkenz> I made sure to test it before pushing
Feb 09 15:43:40 <holtmann> Maybe the empty "" username/password is an issue.
Feb 09 15:43:57 <holtmann> I created the APN config via ConnMan :(
Feb 09 15:44:24 <denkenz> shouldn't be
Feb 09 15:44:33 <holtmann> It is like the firmware crashes we have seen before.
Feb 09 15:44:45 <holtmann> Suddenly the device disappears from the bus.
Feb 09 15:45:33 <denkenz> Try AT trace, maybe it is the ENAP that crashes it
Feb 09 15:45:46 <denkenz> That's what crashed these cards before...
Feb 09 15:48:46 <holtmann> It crashes at ENAP for sure. However something else must trigger it since that card worked before.
Feb 09 15:49:27 <denkenz> I've had that before too, where the card worked then crashed
Feb 09 18:16:53 <denkenz> padovan: The patch looks good for the most part, but you still forgot one thing
Feb 09 18:17:09 <padovan> denkenz: what?
Feb 09 18:17:39 <denkenz> padovan: If connect fails, you need to call ofono_modem_set_powered
Feb 09 18:17:59 <denkenz> and you need to call disconnect only if the error was a timeout error
Feb 09 18:19:09 <padovan> Ok. I'll fix that.
Feb 09 18:33:00 <tmzt> can multiple devices use the modem? is there a locking mechanism in place?
Feb 09 18:33:21 <denkenz> yes, it is called ofonod
Feb 09 18:36:19 <tmzt> hmm, but ref counting or similar for powered status?
Feb 09 18:36:37 <tmzt> also, this hfp could be used to support a usb dun co9nnection as well right?
Feb 09 18:36:47 <denkenz> no, hfp is hfp
Feb 09 18:36:50 <tmzt> like a serial client port
Feb 09 18:37:01 <tmzt> the infrastructure in place
Feb 09 18:37:09 <tmzt> not hfp itself
Feb 09 18:37:21 <denkenz> nope
Feb 09 18:37:55 <denkenz> You're confused about what hfp in ofono does
Feb 09 18:39:11 <akiniemi> denkenz: ping
Feb 09 18:39:20 <denkenz> akiniemi: pong
Feb 09 18:39:45 <akiniemi> do you mind if I take the registration status op away from gprs.h?
Feb 09 18:39:54 <tmzt> yeah I'm confused, hfp is not a server that supports AT commands over rfcomm?
Feb 09 18:40:29 <denkenz> akiniemi: Removing all registration status stuff from gprs is on my todo
Feb 09 18:40:37 <akiniemi> I mean, that data should come from the netreg atom
Feb 09 18:40:41 <denkenz> akiniemi: However, I need to still clarify how GPRS Class A/B works..
Feb 09 18:41:15 <denkenz> akiniemi: I do agree in ideal world it comes from netreg atom, but AT modems are fucking weird
Feb 09 18:41:24 <akiniemi> denkenz: ok, then I'll leave it there, but won't implement it for isimodem
Feb 09 18:42:12 <denkenz> akiniemi: Nod, leave it for now, I think it is unused except for display
Feb 09 18:42:30 <denkenz> akiniemi: If you have problems we can remove it easy
Feb 09 18:42:57 <denkenz> tmzt: HFP has two roles, Server and Client
Feb 09 18:43:05 <denkenz> tmzt: oFono can be used to implement both
Feb 09 18:43:23 <denkenz> tmzt: The plugin in oFono today implements the client role (e.g. Headset)
Feb 09 18:43:34 <akiniemi> denkenz: ok
Feb 09 18:43:49 <tmzt> ah
Feb 09 18:44:09 <akiniemi> denkenz: oh, btw do you have plans for supporting user action USSDs?
Feb 09 18:44:26 <denkenz> AFAIK we already do
Feb 09 18:44:29 <denkenz> look in ussd.c
Feb 09 18:45:06 <denkenz> balrog-kun is working on network initiated ussds
Feb 09 18:45:15 <akiniemi> denkenz: hmm, so what is USSD_STATUS_ACTION_REQUIRED, then?
Feb 09 18:46:07 <akiniemi> denkenz: also, can enum ussd_status go to the header file, please? ;)
Feb 09 18:46:08 <denkenz> That one is when the network requests something from the user
Feb 09 18:46:37 <akiniemi>  denkenz: right, like if you get a menu to choose from, that's what I meant.
Feb 09 18:46:38 <denkenz> Ok, the policy is: int when the enum is defined in 27.007
Feb 09 18:46:52 <denkenz> enum when no definition exists and we invent one
Feb 09 18:47:06 <denkenz> maybe we need to change that, but it worked well so far
Feb 09 18:47:21 <akiniemi> denkenz: I know, I know, but it's f'ng annoying to convert ISI values to plain ints... ;)
Feb 09 18:47:37 <akiniemi> denkenz: I get this uneasy feeling they will change :)
Feb 09 18:47:38 <denkenz> I'm fine putting it into the header
Feb 09 18:48:15 <akiniemi> denkenz: cool
Feb 09 18:48:37 <denkenz> AFAIK the action required is signaled on the ussd interface
Feb 09 18:48:50 <denkenz> and you need to reply to it, but not sure if it is 100% supported
Feb 09 18:49:25 <denkenz> I've never seen it on a real network, so not sure how to test it even
Feb 09 18:49:32 <akiniemi> denkenz: I don't think it is, and the machinery I'm testing against is sending only such responses
Feb 09 18:50:10 <denkenz> Then sounds like you're the best candidate to provide a patch :)
Feb 09 18:50:38 <akiniemi> denkenz: heh, appending to my todo list, then :)
Feb 09 18:56:52 <denkenz> akiniemi: We do have to be careful about removing gprs network registration stuff as we rely on knowing when we're actually attached
Feb 09 18:59:46 <akiniemi> denkenz: ISI modems provide a query/indication for attach status. So an attach_status op would be fine by me...
Feb 09 19:00:54 <denkenz> akiniemi: Ok, propose something, I suppose we can modify ofono_gprs_status_notify and ofono_gprs_detached_notify into ofono_gprs_attached_notify
Feb 09 19:00:58 <denkenz> with a boolean parameter
Feb 09 20:39:24 <denkenz> akiniemi: I'm fine with that patch
Feb 09 20:42:02 <akiniemi> denkenz: ok, I'll push in a bit
Feb 09 20:43:02 <denkenz> akiniemi: The current API doesn't consider user actions, so we need to do some API design as well
Feb 09 20:44:56 <tmzt> this looks very gsm specific, cdma has a single fake context
Feb 09 21:01:33 <akiniemi> denkenz: I reckon you're right. I don't have a clear idea how, though.
Feb 09 21:01:56 <akiniemi> denkenz: you want me to hold off the patch until  we sort the API out?
Feb 09 21:02:14 <denkenz> akiniemi: Nah, that atom needs serious love
Feb 09 21:02:25 <denkenz> akiniemi: Submit it anyway
Feb 09 21:02:49 <akiniemi> denkenz: at least with that patch I can get the isimodem driver working _pretty_ well
Feb 09 21:03:49 <denkenz> akiniemi: Biggest issue is that my network only supports simple user-initiated -> network final response ussds
Feb 09 21:04:01 <denkenz> akiniemi: And my prepaid SIM does support network initiated final ones
Feb 09 21:04:17 <denkenz> akiniemi: Never seen the user-action ones
Feb 09 21:04:43 <akiniemi> denkenz: yeah, I suppose those are quite rare. Our test network does them, though. ;)
Feb 09 21:04:46 <denkenz> akiniemi: So we have to figure out some nice API, maybe a State property, maybe an extra return argument for Initiate
Feb 09 21:05:58 <akiniemi> denkenz: I see what you mean.
Feb 09 23:19:12 <emdete> is it true that gprs is not supported on a freerunner with ofono?
Feb 09 23:19:53 <denkenz> freerunner uses ppp for gprs, we do not support ppp yet
Feb 09 23:20:52 <emdete> does ofono parse the sms-pdu received for a sms?
Feb 09 23:21:10 <emdete> oups... ...for a mms
Feb 09 23:22:05 <denkenz> mms is an entirely different animal, ofono will not support mms
Feb 09 23:22:10 <denkenz> That is a job of an external stack
Feb 09 23:23:06 <emdete> i didn't mean mms. i mean the first step. the sms received as a trigger to retrieve the mms
Feb 09 23:23:27 <denkenz> We recognize wap pushes and simply toss them today
Feb 09 23:25:20 <emdete> so parsing is a layer above ofono?
Feb 09 23:26:14 <denkenz> mms? Yeah
Feb 09 23:26:30 <emdete> mms is alot of steps, so be more concrete ;)
Feb 09 23:27:03 <emdete> and while you can't even activate a pdp context you're lost anyway
Feb 09 23:27:13 <emdete> (for the freerunner...)
Feb 09 23:27:14 <denkenz> Shrug, you get a wap push notification that tells you some crap
Feb 09 23:27:25 <denkenz> Then you activate an mms context
Feb 09 23:27:29 <emdete> exactly - first step
Feb 09 23:27:45 <denkenz> Again, we recognize the wap push and completely ignore it
Feb 09 23:27:50 <denkenz> We don't parse it or anything else
Feb 09 23:27:54 <emdete> pdp-context. often with a special apn. yes
Feb 09 23:29:45 <emdete> hm, i understood "simply toss them" as if you fire a signal that you received it and a higher level program can use it. "completely ignore" sounds as if it gets lost... 
Feb 09 23:30:56 <denkenz> it does, and ofono does not advertise mms support
Feb 09 23:31:04 <denkenz> If you want this, submit a patch, that's how it works
Feb 09 23:31:52 <emdete> problem is: i don't find information about how to decode that sms. i thought maybe ofono contains functionality for that
Feb 09 23:32:29 <denkenz> 3GPP 23.040
Feb 09 23:32:33 <denkenz> That's where I found it ;)
Feb 09 23:38:01 <emdete> do you have code for it already?
Feb 09 23:38:46 <denkenz> All the code I have is upstream
Feb 09 23:39:55 <denkenz> The WCMP id is described in 23.040, what is inside I simply don't care about today
Feb 09 23:40:28 <emdete> okay...
Feb 10 00:53:51 <zhenhua> denkenz: i have local implementation to use a list of free ring buffer to cache the data that written to client side. what do u think?
Feb 10 00:54:53 <denkenz> that could work
Feb 10 00:57:12 <denkenz> emdete: You might want to look into qt-exteded/qtopia
Feb 10 00:57:19 <denkenz> emdete: That one has a primitive mms stack
Feb 10 00:57:49 <denkenz> emdete: src/libraries/qtopiaphone/wap
Feb 10 00:59:08 <emdete> denkenz: good idea. thnx.
Feb 10 01:01:14 <emdete> denkenz: have you any knowledge of the samsung gt i8320? would ofono work with that one?
Feb 10 01:02:43 <denkenz> emdete: None of us have one, so no idea.  If it is at command based then most likely yes
Feb 10 01:04:39 <tmzt> is that usb device or a phone?
Feb 10 01:04:46 <tmzt> what os does it run if a phone
Feb 10 01:05:43 <emdete> denkenz: its probably not. we are working on flashing something more open to it. 
Feb 10 01:06:15 <emdete> denkenz: its quite interesting, i think more&more its the best hw you can get today.
Feb 10 01:07:29 <zhenhua> what modem is gt i8320 using?
Feb 10 01:07:35 <denkenz> if it uses some qualcomm protocol then it might not work
Feb 10 01:07:53 <denkenz> nobody has specs for it
Feb 10 01:08:36 <emdete> zhenhua: i have no idea (now)...
Feb 10 01:09:03 <emdete> there is one wiki starting about it: http://h1.pargon.nl/wiki/index.php?title=Main_Page
Feb 10 01:09:45 <emdete> denkenz: & you may be right with qualcom if this guy is correct
Feb 10 01:11:10 <tmzt> emdete: where are you working?
Feb 10 01:11:31 <emdete> tmzt: germany
Feb 10 01:11:44 <tmzt> on irc anywhere?
Feb 10 01:12:08 <tmzt> my goal is an ipen X based phone on available modern hardware
Feb 10 01:13:03 <emdete> tmzt: don't we all want that?
Feb 10 01:13:33 <denkenz> qualcomm 62xx on the samsung, could very well be proprietary protocol just like on the Pre
Feb 10 01:13:49 <emdete> denkenz: meanin: no chance?
Feb 10 01:13:57 <emdete> tmzt: tell more..
Feb 10 01:14:26 <denkenz> basically no chance :)
Feb 10 01:14:44 <denkenz> some are trying to reverse engineer
Feb 10 01:14:50 <denkenz> but not sure how far they'll get
Feb 10 01:14:56 <zhenhua> how do u know that? cann't find any page mentioned that
Feb 10 01:15:21 <denkenz> http://h1.pargon.nl/wiki/index.php?title=Hardware
Feb 10 01:15:32 <emdete> denkenz: do u have a link/url to that project?
Feb 10 01:16:11 <denkenz> http://www.webos-internals.org/wiki/Portal:Research
Feb 10 01:17:14 <zhenhua> what does the second page for?
Feb 10 01:17:24 <zhenhua> nothing related with 62xx
Feb 10 01:17:42 <zhenhua> hack for pre?
Feb 10 01:17:56 <denkenz> the pre also runs msm 62xx I believe
Feb 10 01:18:50 <zhenhua> we have a local cdma palm pre but not one use it now...
Feb 10 01:34:21 <tmzt> qualcomm could be anything fro AT muxed or not, qmi, to completely custom
Feb 10 01:34:41 <tmzt> more about what?
Feb 10 01:40:40 <emdete> tmzt: your goal. your interpretation of "open"...
Feb 10 01:44:06 <tmzt> a fairly generic linux workstation that happens to be a phone
Feb 10 01:45:12 <tmzt> open can mean everything for license (oss/fsf approved) to customizability to familiarity to desktop users and the ability to install packages without rebuilding a root image
Feb 10 02:40:18 <zhenhua> padovan: ping
Feb 10 02:45:52 <zhenhua> i really don't understand how current hfp.c could work.
Feb 10 02:46:24 <zhenhua> i got seg fault immediately in hfp_register_ofono_handsfree
Feb 10 02:48:52 <padovan> zhenhua: pong
Feb 10 02:49:09 <zhenhua> padovan: so we should not have any thing in modem.conf
Feb 10 02:49:11 <zhenhua> right?
Feb 10 02:49:35 <padovan> zhenhua: yes, we don't need modem.conf anymore
Feb 10 02:50:06 <zhenhua> when i used my original way to have Driver=hfp in modem.conf, i will got crash
Feb 10 02:50:29 <zhenhua> shall we add check in hfp_register_ofono_handsfree().
Feb 10 02:50:39 <zhenhua>       if (!data->handsfree_path)
Feb 10 02:50:39 <zhenhua>                   return -EINVAL;
Feb 10 02:50:44 <zhenhua> here data is 0x0
Feb 10 02:53:56 <padovan> zhenhua: I can't see why we have hfp.c called when we have Driver=hfp in modem.conf
Feb 10 02:54:48 <zhenhua> padovan: i used wrong way to enable hfp drvier when ofono is started.
Feb 10 02:55:29 <zhenhua> padovan: when ofono daemon start up, it will load hfp driver automatically.
**** ENDING LOGGING AT Wed Feb 10 02:59:58 2010