**** BEGIN LOGGING AT Thu Mar 03 02:59:58 2011
Mar 03 03:16:26 <denkenz> zgli: define 'default'? The plugin is built only with maintainer mode enabled
Mar 03 03:20:37 <zgli> for the default: just mean, I would see the NITZ value with maintainer modem enable by ofonod log on ifx mode, nothing else. because I want to test something about it
Mar 03 03:20:54 <zgli> type: ifx modem
Mar 03 03:42:27 <denkenz> shrug, if maintainer mode is on then the plugin will tell you the NITZ value if the network reports it and the modem reports it
Mar 03 04:13:00 <demarchi> denkenz: what would be the proper way to differentiate the mbm modems?
Mar 03 04:13:21 <demarchi> different udev rules?
Mar 03 04:15:32 <denkenz> demarchi: Don't know really, holtmann might have some ideas
Mar 03 04:16:10 <denkenz> At least so far his initial idea looked to be the same as mine (have a peek at huawei ndis rules)
Mar 03 04:17:00 <holtmann> demarchi: We already check for the Dell version of the MBM modem. You can use similar check to blacklist the MD-300.
Mar 03 04:17:03 <denkenz> Maybe you can still set the GPS device after the modem has been registered
Mar 03 04:17:24 <holtmann> Also checking if the GPS AT command is supported before registering the atom would help.
Mar 03 04:17:45 <denkenz> Doesn't help him, since he needs the tty first
Mar 03 04:18:06 <holtmann> He does not. The GPS ctl command should be issued on a different TTY.
Mar 03 04:18:30 <denkenz> Sure, but my MD300 only has 2 TTYs
Mar 03 04:18:32 <denkenz> Not 3
Mar 03 04:18:55 <holtmann> That is fine. You can just detect the modem without TTY port set.
Mar 03 04:19:18 <denkenz> not in the current setup
Mar 03 04:19:33 <holtmann> The GPS TTY will be found and added later one before the atom is initizilized.
Mar 03 04:19:52 <holtmann> Seriously you can run the GPS enable/disable command on any TTY.
Mar 03 04:20:24 <denkenz> Yes, but he physically needs to know whether he has 2 ttys, 3 ttys and their devnodes
Mar 03 04:20:28 <holtmann> Just the TTY data enable command needs to be on the TTY that will become the NMEA device.
Mar 03 04:20:31 <denkenz> The current setup does not allow this
Mar 03 04:20:55 <holtmann> As I said, that is fine. The atom can check if the TTY for GPS is set or not.
Mar 03 04:21:40 <denkenz> Nope, re-read the code
Mar 03 04:21:51 <denkenz> As I said, maybe removing the Registered check in add_mbm will do the trick
Mar 03 04:22:03 <denkenz> Barring that, let holtmann fix it as he seems to know how ;)
Mar 03 04:22:11 <demarchi> holtmann: once it is registered, the function add_mbm() just returns
Mar 03 04:22:20 <demarchi> denkenz: yeah...
Mar 03 04:22:27 <demarchi> denkenz: i think this is the way to go
Mar 03 04:22:51 <holtmann> Revert the change for "Registered" variable.
Mar 03 04:23:03 <holtmann> Make it register as soon as it finds two TTY ports.
Mar 03 04:23:16 <holtmann> And let udev continue to find the third one if present.
Mar 03 04:23:24 <demarchi> yeah...
Mar 03 04:23:26 <holtmann> However the core can go ahead and use the modem.
Mar 03 04:23:40 <holtmann> Once you start location reporting atom. The third port will be found. If available.
Mar 03 04:23:46 <holtmann> If not, then just fail the enabling.
Mar 03 04:24:02 <holtmann> Also the GPS control command with =? should return an error.
Mar 03 04:25:04 <demarchi> denkenz: do i make this change or you'll take care of it
Mar 03 04:25:04 <demarchi> ?
Mar 03 04:25:08 <denkenz> anyhow, we should avoid calling ofono_modem_register the second time
Mar 03 04:25:23 <denkenz> Which is the flip side bug that add_huawei is doing now
Mar 03 04:26:38 <demarchi> denkenz: yes... we still check by the Registered property
Mar 03 04:26:59 <demarchi> but instead of returning, just skip more calls to ofono_modem_register
Mar 03 04:28:51 <demarchi> i think something like this should do it: 
Mar 03 04:28:53 <demarchi> http://codepad.org/LOsq6YL6
Mar 03 04:38:01 <denkenz> I'm pretty sure we need the network for mbm
Mar 03 04:41:56 <holtmann> Even with the network interface this is fine as well. The atom will take care of that by itself.
Mar 03 04:42:09 <holtmann> There is also the problem of the TTY for PPP.
Mar 03 04:43:45 <demarchi> it's working for me like this....
Mar 03 04:44:07 <denkenz> Not really, it'll just give a NULL to the core
Mar 03 04:44:19 <demarchi> well... gotta go
Mar 03 04:45:41 <denkenz> The modem driver is not smart enough to only enable the ppp context if the NetworkInterface is null
Mar 03 04:51:59 <denkenz> anyway, I pushed a fix for just the gps
Mar 03 04:52:03 <denkenz> Have a look at it
Mar 03 07:42:59 <chxie> Any idea when I call cmtspeech_open() I get error: unable to open device /dev/cmt_speech ('Device or resource busy') ?
Mar 03 07:43:27 <chxie> I have called cmtspeech_init() before that succesfully.
Mar 03 11:06:13 <demarchi> denkenz:  it seems good
Mar 03 19:12:38 <denkenz> demarchi: Yikes, why do we go so complicated on the mbm patch
Mar 03 19:12:53 <denkenz> I'd say just open the damn thing blocking, write the command and be done with it
Mar 03 19:13:49 <denkenz> Given that you just opened the serial port, there is no way to get an EAGAIN anyway
Mar 03 19:23:18 <demarchi> denkenz: you said to use non-blocking
Mar 03 19:23:32 <demarchi> humn... here it is:
Mar 03 19:23:33 <demarchi> 14:10    denkenz> demarchi: Sounds like you need to just write the command to the  channel
Mar 03 19:23:36 <demarchi> 14:10    denkenz> Make sure the channel is non-block
Mar 03 19:24:14 <denkenz> wonder why I said that
Mar 03 19:24:20 <denkenz> Either way, ignore me ;)
Mar 03 19:24:25 <demarchi> ehhehe
Mar 03 19:25:27 <denkenz> Lets keep it simple for now, open the channel, write to it and be done with it
Mar 03 19:25:42 <demarchi> denkenz: yup... it's easier this way
Mar 03 19:25:45 <denkenz> If we ever notice timing issues we can fix it
Mar 03 19:26:02 <denkenz> But considering that a serial tty open is blocking and takes forever anyway, this shouldn't be a big deal
Mar 03 19:26:31 <demarchi> denkenz: ok
**** ENDING LOGGING AT Fri Mar 04 02:59:59 2011