**** BEGIN LOGGING AT Fri Nov 26 02:59:58 2010
Nov 26 14:36:03 <demarchi> denkenz: ping
Nov 26 14:55:08 <denkenz> demarchi: pong
Nov 26 16:05:57 <demarchi> denkenz: about the order of the signals, i'll have a similar issue in radio settings
Nov 26 16:06:39 <demarchi> denkenz: so, what do you think of rework of the ofono_radio_settins struct like this:
Nov 26 16:06:51 <demarchi> http://codepad.org/u3oNIM20
Nov 26 16:08:56 <demarchi> then we split the 'set' method into 2... one to set the fields (which would actually copy the entire _pending struct over the other) and the signal sending.
Nov 26 17:11:38 <demarchi> ahn... no, they are not queried at once, even if they are answered all together
Nov 26 17:12:10 <denkenz> demarchi: Yeah, so for now don't worry about it
Nov 26 17:12:24 <denkenz> demarchi: But if you're curious, the way to do this is how call-barring does it
Nov 26 17:12:27 <demarchi> denkenz: what should happen if i call GetProperties() in one interface, the first one goes ok and the second query fails?
Nov 26 17:12:42 <denkenz> e.g. basically saving the properties in a side structure and signaling them all at once
Nov 26 17:13:03 <demarchi> denkenz: yeah... i was doing that for radio-settins now
Nov 26 17:13:58 <demarchi> do you think it's worth doing before putting another property?
Nov 26 17:14:33 <denkenz> I'm fine either way
Nov 26 17:14:46 <denkenz> if you have the code ready and it won't take long, then lets do it
Nov 26 17:14:54 <demarchi> denkenz: ok... 
Nov 26 17:15:10 <denkenz> property queries failing is a bizarre case
Nov 26 17:15:53 <demarchi> ok... for text telephony i put them in the right order
Nov 26 17:16:10 <demarchi> i think i'll do for radio-settings as a followup patch
Nov 26 17:16:27 <denkenz> Ok, so should I ignore the pending text-telephony patches for now?
Nov 26 17:16:38 <demarchi> denkenz: why?
Nov 26 17:16:51 <demarchi> denkenz: the patches i sent are right i hope
Nov 26 17:16:59 <demarchi> denkenz: i'm doing radio-settings now
Nov 26 17:17:03 <denkenz> ah ok
Nov 26 18:14:41 <padovan> denkenz: ping
Nov 26 18:18:52 <denkenz> padovan: pong
Nov 26 18:21:54 <padovan> denkenz: about CNAP; when should I send the +CNAP=[<n>] to enable or disable CNAP? It should be part of the powering up process I think, but I don't know which part exactly
Nov 26 18:26:12 <denkenz> probably just inside voicecall
Nov 26 18:26:27 <denkenz> However, you will also need to use CNAP? in call-settings as well
Nov 26 18:26:37 <denkenz> Since you need to query it just like CLIP
Nov 26 18:28:48 <padovan> I see.
Nov 26 18:29:18 <denkenz> Just follow the CLIP logic
Nov 26 18:29:23 <denkenz> CNAP is basically the same
Nov 26 18:30:15 <padovan> Great, that will help, I'm still lost in the 27.007 stuff
Nov 26 18:31:58 <denkenz> so am I ;)
Nov 26 18:43:47 <denkenz> +       if (ctm->enabled ^ enabled_old)
Nov 26 18:43:47 <denkenz> +               ctm_signal_enabled(ctm);
Nov 26 18:43:53 <denkenz> demarchi: What's wrong with != ? ;)
Nov 26 18:44:47 <demarchi> denkenz: i like xor
Nov 26 18:44:51 <demarchi> don't you like?
Nov 26 18:45:09 <denkenz> I find it less readable
Nov 26 18:45:56 <demarchi> yeah... everybody tell me that and i can't convince them otherwise :(
Nov 26 18:46:02 <denkenz> lol
Nov 26 18:49:46 <padovan> demarchi: so you just have to convince youself that != is better now
Nov 26 18:50:15 <padovan> they will be the same after compile ;)
Nov 26 18:50:55 <demarchi> denkenz: are you sure going with two properties for radio-settings (GsmBand and UmtsBand) is the best way? Why not a big enum with all values?
Nov 26 18:51:23 <demarchi> padovan: nah... xor has a stronger meaning
Nov 26 19:01:08 <denkenz> demarchi: Sure? no, but it seems best
Nov 26 19:01:21 <denkenz> And we actually prefer != for oFono
Nov 26 19:01:43 <denkenz> But then that is my only complaint so far, so you're doing pretty good ;)
Nov 26 19:02:42 <demarchi> i really like xor, but i'll try not to use it anymore :~)
Nov 26 19:06:48 <denkenz> +       enable = !!enable;
Nov 26 19:06:53 <denkenz> I also hate that ;)
Nov 26 19:07:23 <demarchi> damn... one more thing i like :-)
Nov 26 19:08:03 <demarchi> yeah... in this case i could remove because i'm the only caller of that function
Nov 26 19:08:06 <denkenz> What is this trying to do? Guarantee that it is always 1?
Nov 26 19:08:13 <denkenz> or 0?
Nov 26 19:08:31 <demarchi> denkenz: yes... because there isn't a true boolean
Nov 26 19:08:36 <demarchi> it's just an int
Nov 26 19:09:05 <demarchi> so if this would be called from outside, this is the way i guarantee it's either 0 or 1
Nov 26 19:09:10 <denkenz> As a rule, oFono does not set ints to anything but TRUE/FALSE 
Nov 26 19:09:41 <demarchi> denkenz: it's because i'm used to develop libs, used by others
Nov 26 19:09:55 <demarchi> then i can't guarantee the others will give me the right data
Nov 26 19:10:08 <denkenz> And in this case you can actually use ofono_bool_t
Nov 26 19:10:10 <demarchi> in this case... it's true, it's pointless
Nov 26 19:10:59 <evadim_> hi! I have qualcomm gobi2000, and try it with ofono, but no luck
Nov 26 19:11:00 <denkenz> Another case where we're not 100% consistent :P
Nov 26 19:11:22 <demarchi> yet, ofono_bool_t is just a typedef to int
Nov 26 19:11:33 <denkenz> so is gboolean
Nov 26 19:11:40 <denkenz> But you can trust the core to honor the contract
Nov 26 19:11:58 <demarchi> true true
Nov 26 19:13:12 <demarchi> denkenz: do you want me to send another version with these things fixed?
Nov 26 19:13:34 <evadim_> demarchi try to help me with udev rules, but test/list-modems still show nothing
Nov 26 19:13:42 <denkenz> evadim_: For gobi we require qualcomm proprietary protocol, which we do not support
Nov 26 19:13:58 <evadim_> hm
Nov 26 19:14:09 <denkenz> NetworkManager has reverse engineered parts of it, but in general Qualcomm is pretty closed
Nov 26 19:14:21 <evadim_> ehehe....
Nov 26 19:14:25 <denkenz> demarchi: Hold on for a sec, I might have you re-submit a few of them
Nov 26 19:15:14 <demarchi> ok... i'm going home now, i'll be back soon
Nov 26 19:16:10 <evadim_> denkenz: but after loading firmware it appear as 3 ttyUSB ports, and one of it - AT modem, no?
Nov 26 19:17:01 <denkenz> Yeah, but oFono really needs 2 AT ttys
Nov 26 19:17:36 <denkenz> Otherwise once you run PPP you lose the ability to control the device
Nov 26 19:18:03 <evadim_> ehehe...
Nov 26 19:18:15 <denkenz> So far I have not heard of a high-speed interface for gobi
Nov 26 19:18:22 <denkenz> Or the ability to use to AT command channels
Nov 26 19:18:39 <denkenz> If you can figure out either, then we can add support for it
Nov 26 19:18:53 <evadim_> heh
Nov 26 19:20:32 <evadim_> you know any mini pci module for notebook with 3G+GPS that work properly in linux ?
Nov 26 19:21:36 <evadim_> heh, but if i insert it to my netbook i should hack my bios...
Nov 26 19:21:52 <evadim_> :(
Nov 26 19:25:11 <evadim_> denkenz: anyway, thanks!
Nov 26 19:25:35 <denkenz> evadim_: Yes, look into mbm
Nov 26 19:25:47 <denkenz> They have 3G + GPS and work seamlessly with oFono
Nov 26 19:26:13 <evadim_> mbm ?
Nov 26 19:26:29 <denkenz> Ericsson - MBM, e.g. F3507 / F3607
Nov 26 19:26:34 <denkenz> aka Dell 5540
Nov 26 19:26:44 <denkenz> Maybe sold under other names
Nov 26 19:27:06 <evadim_> ok
Nov 26 19:27:37 <denkenz> Also see Sony MD300 / MD400
Nov 26 19:27:44 <denkenz> I think the 300 doesn't have GPS, but 400 might
Nov 26 20:16:34 <Jeevaka> denkenz: regarding one of the call volume patch
Nov 26 20:16:42 <denkenz> yep?
Nov 26 20:17:40 <Jeevaka> either we need to change the order we register the call volume register in the generic at modem or its better to have that check
Nov 26 20:18:52 <Jeevaka> this is about the call-volume: Remove atom registered check
Nov 26 20:20:17 <denkenz> I'm not following
Nov 26 20:20:40 <denkenz> Isn't the core and driver fine as is?
Nov 26 20:22:54 <Jeevaka> yep, agree. but why are we waiting for only clvl_query success to call register function
Nov 26 20:25:31 <Jeevaka> Incase of CMUT is not supported but CLVL is supported, we will call register but the other way we dont
Nov 26 20:26:00 <Jeevaka> is there any reason behind that. may be i missing something
Nov 26 20:28:29 <denkenz> We sort of assume both are supported
Nov 26 20:30:13 <Jeevaka> ok, then I think its better to have that check:-) 
Nov 26 20:30:27 <denkenz> nod
Nov 26 20:35:42 <Jeevaka> isn't the extra line at the EOF is not recommended?
Nov 26 20:58:05 <denkenz> Jeevaka: a newline at EOF is not good
Nov 26 21:07:37 <Jeevaka> ok, patch sent
Nov 26 21:14:03 <demarchi> denkenz: humn... sorry, i used a wrong regex to make the rename
Nov 26 21:14:29 <demarchi> denkenz: besides, in phonesim driver, do i rename tty to ctm?
Nov 26 21:14:46 <denkenz> demarchi: might be good to be consistent
Nov 26 21:20:41 <denkenz> balrog-k1n: Can you take a look at the stk patch from Guillaume?
Nov 26 21:29:45 <Jeevaka> may be I'm becoming more style-pedantic
Nov 26 21:30:01 <denkenz> nothing wrong with that ;)
Nov 26 21:42:46 <demarchi> denkenz: in ctm.h, shouldn't query_tty and set_tty be named query_ctm and set_ctm too?
Nov 26 21:55:06 <denkenz> demarchi: Both are fine, doesn't really matter
Nov 26 21:55:09 <denkenz> leave it for now
Nov 26 23:22:53 <demarchi> q
Nov 26 23:23:22 <demarchi> humn... sorry, this should be in a vim window
**** ENDING LOGGING AT Sat Nov 27 02:59:58 2010