**** BEGIN LOGGING AT Fri Feb 26 02:59:57 2010
Feb 26 03:13:28 <denkenz> zhenhua: Because snprintf returns the number that _would_ be written, not actually written
Feb 26 03:13:34 <denkenz> so the return value can be bigger than buffer size
Feb 26 03:16:29 <zhenhua> On success, returns the number of characters that would have been written had size been sufficiently large, not counting the terminating nul character.
Feb 26 03:16:54 <denkenz> Yes, so if you use len = snprintf you can't just use len directly
Feb 26 03:17:14 <denkenz> Since you might have had an overflow
Feb 26 03:17:28 <zhenhua> let me think a little.
Feb 26 03:17:34 <zhenhua> my CPU is slow
Feb 26 03:18:56 <denkenz> zhenhua: The #define changes sound fine
Feb 26 03:22:26 <zhenhua> denkenz: i still don't under why need sizeof(buf)-1 instead of sizeof(buf).
Feb 26 03:22:40 <zhenhua> the return val of snprintf doesn't count \0
Feb 26 03:23:24 <zhenhua> i have almost updated my patch and will send u soon.
Feb 26 03:24:46 <zhenhua> s/under/understand
Feb 26 03:30:11 <zhenhua> for g_at_server_send_result, the buf is 1024 bytes which is enough big i think.
Feb 26 03:30:47 <zhenhua> why we need MIN(len, sizeof(buf)-1)? i see many other code also use snprintf as well.
Feb 26 03:31:14 * zhenhua go for launch
Feb 26 05:40:51 <zhenhua> denkenz: i wrote a small overflow case and got u now.:-). however, i am not convinced it would happen in g_at_server_send_result
Feb 26 06:55:33 <denkenz> maybe, but since you're using snprintf, then be paranoid
Feb 26 07:00:57 <zhenhua> denkenz: do we still need seperate patch for #define BUF_SIZE 4096?
Feb 26 07:03:26 <zhenhua> the patch is only move 4096 to #define BUF_SIZE 4096
Feb 26 07:08:15 <zhenhua> denkenz: see driver/atmodem/call-barring.c at_call_barring_set(). look like it's possible to overflow.
Feb 26 16:32:55 <sabotage> denkenz: finally got a test platform running with that SIM card and the Option GTM378 modem...
Feb 26 16:33:39 <sabotage> but it shows up as "/Serial_Number" and only has org.ofono.SimManager exposed as a service
Feb 26 16:34:36 <sabotage> so this is a FAIL for me... though prolly still user error
Feb 26 16:35:10 <sabotage> I suspect I may need something sane in modem.conf at least (which I have not touched), but not sure what
Feb 26 16:35:15 <sabotage> any suggestions?
Feb 26 16:40:16 <denkenz> sabotage: Hold on, only SimManager?
Feb 26 16:40:29 <denkenz> sabotage: Are you sure you don't have a sim lock turned on?
Feb 26 16:42:17 <denkenz> sabotage: And feel free to pastebin the AT trace when you power the modem on
Feb 26 16:58:46 <sabotage> sorry, was AFK...
Feb 26 16:59:06 <sabotage> lemme re-run ofonod with debug on and paste it
Feb 26 16:59:30 <sabotage> and I think you answered my other Q... I need to enable generic at in modem.conf, yes?
Feb 26 16:59:57 <denkenz> if it shows up as /serial number it is recognized by udev
Feb 26 17:00:07 <denkenz> I don't think you need to mess with modem.conf at all
Feb 26 17:01:26 <sabotage> hmm -d option has changed since I las used it
Feb 26 17:01:50 <sabotage> what are the options to -d?
Feb 26 17:04:09 <sabotage> denkenz: this is all I get...
Feb 26 17:04:10 <sabotage> Unable to read IMSI, emergency calls only
Feb 26 17:04:23 <sabotage> with -d 1
Feb 26 17:05:36 <sabotage> ok, well be that way ;)
Feb 26 17:06:14 <sabotage> ok, so -d 1 is not apparently how to enable debugging
Feb 26 17:07:17 <denkenz> it changed, ofonod -n -d '*'
Feb 26 17:07:30 <sabotage> I see an example in HACKING for 'plugins/*'
Feb 26 17:07:31 <denkenz> You can debug by file now ;)
Feb 26 17:07:33 <sabotage> oh, ok
Feb 26 17:07:38 <sabotage> will try that
Feb 26 17:07:42 <sabotage> nice
Feb 26 17:11:54 <sabotage> denkenz: http://pastebin.ca/1812042
Feb 26 17:13:11 <denkenz> Interesting, now export OFONO_AT_DEBUG=1 and rerun with ofonod -n
Feb 26 17:14:11 <sabotage> I get no debug other than version and emergency calls only messages
Feb 26 17:17:43 <sabotage> denkenz: ^^^
Feb 26 17:18:36 <sabotage> and BTW, I wouldn't know if I have a sim lock turned on or not, since I don't know what it is ;)
Feb 26 17:19:41 <denkenz> No, you should be getting an at command trace
Feb 26 17:19:56 <denkenz> export OFONO_AT_DEBUG=1; ofonod -n; enable_modem doesn't do it?
Feb 26 17:21:36 <sabotage> nope
Feb 26 17:22:24 <denkenz> wtf
Feb 26 17:23:29 <sabotage> when I run with -nd '*' again, and then run enable-modem, I get an error about it being in progress already
Feb 26 17:23:33 <sabotage> dbus.exceptions.DBusException: org.ofono.Error.InProgress: Operation already in progress
Feb 26 17:23:57 <sabotage> and I had already noticed that the modem was coming up enabled by default
Feb 26 17:24:02 <sabotage> which I thought seemed odd
Feb 26 17:24:08 <sabotage> or at least different
Feb 26 17:24:32 <denkenz> ok kill ofono and redo it
Feb 26 17:27:18 <sabotage> same 
Feb 26 17:28:38 <denkenz> ok, can you tell what tty the GTM is sitting on?
Feb 26 17:28:49 <sabotage> yeah
Feb 26 17:28:52 <sabotage> ttyS0
Feb 26 17:28:52 <denkenz> if so, can you open it up with minicom?
Feb 26 17:29:07 <sabotage> yeesh... been forever since I used that :P
Feb 26 17:29:21 <sabotage> gimme some time to re-learn the basics
Feb 26 17:29:48 <denkenz> minicom -s and follow the menus
Feb 26 17:30:38 <sabotage> installing ...
Feb 26 17:31:01 <sabotage> FWIW, I can see serial#, manufacturer, vendor, etc... info
Feb 26 17:31:17 <sabotage> via d-feet or dbus-send
Feb 26 17:31:49 <denkenz> Yeah, so you're definitely seeing some AT commands flying
Feb 26 17:31:59 <denkenz> Hence my wtf at OFONO_AT_DEBUG not giving anything
Feb 26 17:33:05 <denkenz> you did restart ofono after exporting right?
Feb 26 17:33:50 <sabotage> yes, several times...
Feb 26 17:34:03 <sabotage> oh! *sugar*!!!!
Feb 26 17:34:05 <sabotage> UE
Feb 26 17:34:22 <sabotage> I'm running sudo... which does not copy env 
Feb 26 17:34:25 <sabotage> fudge!
Feb 26 17:34:32 <sabotage> ok, one sec... ;)
Feb 26 17:39:06 <sabotage> ok denkenz, fixed user error, now seeing interesting output ;)
Feb 26 17:39:09 <sabotage> http://pastebin.ca/1812082
Feb 26 17:43:10 <denkenz> ok, your GTM is weird, it is responding with error to CIMI
Feb 26 17:44:05 <denkenz> Can you try manually in minicom? maybe it is simply a timing issue with the SIM not being ready
Feb 26 17:44:30 <denkenz> try AT+CFUN=0, wait 5 secs, AT+CIMI
Feb 26 17:44:37 <denkenz> also try AT+CIMI? and AT+CIMI=?
Feb 26 17:48:09 <sabotage> back from afk... 
Feb 26 18:01:48 <sabotage> denkenz: I may just be minicom handicapped, but I can't get the modem into a state were I can enter commands at all
Feb 26 18:02:14 <sabotage> likely I need to modify the init string I guess, but no idea what it should be
Feb 26 18:02:18 <denkenz> Are you sure you're opening the right port?
Feb 26 18:02:34 <sabotage> far as I know
Feb 26 18:03:40 <sabotage> double checking
Feb 26 18:03:48 <denkenz> So there are 2 ports according to ofono log
Feb 26 18:04:01 <denkenz> It seems to follow the standard HSO breakdown
Feb 26 18:04:41 <denkenz> Which would mean the ttys are most likely /dev/ttyHS0-4
Feb 26 18:07:00 <sabotage> hmm, ok, somehow I got the idea it was on ttyS0...
Feb 26 18:07:02 <sabotage> fixing
Feb 26 18:08:27 <sabotage> ugh!, X hung... need to restart
Feb 26 18:08:42 <denkenz> lol
Feb 26 18:09:05 <denkenz> I suspect it is something simple, like the GTM firmware needing AT+CIMI? instead of AT+CIMI
Feb 26 18:09:17 <denkenz> Or maybe it needs to fire off some notification that SIM is ready
Feb 26 19:43:14 <sabotage> denkenz: on an unrelated topic... where does the responsibility lay in app,ofono,modem scope for connecting voice call audio stream into OS audio system?
Feb 26 19:44:09 <sabotage> IOW, when a call is connected, who owns hooking up the modem audio to the audio stream engine (aka PulseAudio in the Moblin case)?
Feb 26 19:50:55 <denkenz> the Dialer
Feb 26 19:51:10 <sabotage> o_O
Feb 26 19:51:12 <denkenz> sabotage: oFono has no clue whether you want it on the headset / bluetooth, etc
Feb 26 19:51:14 <sabotage> how?
Feb 26 19:51:21 <sabotage> where do I get the stream from
Feb 26 19:51:35 <denkenz> sabotage: In Moblin all of this is taken care (supposedly) by AudioManager / PulseAudio
Feb 26 19:51:52 <sabotage> ok, now we get to the meat of the problem ;)
Feb 26 19:51:56 <sabotage> and my real question
Feb 26 19:52:32 <sabotage> according to the AM docs, the modem driver mus first register with AM, set it's dbus callback methods and perform the PA streem connection
Feb 26 19:52:47 <sabotage> all the app does is inform which dest to send it to
Feb 26 19:52:55 <denkenz> Yeah the AM guys are smoking stuff
Feb 26 19:53:00 <sabotage> set/get gain and mute
Feb 26 19:54:24 <denkenz> In the end it is pulse or the app itself that is responsible
Feb 26 19:54:28 <sabotage> so aside from any dope I may or may not be smoking... if I *were* to hook up the streams, how?
Feb 26 19:54:46 <denkenz> Depends on the situation
Feb 26 19:54:53 <sabotage> I see no APIs that expose a way for me to do this
Feb 26 19:54:58 <denkenz> e.g. in oFono HFP client case it is BlueZ / Pulse
Feb 26 19:55:19 <sabotage> ok, but not my most pressing or relevant case ;)
Feb 26 19:55:27 <denkenz> Basically it depends entirely on the hardware setup
Feb 26 19:55:42 <sabotage> I need incoming/outgoing call via current active modem
Feb 26 19:56:36 <denkenz> Again, AudioManager is supposed to take care of this
Feb 26 19:56:50 <denkenz> The problem is they got tainted by the stupidity of the *other* stack
Feb 26 19:57:03 * sabotage fears there is a *huge* disconnect between those pushing/coding/requiring the use of AM and the Ofono modem driver developers and or ofono architecture :(
Feb 26 19:57:22 <denkenz> Not really, the AM guys just have no idea what they're doing :)
Feb 26 19:57:38 <sabotage> AM "does" this, but only in direct coordination with modem driver
Feb 26 19:57:44 <denkenz> I looked at their code and shuddered
Feb 26 19:57:51 <sabotage> fair enough
Feb 26 19:58:10 <denkenz> Seriously, the flow is:
Feb 26 19:58:11 * sabotage sends denkenz the SAS which defines what they are supposed to be coding to
Feb 26 19:58:52 <denkenz> Dialer tells AM to activate modem path -> AM tells platform driver to activate modem path -> platform driver may or may not call into oFono driver to activate audio path
Feb 26 19:59:12 <denkenz> In the case of Intel hardware its all completely external to oFono
Feb 26 20:02:20 <sabotage> denkenz: missing from your flow is the initial "am_register_modem_control_cb()" call from ofono (or modem driver I suppose) to AM that tells AM how to signal modem to control it's stream ...
Feb 26 20:02:34 <sabotage> again, according to the doc I just sent ;)
Feb 26 20:03:36 <sabotage> the rest I all agree with, sorta, if by "path" you mean output destingation device (earpiece speaker, internal speaker, BT headset, wired headset)
Feb 26 20:03:59 <denkenz> there's no point to have AM listen to *two* entities
Feb 26 20:05:49 <sabotage> am does not listen to ofono in this case... only informed of "who/how" to call when app wants to change output path or props (mute/gain)
Feb 26 20:06:24 <sabotage> but that first step must happen, according to their script 
Feb 26 20:07:24 <sabotage> and anyway, isn't that the point of AM, to listen to "n" entities, and based on rules, adjust output mixing/volume/mute/pause/resume...
Feb 26 20:09:50 <sabotage> BTW, I'm not trying to argue the merits or sanity of this... but rather trying to understand, *if* AM were not in the picture, how exactly is a dialer supposed to hook up the modem stream to *any* output?  
Feb 26 20:10:09 <sabotage> IOW where are the docs on the APIs for this, even if it is per device dependant?
Feb 26 20:10:12 <denkenz> The biggest problem is that the audio can be integrated in one of bazilion ways
Feb 26 20:10:24 <denkenz> All of the *completely* hardware dependent
Feb 26 20:10:40 <sabotage> I (blindly) assumed the whole point of Ofono was to "wrap" that so I don't need per device details
Feb 26 20:11:04 <sabotage> so has anyone done this yet with ofono?
Feb 26 20:11:05 <denkenz> This is not oFono's job, it is PA's job
Feb 26 20:11:26 <sabotage> how is PA made aware of the stream?
Feb 26 20:11:48 <denkenz> one way is for the dialer to simply tell PA about it
Feb 26 20:11:54 <sabotage> to be fair, I know zero PA yet...
Feb 26 20:12:00 <sabotage> tell it what?
Feb 26 20:12:10 <denkenz> That a voice call is 'active'
Feb 26 20:12:31 <denkenz> and to use whatever the device is for voice stream
Feb 26 20:12:39 <sabotage> don't I need to point PA to a stream or FD or ???
Feb 26 20:12:47 <denkenz> Depends on hardware
Feb 26 20:12:58 <denkenz> on some hardware you have a single sound card, with no mixing
Feb 26 20:13:02 <sabotage> ok, now we're getting someplace... how do I find the voice stream?
Feb 26 20:13:08 <denkenz> The sound card has hard-wired paths for audio
Feb 26 20:13:19 <denkenz> so mic -> modem, modem -> speaker
Feb 26 20:13:25 <denkenz> headset -> modem, modem -> speaker
Feb 26 20:13:32 <denkenz> cpu -> speaker, mic -> cpu, etc
Feb 26 20:13:56 <sabotage> ok, this is clearly not helping me... I need to read up on PA  more I guess
Feb 26 20:13:59 <denkenz> On other hardware the modem exposes some stream device with audio data
Feb 26 20:14:49 <sabotage> where I'm lost is how does the modem route audio to any device, does it grock PA or is it lower level?
Feb 26 20:15:20 <denkenz> Two ways:
Feb 26 20:15:33 <denkenz> modem PCM in/out is hardwired to Sound card PCM in/out
Feb 26 20:15:45 <denkenz> Modem exposes a character device with audio packets
Feb 26 20:15:49 <sabotage> lemme ask another Q then... does ModemManager offer some properties that I can query to find out what it's capable or, or how it handles audio?
Feb 26 20:16:00 <denkenz> ModemManager?
Feb 26 20:16:14 <sabotage> org.ofono.modem, sorry
Feb 26 20:16:29 <denkenz> No, oFono has zero clue about audio, it is for a reason
Feb 26 20:16:45 <denkenz> AM/PA is responsible there
Feb 26 20:18:06 <sabotage> so despite all the benifits of encasulating the modem implimentation specifics from apps that Ofono is supposed to provide, it doesn't do this for audio, so I still need per-device handler code in my app anyway?
Feb 26 20:18:22 <denkenz> I don't see how you draw this conclusion
Feb 26 20:18:34 <denkenz> What oFono does for Modems, AudioManager is supposed to do for audio platforms
Feb 26 20:19:10 <sabotage> well you're telling me I need to know what the modem is, to know how/where it routes audio, so I can tell PA to make it active or not, and tell AM what output path I want it on...
Feb 26 20:19:21 <denkenz> No, *you* don't
Feb 26 20:19:40 <denkenz> The AM api should be something like -> RequestPath("VoiceCall", "BT")
Feb 26 20:19:40 <sabotage> well according to the spec, it does, but only if the modem driver "cooperates"
Feb 26 20:19:50 <sabotage> FAIL
Feb 26 20:19:56 <sabotage> this is the disconnect then
Feb 26 20:19:59 <denkenz> and there they've no clue 
Feb 26 20:20:35 * sabotage punts for the weekend and goes home like he was supposed to an hour ago
Feb 26 20:20:55 <denkenz> Trust me, there's nothing oFono can do for the audio part
Feb 26 20:21:11 <denkenz> I've been down that road before and I've paid my debt to society
Feb 26 20:21:17 <sabotage> BTW, not trying to be difficult, justtrying to connect the dots and finding they can't/don't :P
Feb 26 20:21:41 <denkenz> They do, just that no one with clue has really been overseeing the AM development
Feb 26 20:22:24 <denkenz> The fundamental concept is fine, but their thinking is flawed
Feb 26 20:22:26 <sabotage> I suspect I'll be spending the weekend crafting an email point this very fact out to get the ball rolling :(
Feb 26 22:57:38 <tmzt> AM api, awesome
**** ENDING LOGGING AT Sat Feb 27 02:59:56 2010