**** BEGIN LOGGING AT Fri Apr 16 03:00:02 2010 Apr 16 05:19:14 denkenz: looks like Dell 5530 doesn't have data port, so I cannot load it by mbm driver now. Apr 16 09:53:34 denkenz, holtmann, is there any problem patches Ive send some time ago to fix some problems with gdbus watches? Apr 16 14:06:04 Vudentz: Don't remember these patches. Apr 16 14:18:02 zhenhua, martin_office: Are you sure 5530 doesn't have a data port or is it just not being picked up by our udev magic? Apr 16 14:22:11 denkenz: i am not sure whether 5530 has data port. however, i see "DataDevice" is nul in mbm_enable(). let me know if you want more detailed info. Apr 16 14:23:39 denkenz: mbm modem does work before you add data device in mbm.c and udev.c Apr 16 14:24:55 zhenhua: Can you check what ttys are created by 5530 ? Apr 16 14:25:02 zhenhua: Are there two or just one? Apr 16 14:26:20 sorry, i don't have 5530 on hand. in my memory, it's more than two, and we use ttyACM1 as modem device. Apr 16 14:26:40 So it sounds like the udev magic is wrong Apr 16 14:26:57 maybe Apr 16 14:27:24 Can someone check the attributes of the ttys to see whether its yet-another-variation of spelling Data Apr 16 14:27:25 if (ofono_modem_get_string(modem, MODEM_DEVICE) == NULL) Apr 16 14:27:26 ofono_modem_set_string(modem, MODEM_DEVICE, devnode); Apr 16 14:27:26 else Apr 16 14:27:26 ofono_modem_set_string(modem, DATA_DEVICE, devnode); Apr 16 14:27:46 it always goes true branch Apr 16 14:28:47 does you mean the udev properties? Apr 16 14:28:52 yes Apr 16 14:29:12 so i could check that Monday. Apr 16 14:30:22 hopes it's not too late Apr 16 14:31:41 That's fine, I can probably push your patch until then, we will see Apr 16 14:32:43 sure. i just want to report it asap. Apr 16 14:32:59 could the problem be that the udev plugin has the same priority as the modem plugin? Apr 16 14:33:21 nope Apr 16 14:33:35 my modem.conf is empty Apr 16 14:34:38 denkenz: i'd like to investigate two gprs related bugs reported by qa. Apr 16 14:34:52 sure Apr 16 14:34:55 don't find root case yet. Apr 16 14:35:29 will let you know when i have findings. Apr 16 14:38:41 denkenz: what do you mean by 'hint' in the async shutdown thread? Apr 16 14:41:01 as in, disable(modem, boolean final) Apr 16 14:55:13 denkenz: so final == true means 'power down modem' Apr 16 14:55:25 and final == false means 'just RF off' Apr 16 14:56:21 something like that Apr 16 14:56:55 I still don't get why we're doing all of this when I already said I want a flight mode option eventually Apr 16 14:57:42 denkenz: that's not what I sensed on the mailing list... Apr 16 14:58:00 Several times I said that 'Flight' mode is a good idea ;) Apr 16 14:59:00 denkenz: you mean separate ops for RF on/off? Apr 16 15:00:22 I want dedicated flight mode, not necessarily the particulars of whether this means RF on / off or something else Apr 16 15:01:14 Well, that is also what I'd like, but the devil is in details ;) Apr 16 15:01:18 Some atoms also need to be removed when in flight mode (e.g. most of call barring, call settings, etc) Apr 16 15:01:44 And some atoms need to go into reduced-functionality mode (e.g. just being able to set settings) Apr 16 15:02:09 denkenz: sure, but voicecall is one we need for E911 Apr 16 15:02:21 both E911 numbers and dialing one Apr 16 15:02:52 err, explain, voicecall is already available on pre-sim Apr 16 15:03:09 denkenz: not when Powered=false ;) Apr 16 15:03:24 I am mistakenly thinking still that that would be flight mode :) Apr 16 15:04:03 Someone explain to me the logic of having voicecalls when rx/tx is off Apr 16 15:04:27 This is a disconnect we're having across many conversations Apr 16 15:09:02 denkenz: at least you need the emergency numbers, so the manager atom is needed Apr 16 15:09:17 the call UI could always turn RF on and then dial Apr 16 15:09:30 Ok, that's a different issue Apr 16 15:10:39 denkenz: of course, if the manager atom is there, it could also internally enable the modem, if the call is to an emergency number Apr 16 15:10:39 So I suggest we start properly brainstorming how Flight mode would look like Apr 16 15:10:58 +1 Apr 16 15:11:59 Are you sure an emergency call 30K feet up is a good idea? :) Apr 16 15:12:30 All of that seems like a bizarre usecase Apr 16 15:13:10 denkenz: it's bizzarre no matter what Apr 16 15:13:39 if the call UI turns flight mode off to dial one, it should also remember to turn flight mode back on Apr 16 15:13:55 My point is, who's going to help you up there even if you do manage to dial an emergency service? Apr 16 15:14:07 What are they going to do, send people with rocket boosters? Apr 16 15:14:31 unfortunately, they might send fighter jets... :o Apr 16 15:15:31 and flight mode is used outside airplanes, too Apr 16 15:16:08 I have never done so actually Apr 16 15:16:43 Anyway, that is something we can discuss further after we get flight mode figured out Apr 16 15:16:44 I do it in hospitals and the opera and other such places with RF mics Apr 16 15:49:40 holtmann, denkenz, git pull git://gitorious.org/~vudentz/ofono/vudentzs-ofono.git master Apr 16 15:50:28 holtmann, gdbus changes should apply cleanly to bluez connman obexd Apr 16 15:54:38 hi all Apr 16 15:54:50 sorry for the intrusion in "flight mode" thread Apr 16 15:55:15 I don't know if this is in topic but I have one question regarding modem power states Apr 16 15:56:20 what is the best practice to verify user PIN? I mean the best sequence of powering up, checking if PIN is required asking pin and so on.. Apr 16 15:56:51 as far as i know if the modem is not powered I don't have the interfaces to check the PIN Apr 16 15:56:56 oFono will (should? :) tell you Apr 16 15:57:09 Check the SimManager docs Apr 16 15:57:18 and if I power the modem it tries registering on the network Apr 16 15:57:33 ok I'll read thank you denkenz Apr 16 15:57:44 oFono doesn't require you to do anything manually Apr 16 15:57:57 If the PIN is not required, we simply proceed to network registration Apr 16 15:58:14 djdas: most modems will not power rf until the sim is ready Apr 16 15:58:30 unless you make an amergency call Apr 16 15:59:03 denkenz, I put my question in a wrong way :) Apr 16 15:59:29 I test oFono without PIN so I see the powering+registration sequence ok Apr 16 15:59:38 what if the SIM is PIN-locked? Apr 16 16:00:03 do I receive a signal? Apr 16 16:01:07 if so i must unlock the PIN with UnlockPin("pin", "MYPIN") and oFOno auto.registers on the net or do I have to force the registration? Apr 16 16:01:44 No, you will get a signal from SimManager and the NetworkRegistration atom will not be availabl Apr 16 16:01:45 +e Apr 16 16:01:46 pessi, sorry I was talking about the software side of oFono Apr 16 16:02:06 looking from the "client" side of the software Apr 16 16:02:11 e.g. PropertyChanged(PinRequired, "pin") Apr 16 16:02:47 Then you use EnterPin() until you lock the PIN (requiring a PUK) or unlock Apr 16 16:03:04 If you need a Puk, you use ResetPin Apr 16 16:03:04 ok so the sequence is: SetProperty("Powered", true) -> if SIM not locked -> auto registration Apr 16 16:03:32 yes, assuming you have automatic registration set to on (the default) Apr 16 16:03:46 If you did manual operator selection, then it won't send a COPS Apr 16 16:03:52 (however some modems register anyway) Apr 16 16:04:01 else i get PropertyChanged(PinRequired, "pin") then I EnterPin(string type, string pin) -> auto registration Apr 16 16:04:17 yes I have auto registration Apr 16 16:05:02 great Apr 16 16:05:55 the same sequence is repeated at each powering OFF->ON so my "client powering up sequence" is always the same Apr 16 16:07:23 pessi: So let us start brainstorming the Flight mode stuff Apr 16 16:07:46 pessi: The shutdown() thingy is just not the right way to go Apr 16 16:07:52 I just sent a rant on the list Apr 16 16:08:51 pessi: I know, and I realize you're frustrated, however I tried telling you that proper Flight mode is the way to go ;) Apr 16 16:09:21 denkenz: do we agree that we need separate rf on/off? Apr 16 16:09:46 pessi: We need flight mode semantics, what that means on the modem side is up to the driver Apr 16 16:10:08 99% of the time it'll result in rf on/off Apr 16 16:11:12 sure, but we should also define what flight mode means on air interface Apr 16 16:12:25 no TX unless it is really needed Apr 16 16:12:34 So my current thoughts are that we have pre_sim, flight, post_sim Apr 16 16:12:52 And we keep track of the atoms created in each of those phases Apr 16 16:13:20 The atoms that cannot operate fully in a certain phase, will need to setup a watch and act accordingly Apr 16 16:14:07 e.g. gprs can set settings, but not actually activate gprs, sim atom can change SMSC, etc Apr 16 16:14:19 The real tricky one is voicecalls Apr 16 16:14:40 hm? Apr 16 16:15:01 You potentially need rf on while in pre_sim state for voicecalls Apr 16 16:15:30 only after user has dialed an emergencyu number Apr 16 16:15:59 Yes and no, some modems actually don't do it this way Apr 16 16:16:30 you mean driver has explicitly tell them to enable radio, register and then dial? Apr 16 16:17:10 Some modems actually have explicit notifications when emergency dialing is available Apr 16 16:17:17 and that requires rx/tx to be on Apr 16 16:19:55 so we actually have use case of rx on/off in pre-sim state Apr 16 16:20:12 potentially yes Apr 16 16:20:21 However, this is not for the core to figure out Apr 16 16:20:26 That is for the modem driver to figure out Apr 16 16:23:56 and how this works with flight mode? Apr 16 16:24:45 Typically this is done on modems before flight mode was ever invented Apr 16 16:25:20 The reason for it is emergency dialing while PIN is blocked Apr 16 16:25:29 They kept rf on in those cases Apr 16 16:27:33 The other complication is that modems have their own idea of what constitutes an emergency number Apr 16 16:27:52 They don't necessarily follow the 3GPP specs, or have extra numbers burned into the ROM Apr 16 16:29:37 should that be also driver-specific, so only the driver knows about extra emergency numbers? Apr 16 16:31:02 That is a good question Apr 16 16:31:40 That is part of the reason why I don't want to interfere too much with the calls inside voicecall atom Apr 16 16:31:41 and if we have an application that just wants to make an emergency call, should it be possible without having a peek on emergency number list (on SIM card)? Apr 16 16:32:11 In general 112 and 911 _always_ work Apr 16 16:32:18 So an application doesn't actually need to peek Apr 16 16:33:08 except phones sold in Singapore Apr 16 16:34:42 So that is the issue, if the modem has its own idea, the driver either needs to tell us, or we just dial it an let the modem decide whether it is an emergency number or not Apr 16 16:38:21 for now I suggest we do the basics, e.g. pre, flight, full functions in the modem driver, FlightMode property of some kind, flight mode watch, automatic removal of atoms not useful in some particular phase Apr 16 16:39:48 sounds reasonable Apr 16 16:43:39 and then the Powered, we have 1) modems that you can't power on or off (a real phone on USB, for instance) 2) modems that you have to power on in boot and power off in shutdown (N900) 3) modems that you have to power off in order to disable TX and 4) modems that you can power on/off when needed Apr 16 16:44:26 Yep Apr 16 16:45:02 So we have some support for 1) since the driver can simply tell us it is powered, e.g. hfp does this Apr 16 16:45:20 2) Is really a UI issue Apr 16 16:45:30 3) You basically don't support flight mode Apr 16 16:45:42 Remember, some devices simply won't need it Apr 16 16:46:56 For 1) The USB semantic might be to use powered on/off and not support flight mode, e.g. the current semantics Apr 16 16:52:41 well, some phones use usb for charging => some Nokia phones open ISI channel over USB for diagnostics Apr 16 16:52:51 but that is probably our headache Apr 16 16:54:20 denkenz: so who is going to add the pre/flight/full modes to core? add them first, and try to see later what to do with various atoms? Apr 16 16:54:45 Well I'm swamped, so I have no plans to do that in the short term Apr 16 16:54:53 So if you want, you can work on it Apr 16 16:55:00 But yes, the basic plumbing is the first priority Apr 16 16:55:12 We can then go atom by atom to see what needs to be blocked for flight mode Apr 16 16:56:51 k Apr 16 16:57:27 and by the way, what you thinkg about plugins providing atoms? Apr 16 16:58:20 can we open atom interface and provide range of atom types for plugins? Apr 16 16:59:27 That was the eventual intent Apr 16 16:59:33 Not sure if we're ready for that though Apr 16 17:01:03 but eventually ;) Apr 16 17:01:39 Eventually yes Apr 16 19:58:43 denkenz: ping Apr 16 20:02:21 padovan: pong Apr 16 20:08:00 denkenz: I'm thinking about a bluetooth lib to share code between the hfp and dun plugins. The idea is to create a interface where plugins can register for get notified about new devices with the requested uuid. That will be the only interface exported, the rest of the code to handle the bluez API can be static. How does that sounds to you? Apr 16 20:09:55 seems reasonable Apr 16 20:12:15 Nice. I'm starting that here and then create a prototype for the dun plugin Apr 16 20:19:14 yep, see my post to the list about emulator stuff Apr 16 20:19:21 Tell me if it makes sense Apr 16 20:26:42 holtmann: That goes for you too, the idea is that the emulator is done completely in-core Apr 16 20:27:28 holtmann: And connman can then listen for DUN emulator interface going up and adding it to the right bridge Apr 16 20:33:20 denkenz: I can't find your post. Apr 16 20:33:52 reply to zhenhua's patch Apr 16 20:34:08 ah! Apr 16 23:39:20 denkenz: No. oFono has to add it to the bridge. ConnMan will only tell you which bridge it is. Apr 16 23:39:42 That is how we will be doing it with BlueZ. Apr 16 23:59:26 holtmann: Ok, that could work, assuming you're fine with oFono core accessing connman directly and not through a driver **** ENDING LOGGING AT Sat Apr 17 02:59:56 2010