**** BEGIN LOGGING AT Tue Aug 17 02:59:57 2010
Aug 17 10:03:50 <zhenhua1> holtmann: what do you think about btio.[ch] in ofono?
Aug 17 10:04:20 <zhenhua1> holtmann: shall we keep the same version as bluez or cut-down it to keep RFCOMM stuff only?
Aug 17 10:04:22 <holtmann> zhenhua1: So Johan, Denis and I talked about it.
Aug 17 10:04:54 <zhenhua1> yeah, i want to know the conclusion. :-)
Aug 17 10:05:10 <holtmann> We need to create a btio.[ch] version that is free of libbluetooth dependency. And the put it into btio/btio.[ch] into BlueZ, obexd and oFono.
Aug 17 10:05:40 <holtmann> Start by working on the obexd version. That is the smallest code base. And it benefits from not having to link against libbluetooth.
Aug 17 10:07:14 <zhenhua1> so we have to wait until Johan finish that version in obexd, right?
Aug 17 10:09:00 <holtmann> Nope. You need to do that version. Non of the BlueZ devs will touch it ;)
Aug 17 10:10:43 <holtmann> Doing it first in obexd is a bit simpler and than merging it is a bit simpler than merging it from ofono into obexd and bluez.
Aug 17 10:11:04 <zhenhua1> Hmm...could you help to estimate how much efforts it require? you know, i need to tell majid about that.
Aug 17 10:11:25 <zhenhua1> i see
Aug 17 10:11:30 <holtmann> It takes as long as it takes.
Aug 17 10:11:55 <holtmann> Since we are not removing L2CAP or anything, I would assume you should be done in less than a week.
Aug 17 10:12:07 <holtmann> And that is including patch review on the linux-bluetooth mailing list.
Aug 17 10:12:43 <holtmann> The code stays the same. You might need to add btio/bluetooth.h btio/bluetooth.c for the ba2str and the other includes.
Aug 17 10:12:47 <holtmann> However that should be it.
Aug 17 10:13:21 <holtmann> The tricky part comes when we try to do that for bluez.git since that links against libbluetooth.
Aug 17 10:13:42 <holtmann> That is why trying obexd.git first, then bluez.git and if that works out, then we put it into ofono.git.
Aug 17 10:14:34 <zhenhua1> suppose i should make patch for obexd, and the patch also should be sent to linux-bluetooth ML, right?
Aug 17 10:14:53 <holtmann> Make a patch for obexd.git and only send it to linux-bluetooth ML.
Aug 17 10:15:14 <zhenhua1> i have no idea about difference yet, let me do some practise and turn to you later
Aug 17 10:15:23 <holtmann> No need for cross-posting. All maintainers are subscribed to all three mailing lists anyway.
Aug 17 10:15:32 <holtmann> Sure. Give it a spin.
Aug 17 10:15:33 <zhenhua1> sure, i know
Aug 17 10:15:46 <zhenhua1> okay, it's on my task list now
Aug 17 10:15:56 <holtmann> It could also not work out. I doubt it, but that is always a possibility. And only once you tried it, you know.
Aug 17 10:16:34 <zhenhua1> yes. of course.
Aug 17 12:24:26 <zhenhua2> holtmann: i did some test in obexd. many .[ch] files should be duplicated into btio dir, like sdp, hci, l2cap.h, etc.
Aug 17 12:25:04 <zhenhua2> holtmann: will bluez remove libbluetooth or keep libbluetooth and btio co-exist?
Aug 17 12:32:08 <holtmann> sdp sounds wrong.
Aug 17 12:32:21 <holtmann> Also not really copied. Just use the pieces you need.
Aug 17 12:32:43 <holtmann> For bluez, we have to figure out on how to make this work. That is the tricky part.
Aug 17 12:35:48 <zhenhua2> holtmann: client/session.c calls sdp_connect()
Aug 17 12:36:14 <holtmann> What has that to do with btio?
Aug 17 12:36:35 <holtmann> Right, inside obexd. So we still need the libbluetooth dependency.
Aug 17 12:36:42 <holtmann> Crap, so back to the drawing board.
Aug 17 12:36:48 <zhenhua2> it doesn't, but i have to include that sdp.c
Aug 17 12:38:09 <holtmann> Then it is just btio/btio.[ch] then.
Aug 17 12:38:27 <zhenhua2> also hci.[ch]
Aug 17 12:38:38 <zhenhua2> because btio calls hci_devba
Aug 17 12:39:01 <zhenhua2> in btio.c line 642
Aug 17 12:45:18 <holtmann> This becomes a nasty project for you. So you might should plan a little bit longer time for it.
Aug 17 12:45:40 <holtmann> I want to have this cleaned up. No matter how long it takes. And bluez code has a lot of legacy. We have to work through that.
Aug 17 12:45:50 <zhenhua2> haha. i have no idea how to strip that part.
Aug 17 12:45:51 <holtmann> And if needed write new functions for exactly the same job.
Aug 17 12:46:10 <holtmann> denkenz: Are you okay with the SIM polling for STE.
Aug 17 12:57:05 <balrog-k1n> holtmann: it's the same thing the mbm plugin does (and same code)
Aug 17 15:03:00 <denkenz> holtmann: Yeah I already mentioned I was ok with it
Aug 17 15:03:17 <holtmann> Must have missed it. Too late now anyway. I pushed everything ;)
Aug 17 15:08:20 <pessi> oohaah. it works
Aug 17 15:09:37 <holtmann> pessi: Yeah.
Aug 17 15:09:45 <holtmann> What are we cheering for again?
Aug 17 15:10:23 <pessi> connman on n900
Aug 17 15:10:44 <holtmann> Sweet. Why are you telling this the oFono guys ;)
Aug 17 15:10:55 <pessi> because it sets the online ;)
Aug 17 15:11:02 <holtmann> I see. Nice.
Aug 17 15:12:40 <pessi> now there are just some minor timing issues in isimodem drivers
Aug 17 15:14:36 <holtmann> That can be all fixed.
Aug 17 18:05:09 <sameo> denkenz: ping
Aug 17 18:05:18 <denkenz> sameo: pong
Aug 17 18:06:23 <sameo> question about the modem API: Is it possible to have the interfaces array containing the SIM one, but not the GPRS one ?
Aug 17 18:06:35 <denkenz> yep
Aug 17 18:06:47 <denkenz> There are two existing cases like this
Aug 17 18:06:52 <denkenz> For instance, SIM PIN is locked
Aug 17 18:07:16 <denkenz> This prevents the DataConnectionManager from being registered until the PIN is unlocked
Aug 17 18:07:23 <denkenz> The other case is for voice-only modems
Aug 17 18:07:36 <sameo> yes, I thought about the latter.
Aug 17 18:07:54 <sameo> ok, ta
Aug 17 18:11:15 <sameo> oh, and then I guess having the GPRS one without the SIM one is not possible.
Aug 17 18:14:04 <holtmann> Nope. No SIM card, no GPRS. That is how GSM works ;)
Aug 17 18:15:15 <sameo> I just wonder why pessi wants to create the connman device as soon as oFono gives us a SIM...
Aug 17 18:15:40 <sameo> instead of waiting for the GPRS interface to show up.
Aug 17 18:17:39 <holtmann> No idea. I wouldn't do it that way.
Aug 17 18:17:56 <holtmann> If you have a voice only SIM for example, bringing up GRPS makes no sense.
Aug 17 18:18:09 <holtmann> And we won't if the modem tells us voice only.
Aug 17 18:18:20 <holtmann> Also some hardware might not support GPRS at all.
Aug 17 18:18:37 <holtmann> So I would bounce this all based on the GPRS support.
Aug 17 18:18:55 <holtmann> We are also changing oFono to always auto-create at least the Internet context.
Aug 17 18:19:58 <holtmann> So we need to keep that in mind and eventually remove that magic from ConnMan.
Aug 17 18:20:27 <denkenz> sameo, holtmann: He wants it for the online state
Aug 17 18:20:39 <denkenz> That'd be my guess anyway
Aug 17 18:21:14 <holtmann> Okay. Fair enough. Do we have Online = false and GPRS atom removed?
Aug 17 18:21:21 <denkenz> Presumably ConnMan controls the online state even when GPRS is unavailable :)
Aug 17 18:21:43 <denkenz> Actually, we should keep the GPRS atom even when offline
Aug 17 18:21:50 <holtmann> Yes. We should do that.
Aug 17 18:22:01 <denkenz> So we can set Powered / Roaming / Context properties
Aug 17 18:22:03 <holtmann> And if we keep the GPRS atom when offline that would be even better.
Aug 17 18:27:09 <kristenc> denkenz: I have a question about the crsm command.  for a read binary, is p3 supposed to be the number of bytes to read from offset p1 << 8 | p2?
Aug 17 18:29:00 <denkenz> kristenc: Check out 3GPP 11.11 Section 9.2
Aug 17 18:29:05 <sameo> denkenz: it seems he _wants_ to control the online state before knowing if GPRS is available.
Aug 17 18:29:06 <denkenz> I think your interpretation is correct
Aug 17 18:30:04 <denkenz> sameo: He might simply be wanting to control it for all oFono modems
Aug 17 18:30:27 <denkenz> sameo: Not an unreasonable assumption, since ConnMan should have control over that anyway
Aug 17 18:31:04 <sameo> denkenz: what's the pros of doing so instead of controlling the GPRS interface ?
Aug 17 18:31:17 <kristenc> denkenz: do you know what sw2 is supposed to be (I don't have that spec downloaded yet - working it now).
Aug 17 18:32:36 <denkenz> kristenc: Check 9.4.7 in the same spec, basically it tells you whether command succeded or not
Aug 17 18:32:57 <denkenz> sameo: Think of Online as 'Powered' on the Modem interface today
Aug 17 18:33:22 <denkenz> sameo: Online will control the radio state
Aug 17 18:33:40 <denkenz> Because most modems can still be used as a glorified SIM card reader when the radio is turned off
Aug 17 18:33:42 <sameo> denkenz: I understand, but then what's the GPRS interface Powered property for ?
Aug 17 18:34:03 <denkenz> GPRS.Powered is whether you want Data connection
Aug 17 18:34:13 <denkenz> If you're roaming you might not want that turned on at all
Aug 17 18:35:14 <denkenz> holtmann: Btw, GPRS.Powered might be redundant
Aug 17 18:35:29 <denkenz> RoamingAllowed works pretty well for this anyway
Aug 17 18:36:15 <sameo> denkenz: Sure, but I'm looking at it from the current ConnMan point of view.
Aug 17 18:36:54 <denkenz> sameo: I know, unfortunately holtmann signed ConnMan up to control Airplane mode
Aug 17 18:37:18 <denkenz> Which means it has to control that for all devices, including ones with no network capabilities ;)
Aug 17 18:37:18 <sameo> denkenz: I guess pessi is looking forward at cases where ConnMan would be the only app controlling oFono.
Aug 17 18:37:30 <sameo> denkenz: oh, I see now..
Aug 17 18:37:49 <holtmann> Some piece in the system has to do flight mode. And so far this is ConnMan.
Aug 17 18:37:53 <sameo> makes a little more sense.
Aug 17 18:38:28 <holtmann> So yes, in theory we might need to handle device with radio, but no GPRS.
Aug 17 18:39:49 <sameo> denkenz: but you were saying the none of the oFono drivers are currently using the Online prop ?
Aug 17 18:40:52 <holtmann> Not yet, but we have to that eventually.
Aug 17 18:41:16 <holtmann> Or fake it at least as much as we can. I assume MBM is one of the ones that could actually do this easily.
Aug 17 18:41:25 <holtmann> For all the Qualcomm based ones, I have no idea.
Aug 17 18:44:13 <sameo> ok.
Aug 17 18:59:59 <denkenz> sameo, holtmann: Pretty much all USB drivers should really use Online instead of Powered
Aug 17 19:00:17 <denkenz> only something like the Freerunner or the N900 can truly take advantage of Powered
Aug 17 19:19:58 <luke-jr> denkenz: host OS can support turning USB power on/off
Aug 17 19:20:16 <luke-jr> it might lose the ability to detect removal though
Aug 17 19:21:03 <sameo> denkenz: a modem not supporting Online will not export the Online property at all, right ?
Aug 17 19:21:12 <denkenz> luke-jr: There are cases where Powered might make sense with USB devices, e.g. built-in devices
Aug 17 19:21:27 <denkenz> luke-jr: But for vast majority of USB sticks, powered=Off simply means the device disappears
Aug 17 19:22:03 <denkenz> sameo: No, today we just go straight to Online=True and report NotImplemented if someone tries to set Online
Aug 17 19:22:33 <sameo> denkenz: ok.
Aug 17 19:22:37 <luke-jr> I think I might have already asked this, but are there any plans to add framework to allow the user to set the GPRS/UMTS/etc interface name?
Aug 17 19:23:15 <luke-jr> or is something like ifrename needed? (would oFono work with the rename?)
Aug 17 19:23:19 <denkenz> luke-jr: Nope, on high-speed devices this is only given to us by udev anyway
Aug 17 19:23:36 <denkenz> luke-jr: So you can play with udev rules, but that is outside the scope of oFono
Aug 17 19:23:48 <luke-jr> hm
Aug 17 19:32:00 <luke-jr> I don't see any way for udev to identify gprs%d devices
Aug 17 19:33:00 <luke-jr> but then, I'm running Maemo rather than oFono right now
Aug 17 19:33:07 <luke-jr> maybe oFono would show me a context name?
Aug 17 19:36:02 <holtmann> luke-jr: What are you trying to do here.
Aug 17 19:36:18 <holtmann> The interface names are irrelevant.
Aug 17 19:36:36 <luke-jr> holtmann: integration with Gentoo's networking scripts
Aug 17 19:36:52 <luke-jr> /etc/init.d/net.gprs0 start needs the interface to be named gprs0 exactly
Aug 17 19:37:02 <holtmann> Hah. Good luck. That is gonna work at all.
Aug 17 19:37:09 <luke-jr> configuration of interfaces are also done by interface name
Aug 17 19:37:27 <luke-jr> it does work at all, since right now oFono only supports a single context
Aug 17 19:37:45 <luke-jr> but when it supports multiple, it'll need a way to control which gprs%d is used
Aug 17 19:37:50 <luke-jr> or give it a real name
Aug 17 19:37:53 <luke-jr> liek 'tmobile'
Aug 17 19:38:21 <holtmann> That is all pointless attempt to try make something work which is outdated anyway.
Aug 17 19:39:14 <holtmann> Distro scripts are an outdated relict.
Aug 17 19:40:22 <luke-jr> as if there's a reasonable alternative
Aug 17 19:41:18 <holtmann> I would just use ConnMan for this.
Aug 17 19:41:48 <holtmann> We tell you the network interface name via the Settings dict.
Aug 17 19:41:56 <luke-jr> no thanks ☺
Aug 17 19:42:19 <holtmann> All interface names are dynamic. Since oFono doesn't care at all.
Aug 17 19:42:39 <luke-jr> even if Gentoo didn't care, I do. ☺
Aug 17 19:43:06 <luke-jr> if I bring up 5 GPRS links at boot, I don't want to have to guess which number they are
Aug 17 19:43:11 <holtmann> Then you have a problem. You need to read the Settings dict from the oFono context interface.
Aug 17 19:43:22 <holtmann> They will give you the mapping.
Aug 17 19:43:44 <luke-jr> sure, or I could just name them predictably and start using them by name immediately
Aug 17 19:43:50 <luke-jr> without needing to look up a mapping every time
Aug 17 19:44:24 <holtmann> And how are you going to activate these 5 contexts.
Aug 17 19:44:32 <luke-jr> not to mention I don't care to reconfigure the few applications which care about interfaces every boot
Aug 17 19:44:38 <holtmann> (Still like to see a hardware that supports 5 contexts at the same time)
Aug 17 19:44:51 <luke-jr> rc-update add net.tmobile_data default
Aug 17 19:44:57 <luke-jr> rc-update add net.tmobile_mms default
Aug 17 19:45:00 <luke-jr> rc-update add net.tmobile_ipv6 default
Aug 17 19:46:04 <luke-jr> rc-update add net.roaming_att default
Aug 17 19:46:06 <luke-jr> ☺
Aug 17 19:46:17 <holtmann> To be honest, I am not sure that oFono is the right application for your needs.
Aug 17 19:46:45 <luke-jr> it probably isn't, but I don't have a choice there either
Aug 17 19:47:49 <denkenz> Again, oFono does not control the interface name
Aug 17 19:47:50 <luke-jr> I've only heard of one alternative to oFono, and it sounds like it's far worse
Aug 17 19:48:04 <denkenz> What udev gives us, we use
Aug 17 19:48:10 <luke-jr> denkenz: the problem now is how udev can associate interface with context
Aug 17 19:48:20 <luke-jr> none of the udev environment variables appear to be useful
Aug 17 19:48:30 <denkenz> You can't, and that's a fundamental problem
Aug 17 19:48:45 <holtmann> Only the D-Bus Context API with the Settings dict has this association.
Aug 17 19:48:55 <holtmann> Since it is only valid once your PDP context is up and running.
Aug 17 19:48:57 <denkenz> Your high-speed device is not related to the context currently active
Aug 17 19:49:18 <holtmann> You wanna pre-reserve interface on a per context basis. And oFono just doesn't care.
Aug 17 19:49:25 <denkenz> e.g. you can have ip, mms, wap contexts and only 1 high speed interface
Aug 17 19:49:29 <denkenz> They all share that one
Aug 17 19:50:12 <luke-jr> the context name exists before the interface does. there's no reason udev shouldn't be told the context name…
Aug 17 19:50:24 <denkenz> No
Aug 17 19:50:26 <holtmann> udev has no idea about 3G.
Aug 17 19:50:31 <denkenz> Because the context definition is dynamic
Aug 17 19:50:43 <luke-jr> holtmann: nor Ethernet, nor 802.11
Aug 17 19:51:06 <holtmann> You are also not renaming you wlan0 wlan1 depending on what SSID is set, do you
Aug 17 19:51:23 <luke-jr> holtmann: sometimes
Aug 17 19:51:38 <luke-jr> or rather, I'm creating wlanX specifically for a SSID
Aug 17 19:51:52 <holtmann> But then neither ConnMan or NetworkManager will work properly.
Aug 17 19:51:56 <luke-jr> fube
Aug 17 19:51:58 <luke-jr> fine*
Aug 17 19:52:04 <luke-jr> I don't use those,
Aug 17 19:52:06 <luke-jr> nor want to
Aug 17 19:52:15 <holtmann> You will have the same problem with oFono then.
Aug 17 19:52:39 <holtmann> Also with some hardware (like HSO or MBM) you only get one high speed interface that can be used for any context.
Aug 17 19:52:57 <holtmann> Additional PPP ones are then numbers ppp0, ppp1 etc.
Aug 17 19:53:10 <luke-jr> PPP devices can be named arbitrarily, too
Aug 17 19:53:41 <luke-jr> the key difference between 802.11 and oFono data devices, is that 802.11 devices have independent create-interface and configure-interface operations
Aug 17 19:53:53 <luke-jr> whereas oFono is configure-interface only
Aug 17 19:54:27 <holtmann> Depends on your hardware. Some has pre-created interfaces. Others are created when PDP context setup happens.
Aug 17 19:55:09 <denkenz> Seriously, oFono core does not have control here.  You won't get your Pony no matter how much you try ;)
Aug 17 19:55:23 <luke-jr> …
Aug 17 19:56:11 <luke-jr> oFono makes it impossible, best I can tell
Aug 17 19:56:38 <holtmann> It was never our design goal to support this.
Aug 17 19:57:00 <holtmann> Also your hardware choices could make this impossible. Even if we would try.
Aug 17 19:57:38 <holtmann> luke-jr: As I said, you get the information from us. See the list-contexts script.
Aug 17 19:57:49 <luke-jr> interface stuff is all software-side, no reason it isn't fixable.
Aug 17 19:58:04 <denkenz> I look forward to your patch
Aug 17 19:58:13 <holtmann> It needs to be fixed in a consistent way working on all hardware.
Aug 17 19:58:28 <holtmann> What is your target modem hardware?
Aug 17 19:58:34 <luke-jr> N900
Aug 17 19:58:54 <holtmann> Gentoo on an N900 with oFono, but not ConnMan?
Aug 17 19:58:59 <luke-jr> correct
Aug 17 19:59:46 <holtmann> So the Nokia hardware can potentially do multiple context setup and interface renaming. Fair enough. If you tell me on how to do this MBM and HSO, then we can talk.
Aug 17 20:00:04 <luke-jr> no idea what those are
Aug 17 20:00:19 <holtmann> Ericsson MBM and Option HSO 3G modems.
Aug 17 20:00:41 <luke-jr> and the kernel doesn't do the userland-side interface creation?
Aug 17 20:01:40 <holtmann> As I said, that hardware can potentially support it. Others can't. And inside oFono this needs to be unified.
Aug 17 20:01:53 <denkenz> Nokia hw might be good, but its not godlike, I doubt it supports more than 2, max 3 active contexts
Aug 17 20:02:12 <denkenz> So this still won't solve the issue anyway
Aug 17 20:03:20 <luke-jr> if oFono sends the context name to the kernel when it configures the interface, the kernel could potentially pass that to udev which can rename the interface as desired
Aug 17 20:04:21 <holtmann> That is not how this works actually. It only will work for Phonet (if the netlink interface allows this) and potentially for PPP.
Aug 17 20:04:25 * luke-jr ponders how exactly ppp, 802.11, etc name their devices
Aug 17 20:04:38 <holtmann> For MBM and HSO this is not that simple.
Aug 17 20:04:52 <holtmann> And not all network interfaces support renaming properly.
Aug 17 20:04:57 <holtmann> This causes problems.
Aug 17 20:05:42 <luke-jr> I'm not suggesting renaming is done by oFono at this point, just that oFono ensure udev gets enough information that it can identify oFono interfaces
Aug 17 20:31:05 <holtmann> luke-jr: We are not giving anything to udev at all.
Aug 17 20:31:23 <holtmann> You would need to write a udev helper talking D-Bus to oFono and figuring this out.
Aug 17 20:31:55 <holtmann> However you don't even know which is a 3G network interface and which not. udev just doesn't really know that.
Aug 17 20:32:18 <holtmann> Only exception is DEVTYPE=cellular. But I am not sure that Phonet does that.
Aug 17 20:34:13 <holtmann> You could hack something that makes this work on the N900, but nothing that can be generalized to make it useful for upstream.
Aug 17 20:34:16 <tgall_foo> anyone have opinions on the telit 86x parts and their EVK2 evaluation kit ?
Aug 17 20:43:40 <denkenz> tgall_foo: I have one, but honestly haven't used it much
Aug 17 20:44:09 <denkenz> They do make their AT command documentation fully available and the modem is pretty fully featured
Aug 17 20:46:49 <tgall_foo> yeah that was the part that seems nice ...  
Aug 17 20:53:12 <e-yes> how do I remove primarycontext(s)?
Aug 17 20:56:13 <denkenz> e-yes: ConnMan.RemoveContext()
Aug 17 20:58:22 <e-yes> denkenz, any chance to call it using dbus-send?
Aug 17 20:59:27 <denkenz> everything can be called using dbus-send
Aug 17 21:02:08 <e-yes> RemoveContext(object context), object == type? is it supported by dbus-send?
Aug 17 21:02:39 <denkenz> e-yes: object == objectpath in dbus
Aug 17 21:03:05 <denkenz> so using objpath works just fine
Aug 17 21:08:10 <e-yes> objpath - that's a key. thank you
Aug 17 23:06:16 <e-yes> when i get Modem.propertyChanged("Powered") i'm going to set "Online" property to true. but it always fails: org.ofono->SetProperty(Online) to 0x40108900 failed: .NotAvailable
Aug 17 23:07:13 <e-yes> org.ofono - name of bus, actualy i call SetProperty for Modem proxy
Aug 17 23:08:26 <e-yes> or i must "listen to" interface changes (SIM Manager?)
Aug 17 23:10:19 <denkenz> What hardware?
Aug 17 23:11:47 <denkenz> And the most likely cause is that you have a SIM PIN set
Aug 17 23:11:58 <denkenz> oFono won't allow you to go Online until you enter the PIN
Aug 17 23:34:11 <e-yes> denkenz, n900modem, pin is not set
Aug 17 23:36:29 <denkenz> e-yes: The .NotAvailable error is only returned if the modem has not reached a SIM_READY state
Aug 17 23:36:45 <denkenz> Perhaps you're simply too fast...
Aug 17 23:36:58 <luke-jr> denkenz: can the SIM_READY state be read?
Aug 17 23:37:02 <luke-jr> or detected?
Aug 17 23:37:18 <denkenz> You need to wait for the PinRequired property to get fired
Aug 17 23:37:49 <denkenz> Remember, Online / Offline is highly experimental and not even upstream yet
Aug 17 23:42:28 <denkenz> In your case, performing Online toggling when you get the SubscriberIdentity is better
Aug 17 23:43:11 <denkenz> After modem is powered and before Online toggling there's quite a bit of processing / querying to be done
Aug 17 23:44:11 <denkenz> holtmann: We might need a SimReady property
Aug 18 00:28:10 <luke-jr> denkenz: and signal, IMO
Aug 18 00:28:43 <balrog-k1n> PropertyChanged should be enough?
Aug 18 00:28:48 <luke-jr> oh, true
Aug 18 00:28:59 <luke-jr> maybe a more generic name, too; I imagine CDMA has some equivalent
Aug 18 01:11:37 <denkenz> balrog-k1n: How nasty is Setup Call btw? Do you have a prototype yet?
Aug 18 01:13:19 <denkenz> balrog-k1n: And what does the spec say about the display of alpha_id2 ? Is that mandatory?
Aug 18 01:18:29 <balrog-k1n> denkenz: i don't have any code yet, will send another doc change proposal according to what holtmann suggests
Aug 18 01:19:10 <balrog-k1n> denkenz: for both alpha id's it says "the terminal shall use it [...]", so i guess it is
Aug 18 01:20:17 <denkenz> Ok, then we need to come up with a nice property name
Aug 18 01:20:20 <balrog-k1n> denkenz: please let me know if you have a different idea about how we can do that
Aug 18 01:21:03 <denkenz> AlphaIdentifier is just too hard to explain :(
Aug 18 01:21:21 <balrog-k1n> Label?
Aug 18 01:22:35 <denkenz> Description?
Aug 18 01:24:39 <denkenz> We have also used 'AdditionalInformation' in the NetworkOperator API
Aug 18 01:24:49 <denkenz> So any of those two get my vote
Aug 18 01:25:40 <balrog-k1n> Information or Message would be good i think, because the sim can put any kind of message or instruction for the user in it
Aug 18 01:27:08 <balrog-k1n> "Now talk to the microphone.. and be kind"
Aug 18 01:28:47 <denkenz> Information is pretty close to AdditionalInformation, so I'm fine with that one too
Aug 18 01:30:05 <denkenz> Also we will need to add CNAP support and an extra property for this as well
Aug 18 01:30:22 <denkenz> So the two should not overlap and be quite clear
Aug 18 01:32:08 <denkenz> And the dial string stuff in Setup Call is actually a bit nasty
Aug 18 01:32:46 <balrog-k1n> yeah.. i'm hoping that there are many modems that implement Set Up Call in firmware, like the Calypso
Aug 18 01:33:48 <balrog-k1n> as far as i can tell we have no way of sending the subaddress through AT for example
Aug 18 01:34:07 <denkenz> Yep, if we get one like that then just fail
Aug 18 01:34:32 <denkenz> But dial strings are something we'll have to do at some point :(
Aug 18 01:34:47 <czhang> I see there is a 'Power' and 'Online' and property in modem API. I think maybe only one is enough. 
Aug 18 01:35:46 <denkenz> czhang: They are actually different, and both are required.  See the mailing list archives for the exact reasons
Aug 18 01:35:47 <czhang> according to 3GPP 27.007 when +CFUN=0 means the RF is turn off, so of course the modem is offline.
Aug 18 01:36:13 <balrog-k1n> sometimes you need to use the modem even if it's offline
Aug 18 01:36:29 <balrog-k1n> for example sim applications can be used
Aug 18 01:36:41 <balrog-k1n> and phonebook
Aug 18 01:36:50 <czhang> Yes, but when +CFUN=0, it does not impact the access of SIM.
Aug 18 01:37:10 <denkenz> You're thinking of Offline mode, Powered means something different
Aug 18 01:37:37 <denkenz> Some modems need to be physically turned off for various reasons as well
Aug 18 01:37:48 <denkenz> e.g. firmware upgrades
Aug 18 01:37:55 <balrog-k1n> czhang: in practice it does impact sim access on the MBM modem and on Calypso for example
Aug 18 01:38:42 <czhang> yes
Aug 18 01:39:35 <czhang> but I see when the power property's value is false, all atoms will be removed
Aug 18 01:39:47 <denkenz> And btw, on many modems CFUN=0 is used for power off, and CFUN=4 for airplane mode
Aug 18 01:45:16 <zhenhua1> denkenz: so i guess we should update plugin to add set_online, like phonesim does.
Aug 18 01:45:42 <zhenhua1> denkenz: e.g. for huawei modem, CFUN=0 means offline, 1 menas online.
Aug 18 01:45:54 <zhenhua1> am i right?
Aug 18 01:46:32 <denkenz> Probably, but online/offline is more trickier than that
Aug 18 01:46:35 <czhang> When CFUN=0, can access SIM?
Aug 18 01:46:43 <zhenhua1> btw, does calypso support multiple active Gprs contexts?
Aug 18 01:46:51 <denkenz> Calypso should
Aug 18 01:46:55 <denkenz> czhang: It depends on the modem
Aug 18 01:47:11 <denkenz> For instance, MBM devices jump off the USB bus when you issue CFUN=0
Aug 18 01:47:12 <zhenhua1> i tried on freerunner, but looks not, return me CME error
Aug 18 01:47:22 <czhang> OK
Aug 18 01:47:44 <denkenz> zhenhua1: It also depends on the network, might be that the network doesn't
Aug 18 01:47:45 <zhenhua1> czhang: i could have a try on huawei modem, not sure
Aug 18 01:47:56 <balrog-k1n> denkenz: i think the stkagent should reply with UserTerminatedSession to the card when the dbus call returns error or invalid response, should i send a patch?
Aug 18 01:48:20 <zhenhua1> denkenz: if china mobile doesn't support that, i have no choice...
Aug 18 01:48:28 <balrog-k1n> currently we just release the agent, but don't send a response to the card
Aug 18 01:48:47 <denkenz> zhenhua1: Well, the fact that you get a CME error probably means the modem itself doesn't support it
Aug 18 01:49:01 <denkenz> balrog-k1n: I'm pretty sure we do
Aug 18 01:49:40 <zhenhua1> denkenz: i see. it sends me CME 300: ME Failure.
Aug 18 01:50:14 <zhenhua1> denkenz: anyway, maybe my operation has some mistakes. first try. ;-)
Aug 18 01:50:27 <balrog-k1n> denkenz: i can't see it being sent in the code, and i don't see it in the debug trace
Aug 18 01:50:54 <denkenz> R02P604
Aug 18 01:51:02 <denkenz> woops
Aug 18 01:51:10 <denkenz>         if (stk->current_agent == stk->session_agent && agent_called(stk)) {
Aug 18 01:51:11 <denkenz>                 DBG("Sending Terminate response for session agent");
Aug 18 01:51:11 <denkenz>                 send_simple_response(stk, STK_RESULT_TYPE_USER_TERMINATED);
Aug 18 01:51:11 <denkenz>         }
Aug 18 01:51:40 <denkenz> I'm pretty sure I tested that
Aug 18 01:51:46 <denkenz> But maybe I'm wrong
Aug 18 01:51:48 <balrog-k1n> let me check
Aug 18 01:52:22 <denkenz> zhenhua1: We need to port all drivers to Online eventually
Aug 18 01:52:32 <denkenz> zhenhua1: However, this needs to be coordinated with ConnMan
Aug 18 01:52:50 <denkenz> zhenhua1: Feel free to work on that if you want
Aug 18 01:53:20 <zhenhua1> denkenz: right. i guess so
Aug 18 01:54:10 <zhenhua1> denkenz: will try to send patches if i could do that. marcel ask me to do some btio.[ch] stuff first.
Aug 18 01:54:23 <balrog-k1n> ah agent_called is not updated to support Get Input, i'll test and send a patch
Aug 18 01:54:44 <zhenhua1> denkenz: the btio.[ch] work looks tricky.
Aug 18 01:55:17 <denkenz> zhenhua1: That is also important
Aug 18 01:55:39 <denkenz> There's plenty of work, you don't even have to look hard ;)
Aug 18 01:55:57 <zhenhua1> denkenz: without that, i cann't push my DUN patches. DUN takes me too long.
Aug 18 01:56:35 <denkenz> Nah, DUN is extremely tricky and its taking about what I thought it would
Aug 18 01:57:47 <zhenhua1> but i have already some codes there. no comments still?
Aug 18 01:58:10 <denkenz> One step at a time, lets solve the btio problem first
Aug 18 01:58:23 <zhenhua1> sure, will do
Aug 18 01:59:56 <denkenz> balrog-k1n: Hah, missed that part when I integrated your patches :)
Aug 18 02:03:53 * balrog-k1n blames it on the idea of agent_called()
Aug 18 02:05:10 <denkenz> I don't remember the exact reason, but I think its the weird Immediate Response crap
Aug 18 02:07:33 <denkenz> Code got extremely tricky because of that one
Aug 18 02:12:44 <czhang> I have submit the APIs for SIM/UIM manager. I'd like do some changes about current APIs.
Aug 18 02:15:31 <czhang> replace properties 'Present' 'PinRequired' and 'LockedPins' with a single property 'Staus'. 
Aug 18 02:16:59 <balrog-k1n> LockedPins is a non-volatile information stored in the card
Aug 18 02:18:03 <czhang> According to 3GPP 27.007, there is no way to get all LockedPins.
Aug 18 02:18:11 <denkenz> What would the 'Status' property's values be?
Aug 18 02:19:18 <czhang> besides the values of current PinRequired property, add a new value 'absent'
Aug 18 02:21:31 <denkenz> Not sure what that really buys you
Aug 18 02:22:27 <denkenz> And if you look at how Present is used, you'll notice it is a hint whether any of the other properties are available
Aug 18 02:22:36 <czhang> I see in current implementation the LockedPins properties is set when lock PIN. It can not really indicate all the Pins is locked.
Aug 18 02:23:01 <denkenz> LockedPins is a nicety
Aug 18 02:23:06 <denkenz> oFono fudges that one
Aug 18 02:23:19 <denkenz> Its really only meant for PIN1
Aug 18 02:23:50 <czhang> e.g. when the modem is powered on both PIN and PIN2 is locked. with +CPIN, can only get to know PIN is locked.
Aug 18 02:24:22 <denkenz> I know, that one maybe we can be persuaded into, but as I said, it is a nicety
Aug 18 02:25:04 <czhang> OK. 
Aug 18 02:25:41 <czhang> What about support PIN retry count?
Aug 18 02:25:51 <denkenz> That is already a task in the TODO list
**** ENDING LOGGING AT Wed Aug 18 02:59:57 2010