**** BEGIN LOGGING AT Tue May 12 00:15:31 2009
May 12 00:15:38 <rwhitby> thx
May 12 00:16:50 <rwhitby> Daily log is at http://logs.nslu2-linux.org/livelogs/ofono.txt, previous 24 hours will be at http://logs.nslu2-linux.org/livelogs/ofono-prev.txt and archive at http://logs.nslu2-linux.org/livelogs/ofono/
May 12 00:18:10 <rwhitby> holtmann: is there any relationship between ofono.org and freesmartphone.org ?
May 12 00:18:29 <holtmann> No. It is a complete new project.
May 12 00:20:02 <Lewis__> holtmann, why create a new one if we already have freesmartphone.org ?
May 12 00:22:51 <holtmann> Lewis__: Because FSO doesn't do what we want from an API and design perspective.
May 12 00:23:47 <rwhitby> One would expect the fact that Intel and Nokia have no leverage over FSO would come into the equation as well ...
May 12 00:25:25 <holtmann> Not really. This is meant as a full open source project. We would have contributed to FSO if the API would be in a way we envision it.
May 12 00:25:46 <rwhitby> holtmann: that's good to hear.
May 12 00:26:32 <holtmann> We want to do something like a 21st century telephony stack and not some copy of ETSI specifications. It needs to be simple for the UI.
May 12 00:27:35 <Lewis__> holtmann: Nice"!
May 12 00:28:37 <holtmann> The time of our UI developers is better spent to make everything look sexy than solving technical issues because of stupid APIs :)
May 12 00:29:25 <Lewis__> :)
May 12 01:22:17 <KaraDog> hi, all
May 12 01:26:37 <KaraDog> How to compile ofono grabbed from git??
May 12 01:26:52 <KaraDog> no configure script there??
May 12 01:27:56 <KaraDog> OK. got it... run bootstrap first
May 12 02:39:45 <holtmann> ./bootstrap-configure
**** ENDING LOGGING AT Tue May 12 02:59:57 2009

**** BEGIN LOGGING AT Tue May 12 02:59:57 2009
May 12 07:06:33 <carldani> hi
May 12 07:07:35 <carldani> I couldn't find any info on how ofono.org compares to freesmartphone.org.
May 12 07:08:26 <holtmann> It is different. Different API and different design.
May 12 07:12:17 <carldani> That implies you either didn't know of FSO or didn't like it. If you didn't like it, I'd be very interested in a comparison between ofono and fso.
May 12 07:12:43 <carldani> Unfortunately, the ofono website is missing and such coparison
May 12 07:14:43 <carldani> a wiki/blog entry about the differences (or advantages of ofono) would be very nice  to have.
May 12 07:17:10 <holtmann> I am aware of FSO, but we think their API is putting to much knowledge into the UI. From our point of view it should be really simple to write phone applications like dialer, text msg or integrate it with existing apps. Keywords like customization and branding of the UI come to mind.
May 12 07:17:31 <holtmann> The FSO API is basically a AT command set converted into a D-Bus API.
May 12 07:17:38 <holtmann> oFono has nothing alike.
May 12 07:18:03 <carldani> So oFono is a higher level API than FSO?
May 12 07:18:11 <holtmann> Since it is a popular request to compare FSO against oFono, we will be working on writing up the details they have in common and where they differ.
May 12 07:18:35 <carldani> Cool, thanks
May 12 07:18:41 <holtmann> It is a different API. if you wanna call it high level, then feel free, but you will realize it is different.
May 12 07:19:23 <holtmann> It makes full use of the potential of D-Bus.
May 12 07:20:06 <Mirv> ehlo
May 12 07:20:46 <carldani> Ah hm. So in theory it should be possible to create compat wrappers in both directions. Good to know.
May 12 07:21:12 <holtmann> In theory you could create an oFono modem plugin that will talk to FSO.
May 12 07:21:31 <holtmann> The other way around is more complicated.
May 12 07:22:49 <holtmann> As I said, the oFono API is different. I follows different design principals and leaves a lot of GSM/UMTS details out since nobody really ever sees them.
May 12 07:23:00 <holtmann> If the UI doesn't need these details, there are no in the API.
May 12 07:24:39 <carldani> Thanks for the info!
May 12 07:25:19 <holtmann> Any time.
May 12 07:30:46 <Mirv> and probably rinse and repeat that hourly :) FAQ section is probably under work already?
May 12 07:31:01 <Mirv> (I read http://logs.nslu2-linux.org/livelogs/ofono.txt already before joining)
May 12 07:33:27 <shoragan> holtmann, we indend to have a more abstract api on top of ogsmd
May 12 07:34:37 <shoragan> we started designing the api with same goals as ofono (minimal, easy to use)
May 12 07:35:02 <shoragan> so what we have now is based on what the users needed
May 12 07:35:33 <holtmann> We want to have even less logic inside the UI code.
May 12 07:35:47 <holtmann> Hence a total different API design.
May 12 07:36:12 <shoragan> there is not much logic needed in the ui with current fso
May 12 07:36:41 <shoragan> it's more or less just mapping buttons to dbus calls
May 12 07:36:59 <shoragan> and signals to text fields/labels
May 12 07:37:45 <holtmann> First of all you are handing id from on signal to another one.
May 12 07:37:59 <shoragan> ok, yes
May 12 07:38:15 <holtmann> An id in D-Bus terms should be represented with an object path.
May 12 07:38:26 <shoragan> what are you doing instead? handing a dbus object path?
May 12 07:39:19 <holtmann> This makes an API like ListCalls horribly complex.
May 12 07:39:33 <holtmann> Also how do you do MultiParty calls.
May 12 07:39:43 <shoragan> in that case i think that using object paths there involves more boilerplate code
May 12 07:40:13 <holtmann> Where is the boilerplate code. In the UI. If it is in the UI, then the bindings are not good enough.
May 12 07:40:39 <shoragan> hmm
May 12 07:41:00 <shoragan> would you also represent each sms and sim contact as a dbus objec?T
May 12 07:42:18 <holtmann> If you would expect direct access over D-Bus, then you would do exactly that.
May 12 07:42:33 <holtmann> However there is more to SMS then just text messaging.
May 12 07:42:58 <shoragan> of course
May 12 07:43:55 <josch> fgau: you are too late ;)
May 12 07:44:09 <holtmann> You need an interface where certain applications (internal/external) can register for certain SMS services (aka ports). So that EDS for example could just register for text messages and then process and present them.
May 12 07:44:24 <shoragan> not-sim-buffered sms are different, you'd like to have some way to notify the target app
May 12 07:44:32 <shoragan> and get the ack back
May 12 07:45:00 <holtmann> We are not doing SIM stuff. The SIM concept is dead and stupid. The SIM is just an identity module for the auth.
May 12 07:45:29 <holtmann> oFono will take care of multipart SMS, reassemble them and then hand them off to the processing application (which could be a plugin).
May 12 07:46:00 <holtmann> Same goes for the SIM phonebook btw. We will only allow import from it. That is it.
May 12 07:46:07 <shoragan> ah
May 12 07:46:38 <shoragan> then you need to have persistent storage for fragements in ofono
May 12 07:47:01 <holtmann> We decided to ignore this stupid parts of the ETSI specs. and implement the parts that really matter these days (and not what mattered ten years ago).
May 12 07:47:03 <shoragan> they could come over a long time
May 12 07:47:16 <holtmann> And yes, we spool the parts in /var/spool/ofono or similar.
May 12 07:47:44 <holtmann> Price we have to pay. Better than DoS on the SIM card memory (16 messages only or so).
May 12 07:49:07 <carldani> Hm. Since when can SIM cards only store 16 messages? My (admittedly 8 year old) SIM card can store around 120 messages.
May 12 07:50:07 <josch> carldani: fact is that there is a limit - that sucks big time
May 12 07:51:10 <josch> same for contacts: there is only limited space on the sim - how do you sync contacts with your sim when you want to put more there than possible?? this is a mess
May 12 07:51:10 <holtmann> carldani: Whatever number there is. It will be reached and a Symbian phone for example will DoS. You can't delete fragments.
May 12 07:51:53 <holtmann> Also the other thing is that the SIM card access is horribly slow.
May 12 07:51:57 <carldani> josch: Yes, the limit sucks. But I have owned (even recent) phones which had less in-phone SMS slots than my SIM.
May 12 07:52:23 <josch> carldani: i think we agree that we dont want to have any limits at all
May 12 07:53:01 <carldani> josch: True. I also want a phone to keep a copy of as many SMS as possible on the SIM in case my phone dies.
May 12 07:53:57 <holtmann> carldani: With the same argument could your SIM card defect and then you want to keep it inside the phone.
May 12 07:53:58 <josch> carldani: no - for that you want to sync with some other source
May 12 07:54:11 <josch> like your laptop or desktop
May 12 07:54:13 <holtmann> Backup of your contacts and SMS is the only answer.
May 12 07:54:57 <holtmann> I think that systems like MobileMe from Apple showed how this is done best.
May 12 07:55:16 <carldani> holtmann: No, totally different argument. I wrote the SIM should have _copies_ of in-phone SMS. In case of a SIM card defect and a still-working phone, I lose nothing.
May 12 07:55:48 <holtmann> We are not syncing between the SIM card and the phone. If you wanna sync, then sync with a cloud system or your desktop.
May 12 07:56:09 <holtmann> SIM cards are horribly slow.
May 12 07:57:06 <carldani> Sync with a cloud system over the phone network is expensive for many contracts -> no go for me.
May 12 07:57:29 <josch> carldani: this was only an example..
May 12 07:57:42 <holtmann> Then use a cable or Bluetooth or WiFi. This is not really an issue here. Is it?
May 12 07:57:44 <carldani> Sync with a desktop... maybe. I've seen too many incompatible phone backup apps on my linux desktop to actually believe in that option.
May 12 07:58:19 <holtmann> oFono is not covering sync. We will only support the export of the SIM phonebook for legacy reasons.
May 12 07:58:35 <holtmann> That is as much as we get into PIM details.
May 12 07:58:52 <shoragan> holtmann, are there some API specs for ofono?
May 12 07:59:09 <holtmann> Yes, but I forgot to push them into the repo. Planning on doing that soon.
May 12 07:59:12 <carldani> So phone developers have to write their own complete software stack to handle syncing?
May 12 07:59:47 <holtmann> Depends on. oFono is not covering sync.
May 12 07:59:57 <shoragan> carldani, you probablt would use some pim server (eds) and opensync
May 12 07:59:59 <carldani> I'm trying to understand the design philospophy.
May 12 07:59:59 <holtmann> That is as much as I am going to say about this.
May 12 08:00:24 <carldani> OK
May 12 08:00:47 <holtmann> Assume the rest :)
May 12 08:00:57 <josch> holtmann: to slightly change the topic - will ofono only be for telephony or even provide services for other smartphone tasks?
May 12 08:01:13 <holtmann> Only telephony.
May 12 08:01:30 <josch> which covers call handling, sms and the pb exporting
May 12 08:01:38 <holtmann> To some degree GPS integration where GSM/GPS comes on the same chip. That has to be still figured out.
May 12 08:01:41 <shoragan> are you using multiple AT ports?
May 12 08:02:03 <holtmann> josch: And at some point GPRS/UMTS data connections of course.
May 12 08:02:14 <shoragan> via 0710
May 12 08:02:15 <holtmann> josch: Also call forwarding, holding, caller id etc.
May 12 08:02:21 <josch> holtmann: so you have a muxer for the modem to handle gsm and gprs
May 12 08:02:37 <carldani> Have a nice day everyone.
May 12 08:02:52 <josch> carldani: likewise
May 12 08:03:05 <holtmann> For the GSM MUX we have to do something at some point. Some modem are just plain stupid and have only one port.
May 12 08:03:22 <holtmann> For us the only real solution is to get the GSM MUX finally into the kernel.
May 12 08:03:35 <josch> good call
May 12 08:03:54 <holtmann> However there are modems with multiple ports and network interfaces. Also there are modems (like Nokia PhoNet) that don't use AT commands at all.
May 12 08:04:31 <josch> holtmann: when you handle gprs - do you also handle ppp and the network management that comes with it?
May 12 08:05:01 <holtmann> If we need PPP, then we will. However PPP is not used over the air. It is just plain old crap legacy.
May 12 08:05:14 <shoragan> for gprs you probably don't want to use the old pppd
May 12 08:05:30 <holtmann> Depends on the modem hardware. Some give us no other choice.
May 12 08:05:30 <shoragan> you only need it on some modems for IP/DNS negotiation
May 12 08:05:57 <holtmann> For UMTS is actually becomes a problem because of the speed. We need some high-speed interface.
May 12 08:06:16 <josch> but then when ofono handles ip/dns then it has to act as a network manager
May 12 08:06:20 <shoragan> i've seen some modems which use usb-cdc ether
May 12 08:06:24 <shoragan> and simply offer dhcp
May 12 08:07:19 <holtmann> Doing IP/DNS negotiation and setting them are two different things. NM or ConnMan for that matter will take care of dealing with network interfaces.
May 12 08:07:53 <holtmann> However oFono will tell ConnMan for example that is has a static IP address (received from the GSM network) or that DHCP might be used.
May 12 08:08:02 <josch> i see
May 12 08:08:12 <josch> you probably prefer connman
May 12 08:08:37 <holtmann> NM will work as good. However our goal is to integrate oFono with ConnMan and BlueZ.
May 12 08:09:15 <holtmann> And yes, BlueZ will get a telephony plugin that talks to oFono. So that headset/handsfree support works.
May 12 08:23:16 <shoragan> holtmann, just a quick question about bluez v4, why does it use the pid in the object paths?
May 12 08:24:35 <holtmann> Just to make sure people don't hardcode object path. The only hardcoded on is the manager path.
May 12 08:25:00 <holtmann> Could also be a random number, but PID is cheaper :)
May 12 08:26:30 <shoragan> just seems somewhat "un-dbus-ish"
May 12 08:27:18 <holtmann> Actually it is not. The adapter present in your system should be discovered and not hardcoded in your application.
May 12 08:27:44 <holtmann> I had to put this quirk in to ensure that application developers do the right thing :)
May 12 08:27:44 <shoragan> (discovery) yes, of course
May 12 08:28:04 <shoragan> i've just been annoyed by it during debugging
May 12 08:28:06 <shoragan> ;)
May 12 08:28:15 <holtmann> Other than that. A object path is just an identifier. Doesn't have to be readable.
May 12 08:28:34 <holtmann> That is why I always use Python for testing. Nice and quick.
May 12 08:28:59 <holtmann> I think we discussed to disable it when -d is enabled, but nobody ever sent a patch for it.
May 12 08:29:21 <holtmann> And I don't care. No problems for my debugging.
May 12 08:34:12 <emdete> holtmann: are you interested to discuss pyneo?
May 12 08:35:02 <holtmann> I have 20 minutes battery power left. Then I go to sleep.
May 12 08:35:08 <emdete> :D
May 12 08:36:05 <emdete> i know pyneo is lacking documentation and other stuff. that's because nobody pays for it and i am alone in development so i concentrate for the important stuff. 
May 12 08:36:53 <holtmann> I can't even get to the bare low-level D-Bus API. So I can even tell if it would be close to what we envision or not.
May 12 08:37:25 <holtmann> Also the missing concept of SCM usage is not working for me at all.
May 12 08:37:48 <emdete> holtmann: i know. the definition is in py for now. we can extract xml inrtospection i you like or i explain how it'e meant
May 12 08:38:15 <emdete> holtmann: strange, scm is not related to pyneos' arch in any way
May 12 08:38:21 <holtmann> That is what I would need. I can read Python code to some degree, but if we wanna talk API, then I need introspection.
May 12 08:38:50 <holtmann> Not that strange, I like to be able to see the history of a project and how an API evolved over time.
May 12 08:38:56 <emdete> holtmann: introspection is there, but again: i have very, very limited resources, things will be done if they are important
May 12 08:39:07 <holtmann> We put oFono out into the public as soon as possible so that everybody can follow the development.
May 12 08:39:17 <emdete> holtmann: i know about that. i /use/ a scm, sure
May 12 08:39:57 <holtmann> We can talk about the API if you give me at least introspection details. Otherwise I can't discuss much.
May 12 08:40:06 <emdete> holtmann: but there are things in there that are not for public, like passwords and pins because  i did not separate that in the past
May 12 08:40:24 <emdete> holtmann: so the xml files would be enough?
May 12 08:40:42 <holtmann> D-Bus introspection in XML would be a start.
May 12 08:40:46 <emdete> find
May 12 08:40:47 <emdete> fine
May 12 08:41:24 <emdete> i will try to do that soon. hopefully we could work together...
May 12 08:42:43 <holtmann> I would like that. However one big difference is that we are using C for the daemon and not Python. You realize that. It will not change :)
May 12 08:43:01 <emdete> sure. no problem with that!
May 12 08:43:02 <holtmann> What runs in application space, can be Python for all we care.
May 12 08:43:34 <emdete> :D one important point with pyneo is: all, really all functionality is behind dbus for the gui
May 12 08:43:34 <tuukkah> morning
May 12 08:43:59 <tuukkah> emdete, would it be easy to create the xml from the python decorators in the docs?
May 12 08:44:03 <emdete> and i would like to see more c there. i just have not the time to do si
May 12 08:44:20 <emdete> tuukkah: i just said, i will do that for you next
May 12 08:44:29 <holtmann> tuukkah: Good night. I am off to bed now. Battery is empty and it was a long day.
May 12 08:44:32 <emdete> s/you/ofono-people/ :)
May 12 08:44:45 <tuukkah> holtmann, sleep tight :-)
May 12 08:44:54 <josch> holtmann: good night!
May 12 08:45:42 <tuukkah> emdete, i meant i suppose there are several ways to make the xml
May 12 08:46:04 <emdete> tuukkah: tell me more :)
May 12 08:47:28 <emdete> tuukkah: i would just use dbus introspection. the py bindings to the xml for you if you specify the interface in python
May 12 08:48:49 <tuukkah> emdete, do you need an instance of the object before you can perform introspection? that might not be practical to automate
May 12 08:51:58 <emdete> tuukkah: i just had an idea how to do that. the problem is (normaly) that you have no call object if there is no call. but because i have all the py interfaces i could do dummy instances without functionality in there and than ask for xml
May 12 08:52:46 <tuukkah> that sounds nice
May 12 08:54:00 <emdete> ...and may probably work. i had a py dbus binding patch that includes the py doc into the xml which would be of great help for no-py people
May 12 08:54:08 <emdete> s/had/made/
May 12 09:02:12 <PaulFertser> Is there anybody here that is officially involved in the ofono project except holtmann?
May 12 09:04:24 <emdete> hi PaulFertser ! :D
May 12 09:04:51 <PaulFertser> emdete: Hey :) Looks like alien invasion in here.
May 12 09:05:30 <josch> indeed
May 12 09:08:22 <emdete> PaulFertser: what happened in moscow last days, i heard of a gas explosion?
May 12 09:09:05 <PaulFertser> emdete: sorry, too OT for this chan, i can tell you about it at #pyneo.org
May 12 09:16:19 <tuukkah> PaulFertser, at least akiniemi sent the announcements about the project
May 12 09:17:24 <PaulFertser> tuukkah: well, saw that. Hope he's online now.
May 12 09:17:58 <PaulFertser> akiniemi: Can you please clarify one important thing: will proprietary plugins (e.g. for accessing modems) be possible?
May 12 09:28:18 <florian> good morning
May 12 09:39:32 <tuukkah> PaulFertser, from yesterday: <holtmann> And to answer the other question that will come eventually, we are using GPLv2 to enforce that all components of the oFono core daemon (including plugins) stay open source.
May 12 09:40:31 <PaulFertser> tuukkah: are you sure that means no nonsence like proprietary HTC "RIL" can happen?
May 12 09:44:20 <tuukkah> i dunno, but i suppose if someone makes a plug-in that depends on a proprietary interface, then the plug-in source code will "document" the interface
May 12 09:50:24 <PaulFertser> tuukkah: there shouldn't be any proprietary interfaces between the modem chip and end-user apps...
May 12 09:51:07 <tuukkah> right
May 12 09:57:12 * tuukkah notices a new commit at http://git.kernel.org/?p=network/ofono/ofono.git
May 12 09:57:42 <emmentaler> hi
May 12 09:58:00 <emmentaler> do you support data calls in ofono? i mean CSD calls
May 12 09:58:31 <emdete> emmentaler: i would assume that's a connman thing to do
May 12 09:59:21 <emmentaler> problem: i would like to do a datacall from phone A to phone B and then issue a serial connection between them .. 
May 12 09:59:28 <emmentaler> is this already implemented?
May 12 09:59:28 <PaulFertser> emdete: there should be some support on the lower levels to establish it first even if you're going to have ppp over it.
May 12 10:00:01 <emmentaler> i dont need ppp, just a serial link (serial pseudo device, muxer channel) between the two phones..
May 12 10:00:45 <PaulFertser> emdete: CSD has some advantages over GPRS, it's basically like an old-school modem link between the two devices, you can answer it, and it has a constant low enough latency.
May 12 10:02:03 <emmentaler> and a graanteed bandwith, roaming, etc
May 12 10:02:56 <PaulFertser> emmentaler: do you want to help pyneo or FSO to implement CSD? Does any of this stack already work with your modem?
May 12 10:04:18 <emmentaler> i talked to mickey concerning this .. but it stopped somewhere since something else is more important.. 
May 12 10:04:33 <emmentaler> my current test environment are some neos 
May 12 10:05:10 <PaulFertser> emmentaler: have you tried CSD calls using AT-commands directly on your devices? Do you lack any documentation for that or what?
May 12 10:05:29 <tuukkah> i've tried it and there was nothing surprising
May 12 10:07:08 <PaulFertser> emmentaler: in fact you can simply request a channel from the muxer and it'll give you a pty, write some commands in pty (probably with the help of "chat" or similar) and have you serial connection... Ad hoc, but should work.
May 12 10:08:06 <emmentaler> jop we tried this.. it works quite good with mickeyterm, but open a call by doing it the "right way (TM)" is now missing.. we built an encryption appplication that needs the pty to communicate.. 
May 12 10:09:11 <PaulFertser> emmentaler: and i assume the main problem is that you don't want to handle connection establishing in the app itself?
May 12 10:09:34 <PaulFertser> emmentaler: because you just ask the muxer and it gives you pty, do what you wish...
May 12 10:10:25 <emmentaler> yes .. we have two apps .. securedialer and securecall .. securecall does the encryption and voice stuff. securecall has to be started with $securecall </dev/pty> --caller/--callee
May 12 10:10:51 <emmentaler> securedialer should now open a data call and start securecall with the right pty as  param
May 12 10:10:57 <emmentaler> then the whole stuff should work
May 12 10:11:26 <emmentaler> we now have some problems getting the channel using dbus.. 
May 12 10:11:59 <PaulFertser> emmentaler: wow, do you want to move to -cdevel to discuss this further?
May 12 10:12:23 <emmentaler> ok
May 12 10:57:23 <Amygos> hi, anyone can show me an example of use ofone with dbus-send?
May 12 10:57:55 <Amygos> (and sorry for my bad english :)
May 12 11:04:36 <tuukkah> Amygos, do you know you can use the d-feet gui for testing?
May 12 11:07:05 <Amygos> no, thanks i will look for that
May 12 11:14:28 <Amygos> but if someone can show a sample with dbus-send it  would be more simple for me, i test ofone in neo freerunner 
May 12 11:14:56 <rzr> hi
May 12 11:36:04 <tuukkah> Amygos, dbus-send --print-reply --system --dest=org.ofono / org.ofono.at.Manager.Create string:"tcp:127.0.0.1:1234" string:"ti_calypso"
May 12 11:37:47 <Amygos> tuukkah, thank this is what i search
May 12 11:38:18 <tuukkah> then you need the modem in local tcp port 1234, for example with socat something like this: socat -v -dddd TCP4-LISTEN:1234,reuseaddr,fork file:/dev/ttySAC0,crtscts,echo=0,raw
May 12 11:38:53 <tuukkah> if you do that, then the dbus-send should reply with 'object path "/modem1"'
May 12 11:39:56 <PaulFertser> tuukkah: Are you in any way affiliated with the project?
May 12 11:41:12 <tuukkah> Amygos, after which you can try for example dbus-send --print-reply --system --dest=org.ofono /modem1 org.ofono.VoiceCallManager.Dial string:"123456789" string:""
May 12 11:41:25 <tuukkah> PaulFertser, nope, just checking out what's there
May 12 11:42:02 <PaulFertser> tuukkah: does it already have any calypso-specific parts?
May 12 11:44:30 <tuukkah> just the init here: http://git.kernel.org/?p=network/ofono/ofono.git;a=blob;f=drivers/atmodem/main.c;h=384f1688b41a2672eab8f034b585274f1ffce956;hb=HEAD#l280
May 12 11:51:01 <Amygos> ofone support the SIM PIN?
May 12 12:00:23 <tuukkah> the atmodem driver doesn't seem to
May 12 12:28:49 <Amygos> tuukkah, it seem' s do something in src/call-meter.c at cm_set_property()
May 12 12:38:10 <tuukkah> but the AT command would be something like CPIN, right?
May 12 12:38:23 <tuukkah> and it should be in atdriver
May 12 12:44:10 <Amygos> yes, if i understand right
May 12 12:45:28 <tuukkah> but if the plug-ins already have a capability for sending pin, it might not take more than implementing that function
May 12 18:04:46 <BluesLee> hmm
May 12 21:47:09 <bernt> After starting `./src/ofonod -n -d` calling `mdbus -s org.ofono` gives only / as result. Are there any hints what to do?
May 12 21:47:58 <denkenz> The AT plugin doesn't have a modem to connect to by default
May 12 21:48:10 <denkenz> You need to use org.ofono.at.Manager to connect to one over tcp
May 12 21:49:14 <denkenz> ser2net, netcat, etc work for this. 
May 12 21:50:58 <bernt> ok I will try it ...
May 12 22:06:08 <bernt> ok, now I get this /modem1, but no org.ofono.VoiceCallManager.Dial is possible ... 
May 12 22:09:38 <denkenz> oh?
May 12 22:13:20 <bernt> I dont know how to send the pin for the sim .. perhaps than I will see the VoiceCallManager or?
May 12 22:14:28 <denkenz> We don't support PIN Lock just yet
May 12 22:14:53 <denkenz> So you have to do it manually, then expose the modem through tcp
May 12 22:16:00 <bernt> ok, perhaps tomorrow ...
May 13 00:22:00 <holtmann> denkenz: This reminds me that I have to add support more /etc/ofono/modem.conf and udev detection :)
May 13 00:23:25 <denkenz> holtmann: Nod, assuming modems actually support this :)
May 13 00:24:44 <holtmann> We have to get a modem driver into it. However first I have to fix some ConnMan bugs.
May 13 00:24:52 <holtmann> s/driver/driver model/
May 13 00:25:11 <denkenz> holtmann: yeah, trouble is hardware :)
May 13 00:25:33 <denkenz> holtmann: About the only commonly available one is the Neo, and its actually pretty braindead
May 13 00:25:52 <denkenz> holtmann: We also need to get phonesim hosted somewhere
May 13 00:26:38 <holtmann> denkenz: Working on the phonesim part already.
May 13 00:26:54 <holtmann> modem.conf could also contain a unix or tcp socket address :)
May 13 00:27:04 <denkenz> holtmann: True enough
May 13 00:35:31 <denkenz> holtmann: Have you pushed the *-api docs yet?
May 13 00:45:32 <sabotage> speaking of modems, have either of you tested AT plugin with any USB modems?  Would that work for a test env until we get something else?
May 13 01:05:25 <denkenz> sabotage: No reason why not
May 13 01:06:43 <sabotage> thanks denkenz, any that you've tried yet, or are known to work better under linux than others
May 13 01:07:11 <sabotage> btw, did you get to celebrate mothers day this year ;)
May 13 01:11:28 <denkenz> sabotage: Yep :)
May 13 01:11:37 <denkenz> sabotage: And no, I've no idea about linux usb modems
May 13 01:11:44 <denkenz> sabotage: I've only tried the Neo
May 13 01:12:26 <denkenz> sabotage: There's another thing I did try though:
May 13 01:12:55 <denkenz> sabotage: Use rfcomm to export a Bluetooth-enabled mobile phone
May 13 01:13:11 <denkenz> sabotage: Then connect up ofonod to it :)
May 13 01:13:25 <denkenz> sabotage: Worked pretty well with an old Sony-Ericsson I had
May 13 01:18:43 <sabotage> congrats then denkenz!
May 13 01:18:54 <sabotage> (and to your wife ;)
May 13 01:19:07 <sabotage> bbl, dinner...
May 13 01:19:12 <denkenz> sabotage: Thanks :)
**** ENDING LOGGING AT Wed May 13 02:59:57 2009

**** BEGIN LOGGING AT Wed May 13 02:59:57 2009
May 13 03:02:02 <holtmann> denkenz: About the unit test patches. Are these real unit tests or only test scripts like we have in BlueZ and ConnMan?
May 13 03:02:15 <holtmann> If later then I like to put them into test/ directory.
May 13 03:17:15 <denkenz> holtmann: no they are real unit tests
May 13 03:17:29 <denkenz> holtmann: They test e.g. the Supplementary Service string parser
May 13 03:17:45 <denkenz> holtmann: The pack/unpack and pdu / tpdu encoding / decoding
May 13 03:19:27 <holtmann> denkenz: Btw. can you enforce the coding style. Like trailing whitespaces are  not allowed :)
May 13 03:19:49 <denkenz> holtmann: I run checkpatch.pl on everything
May 13 03:19:56 <denkenz> holtmann: But I might have missed a patch
May 13 03:20:06 <holtmann> Andrew's patches had trailing whitespaces.
May 13 03:20:11 <holtmann> git-am detects these :)
May 13 03:20:22 <denkenz> holtmann: I git-amed them on my tree
May 13 03:20:41 <denkenz> holtmann: And I swear I ran checkpatch.pl as well
May 13 03:20:47 <denkenz> holtmann: Sorry :)
May 13 03:20:57 <holtmann> Don't worry. I do check that stuff.
May 13 03:21:12 <holtmann> And that author name etc. stuff is present and correct :)
May 13 03:21:42 <denkenz> holtmann: Which file did you see this in?
May 13 03:21:55 <holtmann> Another favor. Can you make sure that commit messages are at most 72 chars width.
May 13 03:22:12 <holtmann> Forgot the patch number.
May 13 03:23:46 <denkenz> Sure
May 13 03:24:31 <denkenz> Mindboggling, my checkpatch.pl is not reporting any issues
May 13 03:24:44 <holtmann> git-am can be pickier :)
May 13 03:24:46 <denkenz> Do you use --strict ?
May 13 03:24:59 <holtmann> Also you broke "make distcheck". I am fixing that right now.
May 13 03:25:22 <holtmann> I don't use checkpatch.pl, as I said, just git-am.
May 13 03:25:33 <holtmann> It is picky about trailing and leading whitespaces.
May 13 03:26:11 <denkenz> Hmm, is there an opion to git-am that I should use?
May 13 03:28:36 <holtmann> Not that I know of.
May 13 03:29:49 <denkenz> Then I'm at a loss, unless my squashed commits introduced something
May 13 03:35:45 <sabotage> denkenz: holtmann: set whitespace = error in the [apply] section of your ~/.gitconfig or ofono.git/config
May 13 03:36:10 <sabotage> will force failure on git-am attempts 
May 13 03:36:22 <sabotage> that have whitespace violations of course
May 13 03:37:07 <holtmann> denkenz: Do me one favor, run make distcheck when you touch any Makefile.am or configure.ac. If problems arise, ask me, I can fix that. I am an autoconf/automake god :)
May 13 03:37:31 <sabotage> I also have check = true in [format-patch] so when I generate patches, I get notified before I get embarassed ;)
May 13 03:38:12 * sabotage notes that holtmann is a autoconf/automake god :)
May 13 03:38:37 <holtmann> Your unit test linking was totally braindead. Sorry to be blunt :)
May 13 03:39:07 <holtmann> sabotage: Thanks for these hints. Updated my .gitconfig now.
May 13 03:39:20 <sabotage> np
May 13 03:39:42 <sabotage> only learned them myself a few weeks ago, so I am *not* a git god
May 13 03:40:09 <denkenz> holtmann: Yeah sorry about cssn.h, I forgot your totally reworked the headers to be !intuitive to me ;)
May 13 03:40:31 <denkenz> sabotage: Thanks for the hints :)
May 13 03:40:35 <holtmann> I get by with git and fix some major breakage on the kernel, but that is about. Don't ask me about complex things.
May 13 03:41:17 <holtmann> s/kernel/server side/
May 13 03:41:59 <holtmann> denkenz: Don't worry, I can fix all of this. One thing I am picky about is that make distcheck works flawlessly. Otherwise I get into big trouble when building releases :)
May 13 03:42:14 <holtmann> denkenz: Reminds me to test ofono.git on my build servers.
May 13 03:48:01 <holtmann> Crap I can't clone the repo on my big endian machine. Runs the same Fedora than my laptop.
May 13 03:49:11 <denkenz> heh
May 13 03:49:21 <holtmann> git-clone report remote repo hung up.
May 13 03:49:47 <denkenz> funny, git web is not showing anything
May 13 03:49:50 <denkenz> Might be why :)
May 13 03:49:52 <holtmann> I build release on a big endian machine to catch last minute bugs :)
May 13 03:50:09 <holtmann> kernel.org is slow today. I have one anon clone and that worked fine.
May 13 03:50:27 <denkenz> Heh, you might have killed the repo :)
May 13 03:51:07 <holtmann> No. The repo is just fine.
May 13 03:52:06 <denkenz> I'm kidding, but kernel.org is not responding and I can't pull
May 13 03:52:49 <holtmann> Even if I killed the repo. Advantage of GIT is that everyones copy is as good as the master copy.
May 13 03:53:04 <denkenz> http://git.kernel.org/?p=network/ofono/ofono.git;a=summary
May 13 03:53:07 <denkenz> Nothing there :)
May 13 03:53:12 <denkenz> I know :)
May 13 03:53:56 <holtmann> Mine is stuck at yesterday's last commit.
May 13 03:54:13 <holtmann> Also connman-0.17 is not syncing up either. So seems the kernel.org mirrors are having a problem.
May 13 03:54:47 <holtmann> Europe's servers are borked: git.us.kernel.org works.
May 13 03:56:31 <denkenz> Hmm, yes funny
May 13 03:57:08 <holtmann> Seems the mirror scripts are stuck.
May 13 03:57:16 <holtmann> Happens from time to time.
May 13 04:08:50 <holtmann> denkenz: I am stuck between chairs until git.kernel.org syncs again. Any other pending patches I should push?
May 13 04:09:11 <denkenz> No, I have one other I'm reviewing from Andrew
May 13 04:09:20 <denkenz> but I'm on semi-holiday for rest of the week
May 13 04:09:36 <holtmann> Lucky you.
May 13 05:42:31 <PaulFertser> holtmann: Hi there :) , have a minute to answer several simple questions?
May 13 05:43:05 <PaulFertser> holtmann: first: Is it your absulute intent to prohibit any proprietary components between kernel interfaces and oFono?
May 13 05:45:17 <holtmann> Sure.
May 13 05:45:48 <holtmann> The idea is to have all the code that runs inside ofonod process context open source.
May 13 05:46:02 <holtmann> That is just a pure stability point of view and we are using the GPL to enforce it.
May 13 05:46:28 <PaulFertser> holtmann: "process context" sounds a bit scary, i can imagine a separate daemon talking to the modem via some proprietary interface communicating with oFono via a socket...
May 13 05:46:31 <holtmann> It is just way to hard to debug binary only plugins and will not allow us to modify the API if we limited ourself in some way.
May 13 05:47:10 <holtmann> So in theory you can write a GPL and open source plugin for oFono that then talks to a proprietary modem daemon.
May 13 05:47:23 <holtmann> Over some sort of IPC, unix sockets, D-Bus or whatever.
May 13 05:48:00 <holtmann> We encourage and support open source modem plugins within oFono.
May 13 05:48:22 <holtmann> It is an open source and community project after all.
May 13 05:48:24 <PaulFertser> holtmann: I understand you can't legally enforce it but will you complain really loud if one decided to do that (proprietary ipc-separated stuff)? (like HTC did with android "RIL")
May 13 05:49:15 <PaulFertser> Because android guy didn't complain.
May 13 05:49:21 <PaulFertser> s/guy/guys/
May 13 05:50:09 <holtmann> For me this is fine. If someone wants to go through the complex part in defining an IPC and then running another daemon for modem hardware access. Be my guest.
May 13 05:50:37 <holtmann> We will of course not optimize oFono for this use case. We care about open source modem plugins. They get our attention.
May 13 05:51:58 <holtmann> Most modem interfaces are just closed source because companies think they have some IP to protect. In the end they will realize there is no IP to protect.
May 13 05:52:51 <holtmann> So we encourage open source modem drivers and will support them actively and optimize for them. The closed source modem interfaces have to pay the penalty to go via an extra IPC layer.
May 13 05:52:55 <holtmann> It is as simple as that.
May 13 05:52:57 <PaulFertser> And another question: preface: you might not be aware of pyneod effort but you certainly know about FSO. I can't understand how you can find it ethical to prepare a competing project under the covers on the basis that FSO-api is too low level (which is not exactly true, FSO has both "GSM" layer API and "Phone" layer API which should support even VoIP) and generally "shit" (which is simply unjustified). How come you never dropped around #openmoko-cdevel
May 13 05:53:03 <PaulFertser> ... smartphones-standards MLs to help FSO devs improve their API? Do you think they're really committed to doing "shit"? What bothers me is that you didn't even try to collaborate and just prepared a competing project _undercover_.
May 13 05:54:23 <holtmann> I mentioned it a couple of times that D-Bus API can't be designed like C-APIs and that following the ETSI AT command spec almost literal just makes no sense.
May 13 05:54:53 <PaulFertser> FSO includes higher-level APIs too...
May 13 05:57:15 <holtmann> Of course they do, but my argument still holds. We talked about FSO a lot and decided that we want to design all APIs from scratch.
May 13 05:58:03 <PaulFertser> holtmann: Can you understand that preparing a competing project in a way like this should be somehow more justified and some random general remarks is not enough? I guess you've already seen a post in Harald Welte's blog: http://laforge.gnumonks.org/weblog/ . He talks about companies, but i'm talking about you personally. If you prepared some document comparing your proposed API and FSO, well, it'd look ok. But you didn't, nobody did... And you haven't
May 13 05:58:10 <PaulFertser> ... talked about FSO with the FSO team, you gave them no chance to improve (as i see it, i might be wrong).
May 13 05:58:15 <holtmann> I admit that I learned about pyneod only yesterday. To my defense, I never really look into daemons written in Python.
May 13 06:00:49 <holtmann> Let me put this really simple. We talked about it and we looked at various projects around telephony (including some of these driven by consortium).
May 13 06:01:25 <PaulFertser> holtmann: And here "we" being the team you work with undercovers?
May 13 06:01:39 <holtmann> We did write our own prototype for our ideas that we had as a proof of concept. And we decided to team up with Nokia and create an open source project around it. It is pretty much as simple as that.
May 13 06:02:35 <holtmann> We as in Intel work on various projects, proof of concepts and play with a lot of ideas. Some of these never see the day of light. Others do.
May 13 06:03:00 <holtmann> I personally believe in having more variation and choices is a good thing.
May 13 06:05:23 <PaulFertser> holtmann: (more choices) Not always, you perfectly know that. Standardization sometimes is really great thing. Not always, but so is diversity is not always a great thing. Marcel, i can't express my concerns better than Harald did; i can't see you answering to points he raised :(
May 13 06:08:57 <holtmann> Then let me try again. We are envisioning a complete different D-Bus driven API. I mentioned that before and turning an existing API upside down seem not reasonable.
May 13 06:09:49 <holtmann> One additional reason not to contribute or engage with FSO was simply on a source code base issue. We didn't wanna use a GObject based approach.
May 13 06:12:09 <holtmann> We also plan to support non-AT command based modems like Nokia PhoNet. FSO is heavily based around serial ports and AT modems.
May 13 06:15:44 <PaulFertser> holtmann: that's a good enough for a reason (though FSO aims at compatibility with any modems, not only AT and not only modems, VoIP too). Problem is the lack of publicity from your side. Without clearly expressing why you decided to not collaborate with FSO you present yourself to the general public as some guy engaging in an unfair competition (being backed up by really powerful players). Nowhere in your announcement FSO is even mentioned. Try to ...
May 13 06:15:50 <PaulFertser> ... imagine yourself an FSO dev for a moment to understand how your announcement looks from their POV please.
May 13 06:18:11 <holtmann> I can see that point to some degree. However we are releasing all our source code under GPL and we are trying to be open about almost everything when it comes to our open source projects.
May 13 06:20:17 <holtmann> I agree that companies like Intel and Nokia sometimes can put more manpower behind projects, but with every big corporate company we have to also justify why we put resources on various project. It is an ongoing effort with many projects.
May 13 06:20:43 <PaulFertser> holtmann: well, you prefer talking about open source, i'm talking about free software... Qtopia was/is open source too. And Android. Technically it's even free software mostly but development model is nowhere near free.
May 13 06:21:10 <PaulFertser> holtmann: Well, i guess that's enough for an interview.
May 13 06:21:26 <PaulFertser> holtmann: Thanks for your time. :)
May 13 06:21:34 <holtmann> Anytime.
May 13 06:28:32 <mudyc> holtmann: how many gdbus libraries are you going to write?-) there's at least two: one inside ofono/gdbus and libgdbus 
May 13 06:28:58 <holtmann> They are all the same.
May 13 06:29:53 <holtmann> Just need to free up some time to get libgdbus patches that are queued up and merged. Then we can all switch. With now four projects using it (a 5th is in the making) it makes sense to split it out.
May 13 06:30:06 <holtmann> For development purposes it is nice though to have it inside the repo :)
May 13 06:30:56 <mudyc> yeah sure
May 13 06:45:53 <mudyc> git-submodule is good for that
May 13 06:49:47 <holtmann> I dislike all this submodule concepts. I have seen it with bzr and personally I hate it.
May 13 06:53:12 <DieMumiee> is ofono already useable on the neo?
May 13 06:54:07 <holtmann> DieMumiee: You need to ask denkenz about details here. I think he did basic testing with a Neo.
May 13 06:54:18 <DieMumiee> holtmann: btw, i really happy to see that somebody write a phone daemon in a language like c
May 13 06:54:25 <DieMumiee> +am
May 13 06:54:29 <DieMumiee> ok
May 13 06:54:54 <holtmann> What can I say. Some of us like kernel style coding :)
May 13 06:55:08 <DieMumiee> (c++ would have been fine too)
May 13 06:55:45 <holtmann> Not for me. I can't wrap my mind around it. But that is me.
May 13 06:59:01 <DieMumiee> what other modems are supported by now?
May 13 06:59:17 <DieMumiee> i also have a samsung netbook with a builtin umts modem.
May 13 07:00:09 <holtmann> Currently only basic atmodem driver.
May 13 07:07:30 <bernt> DieMumiee: One thing missing, is the sending of sim-PIN, so perhaps you should try it with a sim  without pin. 
May 13 07:19:03 <DieMumiee> hm i could send the pin manually before starting the daemon?
May 13 07:20:02 <holtmann> Yes, you could.
May 13 07:37:51 <holtmann> We merged our oFono Handsfree telephony driver plugin for BlueZ into upstream bluez.git.
May 13 07:57:59 <akiniemi> PaulFertser: a side comment about FSO, it seems they're also aiming to build something more high-level with the o.fs.Phone
May 13 07:58:21 <akiniemi> That to me looks like duplication of effort compared to Telepathy
May 13 08:03:25 <PaulFertser> akiniemi: i'm not the one to judge about technical advantages/disadvantages. All my questions were about free software and ethics basically and to be honest i don't think i received all the real answers (except probably that ofono devs care about open source more than free software). And as a matter of fact, it's perfectly possible that Telepathy will be integrated in FSO instead of o.fs.Phone.
May 13 08:08:23 <holtmann> akiniemi: Now it is your turn to answer questions. I am going to get some sleep :)
May 13 08:08:34 <akiniemi> PaulFertser: my point is we never intended to grow beyond providing access to cellular, using any modem interface not just AT commands
May 13 08:09:14 <PaulFertser> akiniemi: so is FSO interfaces not limited to AT commands.
May 13 08:09:17 <akiniemi> holtmann: it's cool we have representation in so many TZs ;)
May 13 08:09:21 <PaulFertser> holtmann: n8
May 13 08:12:20 <PaulFertser> akiniemi: and btw talking about how your api is superior because it'll let some GUI coders to make apps more fancier/animated/colourful/addictive/whatever looks more like a marketing bs. Animated apps, omg what are you talking about? Do you think sane people like all that stupid animation on dumb cell phones that just makes interactive interfaces slower?
May 13 08:12:40 <akiniemi> PaulFertser: no, they seem to be very much oriented towards AT commands
May 13 08:13:19 <akiniemi> PaulFertser: all we're saying is that the developer does not and need not understand GSM to build an app using oFono
May 13 08:13:33 <PaulFertser> akiniemi: (at commands) if you sent one sample of any other modem to FSO devs, it'd change fast.
May 13 08:14:47 <PaulFertser> akiniemi: btw, you saw some deficiency in the API (like too AT-oriented interfaces). Well, could you please post a link to a datasheet describing another type of modem interface to smartphones-standards e.g. or here or whereever to give FSO chance to improve?
May 13 08:14:55 <akiniemi> PaulFertser: maybe, but as these things go, it is not easy to reverse initial designs if you're proposal is to change everything
May 13 08:14:58 <PaulFertser> It's much easier than giving a sample.
May 13 08:15:40 <PaulFertser> akiniemi: really, datasheets for other modems in use are appreciated.
May 13 08:16:27 <akiniemi> PaulFertser: I am assuming users of FSO would do that if they wanted that support
May 13 08:16:43 <PaulFertser> akiniemi: and btw you're talking about technical implications of the APIs again, i was talking about lack of publicity...
May 13 08:17:24 <PaulFertser> akiniemi: Is the datasheet for the non-AT modem you're talking about publicly available?
May 13 08:18:04 <akiniemi> PaulFertser: publicity is always a sensitive business with big companies. We're trying our best to be public early on, but it's not especially easy :)
May 13 08:19:17 <iscape_b> are you planning to support one of the currently available 3G usb sticks?
May 13 08:19:49 <akiniemi> PaulFertser: you could take a look at PhoNet documentation in the linux kernel
May 13 08:21:06 <PaulFertser> akiniemi: Look, Harald Welte is not some random person. And he wrote a blog post with all those concerns. Much better worded than i'm talking here. He has some real concerns, he tells about what and how he sees your project from the outside. That's what i'm talking about. You should have done everything beforehand so that a post like that wouldn't exist. 
May 13 08:21:20 <PaulFertser> akiniemi: bad substitute for a datasheet :-/
May 13 08:21:50 <akiniemi> PaulFertser: his entitled to his opinion, I have also a lot of respect for him
May 13 08:22:17 <akiniemi> PaulFertser: but I also belive in letting all flowers bloom, and letting the market decide ;)
May 13 08:22:19 <PaulFertser> akiniemi: his opinion is justified by your (ofone project) actions. It's not an accident, you know.
May 13 08:22:47 <PaulFertser> Market? It's business stuff, not ethics or technical even.
May 13 08:22:58 <iscape_b> well, I wouldn't touch FSO#
May 13 08:23:29 <akiniemi> PaulFertser: when I say market, I mean developers out there. I'm a developer not a business person.
May 13 08:23:35 <iscape_b> harald is a low level specialist btw.
May 13 08:24:51 <akiniemi> iscape_b: there's AT modem support in oFono, which I belive most USB sticks are using. We're welcoming patches for enabling any modem out there. ;)
May 13 08:25:22 <iscape_b> akiniemi: the usb sticks usually come with a second interface for the network
May 13 08:25:35 <iscape_b> so on serial for the AT and the second for data
May 13 08:25:39 <iscape_b> one*
May 13 08:26:19 <akiniemi> iscape_b: yeah, or one serial for control (AT commands) and a real network iface for data
May 13 08:26:29 <iscape_b> I'll have a look but time is always scarce
May 13 08:27:15 <iscape_b> akiniemi: probably a faq: when will you have more doc (except reading sources)?
May 13 08:27:23 <akiniemi> BTW, we're missing the GPRS control from the plugin API...
May 13 08:27:58 <akiniemi> iscape_b: Marcel should have those queued up, so Real Soon Now
May 13 08:30:06 <iscape_b> in any case, imho ofono is a really good concept. do one thing and do it right
May 13 08:30:23 <iscape_b> i never liked this integration of everything into fso
May 13 08:41:16 <bernt> do one thing and do it right and do not use to much memory and other resources for this.
May 13 08:42:38 <iscape_b> yep, C is a better choice than python
May 13 08:43:40 <PaulFertser> iscape_b: the reimplementation of FSO in Vala is ongoing fyi
May 13 08:44:05 <iscape_b> i know
May 13 08:44:26 <iscape_b> and Vala is on low level stuff a bad choice too
May 13 08:45:41 <iscape_b> PaulFertser: btw you have given yourself the answer to harald's blog post
May 13 08:46:29 <PaulFertser> iscape_b: Uhm? Could you please rephrase it, i might have missed that :)
May 13 08:49:06 <iscape_b> PaulFertser:  "reimplementation" is a euphemism for starting from scratch again
May 13 08:50:33 <iscape_b> in a language that currently has way less mindshare than C
May 13 08:51:34 <PaulFertser> iscape_b: not really, experience adds up. Python reference implementation is a good way to evaluate API. Vala rewrite will be mostly compatible, the API proved to be good enough.
May 13 08:53:19 <iscape_b> in a language that currently has way less mindshare than Python because it is good for evaluation :p
May 13 08:53:45 <iscape_b> oops
May 13 08:53:46 <iscape_b> in a language that currently has way less mindshare than Python because it is good for evaluation :p
May 13 08:53:58 <iscape_b> sorry
May 13 08:54:09 <iscape_b> PaulFertser: this is marketing talk :) - I start to believe it once Linus starts developing new stuff in python
May 13 08:58:16 <PaulFertser> iscape_b: you got me wrong. When FSO started there wasn't so much interest in Vala and Vala itself wasn't really ready. Mickey have a big experience developing python stuff so he decided to do it that way (also he was largely influenced by pyneo). Now we have a working implementation of API and consumers and consumers are mostly happy with the API. So rewrite in Vala that will also address most shortcomings of current implementation is a natural step.
May 13 09:02:37 <emdete> PaulFertser: where do you get this "consumers are mostly happy with the api"? i here mostly critics. point is that fso has earnest performance problems which is the cause for the vala reimplementation as far as i understood mickey
May 13 09:06:18 <PaulFertser> emdete: the fact is i see SHR guys every day and they like the API. Mirko (Paroli) also has no real complains. Of course i'm biased just because i hang around on their channel, but still... No doubt i know you don't like FSO api and probably SHR devs just never saw a better alternative, i don't say API is good, i say that consumers are ok with it which seem to reflect the reality.
May 13 09:06:42 <htalvitie> hi, any Finnish speaking domain experts here? i'm looking for peer review to my news story, and since I'm _not_ a expert on matter I'd like to have a 2nd (3rd..) opinion.
May 13 09:08:06 <htalvitie> for interested: a working copy is fully editable at http://etherpad.com/hQN0mmpsJq
May 13 09:11:05 <emdete> PaulFertser: i have contacts with other foss developer that don't like this quite gsm near design
May 13 09:11:38 <PaulFertser> emdete: too bad they didn't express it on smartphones-userland ML
May 13 09:12:44 <emdete> PaulFertser: i would not expect, that discussion would change anything there. i tried ;)
May 13 09:13:30 <emdete> PaulFertser: i discussed in person with the fso-head and not on the list. i did that /before/ any code took place. don't think fso lets people discuss
May 13 09:13:45 <emdete> PaulFertser: influence is not wanted at fso ;)
May 13 09:14:06 <iscape_b> i fully ack emdete's statement
May 13 09:14:51 <PaulFertser> emdete: That's your POV and i respect it. OTOH i'd like to see an attempt to discuss those things on some public mailing list.
May 13 09:15:24 <tuukkah> htalvitie, i can take a look at least
May 13 09:16:12 <htalvitie> tuukkah, thanks. 
May 13 09:16:18 <emdete> PaulFertser: i'm out of resources for that. i think ofono is the chance to do that
May 13 09:18:12 <htalvitie> I have some basic definition problems, e.g. is it "oFono" or "Ofono.org". Both names exist: "oFono.org is a place..", "oFono.org is licensed under GPLv2, and it includes a high-level D-Bus API", "oFono aims to provide an easy to use interface..".. ?
May 13 09:18:29 <PaulFertser> emdete: no, ofono is the chance to split developers even further as i see it atm.
May 13 09:19:19 <holtmann> htalvitie: In written text about the project it is oFono. References to the domain name are ofono.org.
May 13 09:19:57 <holtmann> htalvitie: The project name is oFono. Everything else is just the domain name :)
May 13 09:20:21 <emdete> PaulFertser: maybe we can merge pyneo with ofono...
May 13 09:22:14 <PaulFertser> emdete: do you like the API proposed by ofono btw?
May 13 09:24:10 <emdete> PaulFertser: i haven't had the time to dive deep into it. but what i have read so far sounded promising.
May 13 09:24:59 <htalvitie> holtmann: ok, wasn't sure if this is one of those "openoffice.org" -type names :)
May 13 11:08:05 <htalvitie> thanks to tuukkah et al for help. the story is now at http://www.tietoviikko.fi/kehittaja/article286138.ece
May 13 11:10:19 <akiniemi> htalvitie: nice ;) one correction though, oFono is using technologies common with Maemo (such as D-Bu, which is a common linux desktop standard)...
May 13 11:10:36 <akiniemi> s/D-Bu/D-Bus
May 13 11:11:27 <akiniemi> htalvitie: common with, not coming from like the article seems to suggest
May 13 11:12:36 <josch> *which ist a freedesktop.org standard as used on linux desktops
May 13 11:12:51 <josch> there is no "linux standard"
May 13 11:13:49 <akiniemi> josch: okay, should've said "standard used commonly in the linux desktop" ;)
May 13 11:14:41 <akiniemi> josch: if you agree there is such a thing as linux desktop? :)
May 13 11:17:21 <josch> :P
May 13 11:20:05 <PaulFertser> GNU/Linux
May 13 11:20:26 <josch> i just refrained myself from adding that :D
May 13 11:22:43 <PaulFertser> As as side note, this chan really showed me "opensource" mindset in action.
May 13 11:49:22 <_rmz_> http://www.dn.no/karriere/article1668765.ece
May 13 11:49:24 <_rmz_> *fnis*
May 13 11:51:01 <_rmz_> "vi bryter loven, men det synes vi er greit, for vi er så flinke at vi bør få lov til det" ;-)
May 13 11:51:25 <htalvitie> akiniemi: thanks for the correction. if you mind, could you change the wording in the original text - it's here freely editable: http://etherpad.com/Idqb3IXvDF
May 13 11:51:32 <_rmz_> eventuelt "arbeidstidbestemmelser er for dem som ikke var så flinke på skolen, har unger og familie og andre lite yrkesvennlige trekk"
May 13 11:51:49 <_rmz_> Sorry, wrong channel
May 13 11:51:55 * _rmz_ blushes
May 13 16:55:50 <holtmann> http://lwn.net/Articles/333059/
May 13 16:56:13 <holtmann> For all you guys that care about PIM storage and synchronization.
May 13 17:02:00 <XorA> nice
May 13 17:02:18 <XorA> although the comment is valid, we need a decent server for the other end of the link :-)
May 13 17:03:19 <holtmann> Of course you do, but we have to start somewhere.
May 13 17:08:30 <XorA> congrats on your new project BTW
May 13 17:08:46 <XorA> hoping you bring the same coolness to GSM you did to wifi with connman
May 13 19:20:25 <jorma_> so. how does ofono relate to the stuff available @ openmoko and freesmartphone?
May 13 19:20:35 <jorma_> gsmd stuff
May 13 19:24:31 <jorma_> hmm. ok. http://logs.nslu2-linux.org/livelogs/ofono.txt
May 13 19:59:24 <DarKnesS_WolF> ./configure: line 11307: syntax error near unexpected token `GTHREAD,'
May 13 19:59:25 <DarKnesS_WolF> ./configure: line 11307: `	PKG_CHECK_MODULES(GTHREAD, gthread-2.0 >= 2.16, dummy=yes,'
May 13 19:59:35 <DarKnesS_WolF> problem with compiling under ubuntu 9.04
May 13 20:00:19 <DarKnesS_WolF> actually that is after i did comment the line of glibc so this error will appers many times i think 
May 13 20:00:26 <DarKnesS_WolF> this from latest git snapshot
May 13 20:02:34 <DarKnesS_WolF> ./configure: line 11297: syntax error near unexpected token `GLIB,'
May 13 20:02:34 <DarKnesS_WolF> ./configure: line 11297: `PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.16, dummy=yes,'
May 13 20:15:24 <DarKnesS_WolF> ok gtg now , catch up later
May 13 22:10:11 <emdete> holtmann: pyneo now has dbus xml descriptions: http://pyneo.org/downloads/dbus_api_xml/ - let me know if you have any questions. 
May 13 22:19:21 <denkenz> emdete: Your API is somewhat similar, however compared to oFono it is still too procedural
May 13 22:19:40 <emdete> denkenz: 'too procedural'? where?
May 13 22:20:08 <denkenz> emdete: e.g. ListAll, SetForward
May 13 22:20:32 <emdete> denkenz: how would that be better? how is tht in ofono?
May 13 22:20:52 <denkenz> emdete: Just about everything is a Property in oFono
May 13 22:21:24 <denkenz> emdete: Have you been able to glimpse at our APIs yet?
May 13 22:21:27 <emdete> so how do you get all sms?
May 13 22:21:47 <emdete> denkenz: i did not find any docu but the big image on the web site
May 13 22:22:51 <denkenz> emdete: Ok, we actually do have API docs, they just got 'lost' during migration
May 13 22:22:53 <emdete> denkenz: do you have a link?
May 13 22:23:14 <denkenz> emdete: Let us work on getting those upstream again
May 13 22:24:11 <denkenz> emdete: Overall your API is way better than FSO :)
May 13 22:24:20 <emdete> denkenz: so the other end of "procedural" would be what?
May 13 22:25:13 <emdete> denkenz: thanks - i had a long diskussion with the fso guy mickey before any code of fso exist to work together but he insisted on his api
May 13 22:26:38 <emdete> denkenz: so is ofono object oriented? 
May 13 22:26:41 <denkenz> emdete: For an example of what I mean, look in connman/bluez docs
May 13 22:26:49 <denkenz> emdete: We follow the same pattern
May 13 22:26:56 <emdete> give me a link...
May 13 22:27:24 <denkenz> http://git.kernel.org/?p=bluetooth/bluez.git;a=tree;f=doc;h=8fa94110b8819b43182dc779216acf9adb970e05;hb=HEAD
May 13 22:29:26 <emdete> denkenz: hm, you have no getter/setter but one with a name of the property - is it that?
May 13 22:30:50 <denkenz> Most interesting things are done with SetProperty/GetProperties and being more object oriented
May 13 22:31:07 <emdete> denkenz: why ist that oo? :D
May 13 22:31:44 <tuukkah> emdete, nice docs :-) just an additional suggestion: you could also cat them together into an "All.xml"
May 13 22:31:55 <denkenz> That in itself is not, how we break up objects / properties is though
May 13 22:32:25 <denkenz> Again, pyneo is a much closer in spirit to ofono than FSO
May 13 22:32:30 <emdete> tuukkah: hey, that's the first throw after some patches in the dbus bindings - i'm happy i'm that far! :D but sure, i can do that
May 13 22:33:01 <emdete> denkenz: pyneo's most important idea is to reuse interfaces.
May 13 22:33:20 <denkenz> Reuse interfaces?
May 13 22:34:21 <emdete> interfaces in pyneo are more capabilities of objects. see Powered. or Timeprovider
May 13 22:34:58 <emdete> so gps, gsm, bt, whatever are Powered - you can switch them off and on. even the phone is - switching it off issues a shutdown
May 13 22:35:37 <emdete> denkenz: does ofono have interests in working together?
May 13 22:36:04 <tuukkah> emdete, your GetStatus is a bit like GetProperties, no?
May 13 22:36:22 <denkenz> emdete: We're not aiming to provide access to things like Bluetooth -> Theres BlueZ for that
May 13 22:36:38 <denkenz> emdete: We stay focused on GSM
May 13 22:36:38 <emdete> tuukkah: :D yes 
May 13 22:37:16 <tuukkah> so part of pyneo could be aligned with ofono, but not all
May 13 22:37:19 <emdete> denkenz: i know. i like the idea of a similar design for all objects - that makes it simpler for a developer. that's the cause i wrapped bt
May 13 22:39:05 <denkenz> emdete: Yep, that's what we're trying to accomplish.  Once you know one interface, you pretty much know them all
May 13 22:39:08 <emdete> tuukkah: http://pyneo.org/downloads/dbus_api_xml/All.xml does not work with a cat >> :D
May 13 22:39:18 <emdete> denkenz: exactly
May 13 22:40:48 <emdete> tuukkah: so give me some time to put that in a valid xml..
May 13 22:42:15 <tuukkah> emdete, oops sorry... you could rename it to All.txt =)
May 13 22:42:24 <emdete> :D
May 13 22:42:30 <emdete> good idea
May 13 22:43:32 <emdete> tuukkah: done
May 13 22:45:12 <tuukkah> emdete, thanks
May 13 22:45:12 <denkenz> emdete: Anyway, we definitely welcome any feedback, ideas, patches.  Just remember, the core is going to be written in C, with minimal dependecies
May 13 22:45:45 <emdete> denkenz: i know. i like that.
May 13 22:46:57 <emdete> tuukkah: i incorporated the doc from python, i don't know if that breaks something but i did not want to invent a namespace, what do you think?
May 13 22:49:50 <tuukkah> really nice. i don't really care about the xml format. i suppose it doesn't validate against the dtd anymore, but i don't think even any code cares
May 13 22:50:26 <emdete> tuukkah: the daemons run in py -OO, optimized which throws out the doc anyway
May 13 22:51:07 <tuukkah> hmm, the dtd has something called annotation
May 13 22:52:38 <emdete> yes, saw that, butsomething was with it... its only at the interface? don't remember...
May 13 22:53:22 <tuukkah> it's an empty element, and has attributes name and value :-/
May 13 22:53:47 <tuukkah> so you would have <annotation name="doc" value="..."> ... ugly
May 13 22:54:16 <emdete> hm. i leave that for now, maybe the dbus binding guys have an idea - i send the patches to the mailing list.
May 13 22:54:23 <tuukkah> indeed. let's not care :-)
May 13 22:54:55 <emdete> yes. i only care for the bed now ;) see you tomorrow...
May 13 22:54:57 <tuukkah> good idea to push this up to them
May 13 22:55:10 <tuukkah> 'night!
May 13 22:55:16 <emdete> tuukkah: i hope the put it in, always patching a local installation is ... :/
May 13 22:56:09 <tuukkah> this would make d-feet so much more useful as well
May 13 22:57:32 <tuukkah> (browsing and calling methods via it can be a bit difficult if you can't guess what the methods and arguments mean)
May 14 02:03:11 <denkenz> holtmann: In the current build setup it seems both plugins/ and drivers/ have a libbuiltin
May 14 02:03:28 <holtmann> denkenz: Yes, they do.
May 14 02:03:31 <denkenz> holtmann: Won't they clash?
May 14 02:03:49 <holtmann> No. These are just two libs that are statically linked into ofonod.
May 14 02:04:04 <holtmann> The name of the lib is irrelevant.
May 14 02:05:49 <denkenz> Btw, any reason why both atmodem and phonet are builtins?
May 14 02:20:51 <holtmann> It is better for debugging via valgrind and gdb. Sometimes these get confused with plugins.
May 14 02:21:04 <holtmann> We had that problem in BlueZ already.
May 14 02:39:35 <denkenz> Ah, you can always add an #ifndef MAINTAINER_MODE to dlclose
May 14 02:39:53 <denkenz> I think having both always loaded might not be terribly efficient
May 14 02:58:01 <holtmann> I will fix autoconf to make it a configure option. Just too lazy right now :)
May 14 02:58:25 <holtmann> ConnMan has something like --enable-wifi=<plugin|builtin>
May 14 02:59:42 <holtmann> It is also not only about dlclose btw. we played with disabling the unloading. Most confused is valgrind btw. Don't ask me why and how, I am not a low-level asm expert.
**** ENDING LOGGING AT Thu May 14 02:59:57 2009

**** BEGIN LOGGING AT Thu May 14 02:59:57 2009
May 14 08:39:59 <Eren> hello
May 14 08:41:41 <Eren> as far as I understand from the schema provided in the website that oFono will be language-independent as it will provide just DBUS and we (as humans :P) will be able to use it via PyDbus etc..
May 14 10:19:46 <akiniemi> Eren: yes, and we also try hard to make the interfaces usable without specific language bindings.
May 14 12:13:25 <iscape_b> is there any hardware you are running the ofono stack on?
May 14 12:14:07 <iscape_b> have you i.e. tried it on the openmoko neo?
May 14 12:15:12 <neomilium> iscape_b: did you think about use it in H:1 ?
May 14 12:15:20 <neomilium> ;)
May 14 12:15:45 <iscape_b> earlier or later yes
May 14 12:15:49 <iscape_b> :)
May 14 12:16:45 <iscape_b> and i have a beagleboard sitting here - together with a 3G usb stick
May 14 12:17:21 <neomilium> iscape_b: have you ever tried to use FSO in H:1 ?
May 14 12:17:38 <neomilium> even just for fun ?
May 14 12:17:51 <iscape_b> yes, but was not fun :(
May 14 12:18:25 <neomilium> what was the main reason ?
May 14 12:19:21 <iscape_b> for performance and memory reasons everything is in one big python script
May 14 12:20:37 <iscape_b> gsm, gps, pim
May 14 12:22:57 <emdete> iscape_b: fso does not use any modules anymore?
May 14 12:23:30 <iscape_b> s/one big script/one big app/
May 14 12:27:04 <emdete> iscape_b: whats the problem with 'one process'?
May 14 12:27:28 <iscape_b> eierlegendewollmilchsau
May 14 12:28:09 <neomilium> emdete: I think that's not the 'one process' problem but BIG python one process
May 14 12:28:26 <emdete> iscape_b: :D
May 14 12:28:31 <iscape_b> it is a one process problem too
May 14 12:28:36 <emdete> neomilium: py == big ?
May 14 12:29:20 <iscape_b> gps and gsm have nothing to do with each other
May 14 12:30:07 <emdete> iscape_b: no?
May 14 12:30:33 <iscape_b> imho the unix philosophy of doing one thing well is the big strenght of open source (floss if you are religious) over windows
May 14 12:31:22 <iscape_b> i remember the times on window when you installed a printer and all your fonts went away
May 14 12:33:16 <emdete> iscape_b: exaclty as py works internally. if you modularize better than fso, you have that model inside py too. so no problem with taht for me
May 14 12:34:38 <emdete> iscape_b: pyneo (my project with similar scope) does the one-process for all too. if you have enough ram, each plugin can run standalone but you dont want that. systems like py, java, whatever dont share modules as shared libs do, thahts the problem
May 14 12:35:01 <emdete> iscape_b: problem with fso is, that the module structure is crap
May 14 12:35:16 <fgau> ;)
May 14 12:37:01 <fgau> gsm can be a location provider like gps too, why they have nothing to do with each other?
May 14 12:38:39 <neomilium> fgau: I agree then we could use one GSM handler, one GPS handle, one location provider (that use GSM and/or GPS stack)...
May 14 12:38:59 <neomilium> but not one big thing for all...
May 14 12:41:54 <emdete> neomilium: thats a different discussion, the dbus arch and the processes... have you read about pyneos arch?
May 14 12:42:50 <emdete> neomilium: it's important to leave the low-level elements behind. nobody is interested if its gsm or voip or whatever. in the end you want to do a voice call
May 14 12:43:38 <emdete> so you have different providers for a service with attributes, like accuracy for location or costs for phone calls. this is what makes it possible to choose 
May 14 12:44:06 <neomilium> emdete: im agree
May 14 12:44:51 <emdete> neomilium: what do u think of pyneo?
May 14 17:31:23 <akiniemi> holtmann: hmm, actually might make more sense to name the driver isimodem and have a phonet directory at the same level as gatchat
May 14 17:43:00 <holtmann> akiniemi: Depends on how much you have inside phonet. I only the the Gnokii code for phonet.
May 14 17:43:30 <Tm_T> Mirv: I knew you made it faster than me (:
May 14 17:50:43 <akiniemi> holtmann: it should have an API for sending ISI messages, and receiving responses to those; as well as subscribing to indications.
May 14 17:51:34 <holtmann> akiniemi: So in general something like libphonet could be useful for other applications outside oFono.
May 14 17:52:44 <akiniemi> holtmann: Yes, sure. 
May 14 17:53:32 <holtmann> akiniemi: Then I agree that it should get its own directory like gatchat since in the end we might split them out. For now and for simplicity I keep these deps inside the project.
May 14 17:54:00 <holtmann> akiniemi: My only requirement would be that libphonet or better libgphonet nicely integrates with GLib mainloop.
May 14 17:54:13 <holtmann> Similar to what gatchat does.
May 14 17:54:54 <holtmann> Does libphonet would require a kernel with PhoNet support?
May 14 17:54:55 <akiniemi> Right.
May 14 17:55:20 <akiniemi> Yes.
May 14 17:55:43 <holtmann> So what does libphonet would do that can't be done by the kernel with simple socket calls.
May 14 17:56:04 <akiniemi> Nothing ;)
May 14 17:56:12 <holtmann> Then why do we need it?
May 14 17:56:27 <holtmann> Besides the GIOChannel wrapping I guess.
May 14 17:56:29 <akiniemi> I would rather call it libisi, actually
May 14 17:57:05 <holtmann> Then libgisi it is :)
May 14 17:57:37 <akiniemi> :)
May 14 17:58:28 <holtmann> So question is when do you have that code for us :)
May 14 17:58:48 <akiniemi> soon... ;)
May 14 17:58:54 <denkenz> That reminds me, can we get some HW too? :)
May 14 17:59:56 * akiniemi checks the gadget cabinet
May 14 18:00:10 <akiniemi> denkenz: sorry, we're all out ;)
May 14 18:00:16 <denkenz> Damn ;)
May 14 18:01:21 <holtmann> denkenz: Once we have a USB PhoNet driver, I think that I just have to make sure that we have a least one of the latest Nokia phones.
May 14 18:02:11 <holtmann> akiniemi: What does ISI actually stands for. I think you mentioned it, but I forgot.
May 14 18:03:33 <denkenz> holtmann: Nod, most of the interesting stuff happens in the core, so we need one for debugging
May 14 18:04:04 <holtmann> I think that I want the N97 :)
May 14 18:04:37 <denkenz> Hehe
May 14 18:05:02 <denkenz> akiniemi: Can things like N97 also talk AT commands?
May 14 18:05:56 <holtmann> denkenz: This reminds me that we have to get some modem emulation for the Bluetooth/USB profile details.
May 14 18:06:28 <denkenz> holtmann: Yep, once you release phonesim we can actually test HFP
May 14 18:06:32 <holtmann> We should not rely on any modem firmware to do the right job here. Don't wanna expose quirks. We should implement the AT correctly.
May 14 18:06:53 <denkenz> holtmann: Ok, sorry you lost me
May 14 18:07:09 <holtmann> denkenz: Question on that one. How much changes did you do to phonesim.
May 14 18:07:27 <akiniemi> holtmann: Intelligent Service Interface
May 14 18:07:30 <denkenz> holtmann: Ehh, I'd say < 30 loc
May 14 18:07:50 <denkenz> hotlmann: However, I heavily customized the .xml file
May 14 18:07:52 <holtmann> We could have hardware that doesn't have any AT command access. So we have to export an AT set.
May 14 18:08:13 <denkenz> holtmann: Doesn't the HFP implementation already do this?
May 14 18:08:29 <holtmann> Yes it does, but what about DUN.
May 14 18:08:35 <holtmann> Or SPP.
May 14 18:08:48 <holtmann> Or the USB ACM.
May 14 18:08:53 <akiniemi> denkenz: dunno, but most do enough for the ACM part
May 14 18:09:01 <denkenz> holtmann: ACM?
May 14 18:09:20 <holtmann> TTY for USB in simple word. Spec. is a little bit more nasty.
May 14 18:09:31 <holtmann> Abstract Control Model if I remember correctly.
May 14 18:09:50 <akiniemi> used for dial-up
May 14 18:09:52 <denkenz> holtmann: Not familiar with it, spec?
May 14 18:10:07 <holtmann> usb.org or some usb-acm driver in the kernel.
May 14 18:10:26 <denkenz> holtmann: Also, for DUN we need to discuss how we're doing GPRS/3G Data
May 14 18:10:57 <holtmann> Full DUN has to do PPP, because that is what the spec. says.
May 14 18:11:01 <denkenz> holtmann: IMO we also need to separate out the BlueZ HFP into a generic modem emulator project on top of oFono
May 14 18:11:17 <holtmann> However we can just do PAN via ConnMan. And if USB, then CDC-Ether.
May 14 18:11:41 <holtmann> Just have it run DHCP so just an initial PDP config needs to be done.
May 14 18:12:20 <denkenz> holtmann: You're talking pseudo-DUN :)
May 14 18:13:05 <holtmann> Yes. Exported via Bluetooth or USB. I prefer PAN and CDC-Ether since that would just work.
May 14 18:14:16 <holtmann> For the PDP outgoing context, we have to figure out the second TTY (or mux) or PhoNet, HSO, MBM network devices.
May 14 18:15:16 <holtmann> We need to have to do PPP and I already looked inside the kernel ppp-generic and pppd. We can write our own part since in most cases it acts as a transparent proxy only.
May 14 18:16:46 <holtmann> I have to work on that support anyway for ConnMan. Then we can share code here. Systems with ConnMan, but not oFono and 3G data cards should work.
May 14 18:17:39 <denkenz> holtmann: Nod, I always thought that most of GPRS work will be done by ConnMan
May 14 18:18:00 <denkenz> holtmann: About the only thing that oFono can do is the GPRS Network Registration commands
May 14 18:18:10 <denkenz> holtmann: And maybe the context stuff
May 14 18:18:18 <holtmann> We will see once we have more details about how non AT hardware like PhoNet does it.
May 14 18:18:33 <denkenz> holtmann: Exactly
May 14 18:18:45 <holtmann> I can see a system using oFono and not ConnMan so we might have overlaps here. We will see how it goes.
May 14 18:19:07 <holtmann> Or you wanna use NetworkManager on top of oFono.
May 14 18:19:12 <denkenz> holtmann: Every modern system needs BT + GPRS + CS Voice
May 14 18:19:28 <denkenz> holtmann: I say we cover that case first, then make it fully pluggable
May 14 18:19:58 <holtmann> I am not worried about the details right now since we plug whatever we want anywhere anyway :)
May 14 18:20:56 <denkenz> holtmann: Nod, btw we also are supposed to be working on an HFP client plugin for oFono
May 14 18:21:16 <denkenz> holtmann: So you'll probably get questions later on ;)
May 14 18:21:49 <holtmann> denkenz: oFono HFP support for BlueZ got merged already :)
May 14 18:22:00 <denkenz> holtmann: I know, that's the server
May 14 18:22:18 <holtmann> You mean the headset role. Yes, we need that, too.
May 14 18:22:20 <denkenz> holtmann: I'm talking about oFono using HFP client profile to expose VoiceCallManager / VoiceCall
May 14 18:23:21 <holtmann> denkenz: Please send me your phonesim modifications as one big patch. I have to look into details if we need approval before publishing them.
May 14 18:24:08 <denkenz> holtmann: Gah, I don't actually have any tracking on it
May 14 18:25:33 <holtmann> That is not good. I need that.
May 14 18:26:59 <denkenz> holtmann: Problem is I stole the build system from OpenMoko emulation repo
May 14 18:27:13 <denkenz> holtmann: Then just copied files from latest qt-extended on top
May 14 18:27:36 <denkenz> holtmann: Then made mods and commited initial version
May 14 18:27:42 <denkenz> holtmann: All of them are trivial :)
May 14 18:28:15 <holtmann> Then you have to do them again.
May 14 18:28:24 <holtmann> And commit every step.
May 14 18:28:51 <denkenz> holtmann: Sigh, what a pain :)
May 14 18:29:13 <holtmann> And I don't like C++, so not much help from my side. Maybe I can fix the build-system to be something proper.
May 14 18:30:19 <denkenz> Heh, have fun with QMake :)
May 14 18:30:33 <holtmann> Or I just turn it into autoconf.
May 14 18:31:18 <denkenz> holtmann: Heh, probably can, however moc/qmake have just as much magic in them as automake
May 14 18:31:28 <denkenz> Shudder ;)
May 14 18:31:34 <holtmann> Then you keep it as it is.
May 14 18:35:18 <akiniemi> denkenz: you can always run moc and rcc from automake ;)
May 14 18:35:41 <denkenz> akiniemi: Yes I know, but this is really old-style Qt code
May 14 18:35:56 <denkenz> akiniemi: Some moc crap is inside the .cpp
May 14 18:36:12 <denkenz> akiniemi: Tricky to get right the first time
May 14 18:36:13 <akiniemi> denkenz: yikes
May 14 18:36:43 <denkenz> akiniemi: Nah its not that bad :)
May 14 18:40:20 <akiniemi> Btw, Phonet uses the Phonet Pipe Protocol for GPRS
May 14 18:41:00 <akiniemi> Some details in Documentation/networking/phonet.txt
May 14 18:41:40 <akiniemi> That "third party" is what we need here ;)
May 14 18:45:37 <holtmann> I like the pipe part of PhoNet. Having a proper network device instead of PPP is nice.
May 14 19:03:31 <Mirv> Tm_T: :)
May 14 19:23:16 <denkenz> holtmann: You should have those phonesim patches
May 14 20:27:21 <Strid> Hi everyone, short introduction of myself and who we are. I'm founder of weevio and have big interest in "Connect Home", "Future Living" etc. Weevio develop a application platform for IPTV, Touch Display and soon mobile phones where every device becomes apart of system.
**** ENDING LOGGING AT Fri May 15 02:59:58 2009

**** BEGIN LOGGING AT Fri May 15 02:59:58 2009
May 15 06:29:58 <Tm_T> Strid: welcome
May 15 12:52:49 <Strid> Which will be the first handsets that ofono will work with?
May 15 13:03:06 <iscape_b> i think they are intensively working to have it run on openmoko
May 15 13:03:10 <iscape_b> just kidding...
May 15 13:04:19 <Strid> :)
May 15 13:04:53 <iscape_b> but there is at least one hook for the calypso modem in the source 
May 15 13:05:22 <fgau> pyneo is running nice here, why another framwork?
May 15 13:07:11 <iscape_b> i had the impression that emdete is not too happy with fso
May 15 13:08:04 <fgau> i think you are right ;)
May 15 13:10:49 <Strid> Thanks, need to leave
May 15 13:17:25 <dorileo> fgau, you can see some reason explanations in the oFono mailing list, people has asked those things already
May 15 13:18:28 <dorileo> hi holtmann
May 15 13:18:51 <dorileo> holtmann, wouldn`t that be good to start a FAQ?
May 15 13:19:30 <dorileo> holtmann, a first question to the FAQ: "why another framework?" ;-)
May 15 15:37:00 <holtmann> dorileo: We are working on the FAQ part.
May 15 18:23:14 <ziyong> hi
May 15 19:00:25 <dorileo> holtmann, ok, thank you
May 15 19:36:26 <JosefAssad> erm. Doesn't this misrepresent ofono somewhat? http://www.engadget.com/2009/05/15/nokia-and-intel-collaborating-on-new-linux-based-phone-os-called
May 15 19:36:43 <JosefAssad> just slightly, of course
May 15 20:03:24 <holtmann> JosefAssad: oFono is the name of telephony stack. It is not an OS.
May 15 20:04:44 <holtmann> The OS is Linux or GNU/Linux if you like. Things like Maemo, Moblin, Fedora etc. are distributions.
May 15 20:14:16 <denkenz> Heh, where's my tinfoil hat?
May 15 20:20:13 <fgau> faq #2: why another framwork from companys like ...?
May 15 20:25:14 <JosefAssad> holtmann: yes, I know :) I just found it amusing that they could get it that wrong
May 15 20:27:31 <holtmann> If you wanna compare a piece of software oFono to an OS/distro like Android, the you either one of them wrong ;)
May 15 20:28:57 <holtmann> fgau: Companies like who? If you talk about Android than that is pretty simple. Android code contribution agreement is not really free software.
May 15 20:31:48 <fgau> holtmann: i know, but you are not invent this stack not for free .. i think
May 15 20:32:50 <holtmann> I am getting paid for working on oFono, but for non-Intel contributions we don't require assignment of copyright. Android does this.
May 15 20:33:04 <JosefAssad> doesn't matter how the development is financed if the license is open and the contribution model also
May 15 20:34:18 <JosefAssad> not really my businss, but sometimes there's good reasons for JCAs... should the project need to relicense to something incompatible in the future for whatever reason, for example. But that's probably offtopic
May 15 20:34:38 <JosefAssad> anyhow, IANAL
**** ENDING LOGGING AT Sat May 16 02:59:57 2009

**** BEGIN LOGGING AT Sat May 16 02:59:57 2009
May 16 06:12:02 <bae> hello
May 16 06:20:49 <bae> kubuntu9.04 needs libgtk2.0-dev and libdbus-1-dev when ofonod building
May 16 06:22:25 <bae> ./bootstrap-configure stoped at PKG_CHECK GLIB, GTHREAD, DBUS
May 16 06:23:09 <bae> fyi. regards.
**** ENDING LOGGING AT Sun May 17 02:59:57 2009

**** BEGIN LOGGING AT Sun May 17 02:59:57 2009
May 17 04:56:49 <ziyong> quiet..
May 17 05:01:46 <slaxxer> http://www.vanille-media.de/site/index.php/2008/06/28/gtk-asu-fso-tmtla/
May 17 11:22:08 <flowher> hello?
May 17 11:22:14 <flowher> is somebody here ?
May 17 11:23:46 <flowher> quick question - how to compile ofono?
May 17 11:49:20 <Strid> http://git.kernel.org/?p=network/ofono/ofono.git;a=blob;f=INSTALL;h=56b077d6a0b8773b014bd4381cc09abb17fff351;hb=c427cdfdfacbec9b0221e157797e6c9d33113e91
May 17 11:55:44 <holtmann> Strid: Call ./bootstrap-configure and then make. Check the HACKING document for more details.
May 17 12:51:35 <jorma_> can i already send and receive messages with ofono at driver?
May 17 12:56:05 <holtmann> jorma_: There is only partial support for SMS right now.
May 17 12:57:50 <jorma_> k
May 17 15:39:04 <flowher> \exit
May 17 15:39:05 <flowher> quit
May 17 15:39:07 <flowher> \quit
May 17 15:39:22 <ziyong> . /
**** ENDING LOGGING AT Mon May 18 02:59:57 2009

**** BEGIN LOGGING AT Mon May 18 02:59:57 2009
May 18 17:28:03 <dorileo> hi all... would that be possible to write a "road map" and a "how to contribute" documentation to help newcomers(like me) to understand the project`s short term goals?
May 18 17:36:40 <denkenz> dorileo: We're working on that, however, in the meantime I can certainly answer questions
May 18 21:06:32 <krau> holtmann: denkenz hi! Are you planning export a method or property under org.ofono.Modem interface to control the modem better? For example export the features required to implement SAP server.
May 18 21:07:02 <denkenz> krau: What kind of control?
May 18 21:07:44 <krau> enable remote SIM, power on/off/reset ..
May 18 21:08:09 <krau> report modem status
May 18 21:08:21 <krau> exchange APDUs
May 18 21:09:08 <denkenz> Those are all really vendor specific
May 18 21:09:20 <denkenz> There are a few things we can report, like power level using CFUN
May 18 21:09:27 <denkenz> But that is most likely not what you want anyway
May 18 21:09:51 <denkenz> Can you give me an actual example on a working modem? :)
May 18 21:10:43 <krau> NXP modem :-)
May 18 21:11:04 <denkenz> Heh
May 18 21:11:26 <denkenz> I'm open to ideas, I think we're not planning on it at this time, mostly due to not having actual hardware
May 18 21:11:27 <krau> I saw the new file phonet.c in repo, who is developing this ofono driver?
May 18 21:11:37 <denkenz> Aki I think
May 18 21:13:24 <krau> So if one day we decide implement SAP for BlueZ we will need to develop a service based on plugins due the vendor specific commands
May 18 21:16:58 <denkenz> We have to see
May 18 21:17:09 <denkenz> If we can generalize it enough, we can make it a proper interface
May 18 21:17:25 <denkenz> If not, it might have to be a custom interface only for the particular modem you're using
May 18 21:17:50 <holtmann> My general feeling is that we can add an interface to oFono that is only intended to serve as Bluetooth SAP interaction.
May 18 21:18:22 <holtmann> We should be able to hide the modem specific details inside the modem driver plugin.
May 18 21:18:26 <holtmann> However time will tell.
May 18 21:20:08 <denkenz> Yep, which means it can be a generic interface ;)
May 18 21:20:26 <denkenz> However, most modems I've seen do not support this stuff
May 18 21:32:40 <krau> is there any phonet public documentation? I saw one text file in the kernel documentation, but it is not clear enough to me. Don't answer the source code :-P
May 18 21:33:49 <denkenz> akiniemi is the best person to ask
May 18 21:34:17 <holtmann> krau: PhoNet is the basic transport. ISI is the modem access protocol.
May 18 21:35:08 <holtmann> The plugin for Nokia will be split into a gisi library (ISI with GLib mainloop integration) and then the Nokia modem driver.
May 18 21:35:23 <holtmann> According to my last conversation with Aki.
May 18 21:35:55 <holtmann> Details might change though.
May 18 21:41:04 <krau> thanks, I will try get access to ISI library source code. I have access to some parts, but I am afraid that I will not have access to this library :-)
May 18 22:41:40 <denkenz> holtmann: Lemme get your opinion on something about call barring interface
May 18 22:42:10 <denkenz> holtmann: In call barring, you can have BarOutgoing, BarOutgoing to International, and BarOutgoing except Home
May 18 22:42:26 <denkenz> holtmann: However, only one can be active per Voice/Data/Fax call type
May 18 22:42:34 <denkenz> holtmann: Or Off of course
May 18 22:43:27 <denkenz> holtmann: So question, should we use a single attribute with 4 values, e.g. VoiceBarOutgoing -> "on", "international", "allexcepthome", "off"
May 18 22:43:56 <denkenz> holtmann: Or 3 attributes per, e.g. VoiceBarOutgoing -> enabled / disabled
May 18 22:44:07 <denkenz> holtmann: VoiceBarOutgoingInternational -> enabled / disabled, etc
May 18 22:52:27 <holtmann> The first one with "on" (maybe "activated" is better) , "international" etc. seems more intuitive from a UI perspective.
May 18 22:53:07 <holtmann> And s/Bar/Barrier/ is better. Except this option goes ahead and buys me a beer ;)
May 18 22:56:02 <denkenz> Heh, nod, I was thinking along the same lines
May 18 22:56:08 <denkenz> Except the naming is screwed up
May 18 22:56:28 <denkenz> I'm thinking just having attributes "Outgoing" and "Incoming", keep Bar out of it
May 18 22:56:34 <denkenz> Its in the interface name anyway
May 18 23:00:06 <holtmann> Okay.
**** ENDING LOGGING AT Tue May 19 02:59:57 2009

**** BEGIN LOGGING AT Tue May 19 02:59:57 2009
May 19 08:29:01 <htalvitie> regarding the techcrunch story of maemo harmattan and its use as mobile os: would ofono play a part in this?
May 19 08:29:29 <htalvitie> (or "could")
May 19 08:43:20 <inz> What is the motivation behind using "proprietary" dbus-wrapper instead of using GObjects + dbus-glib?
May 19 08:56:53 <Cougar> when using git latest version and "./configure --enable-maintainer-mode" ity does not compile
May 19 08:56:57 <jhe> inz: which dbus-wrapper are you referring to?
May 19 08:57:17 <inz> jhe, to the one used by oFono (in the git)
May 19 08:57:25 <jhe> inz: gdbus?
May 19 08:57:29 <inz> yeah
May 19 08:57:50 <jhe> it's quite a popular glib based dbus library in open source projects
May 19 08:58:14 <jhe> e.g. bluez, obexd and connman use it (though they are all maintained by mr holtmann :)
May 19 08:58:19 <inz> Oh, I haven't seen it previously :/
May 19 08:58:40 <inz> That would explain it somewhat ;)
**** ENDING LOGGING AT Wed May 20 02:59:57 2009

**** BEGIN LOGGING AT Wed May 20 02:59:57 2009
May 20 11:07:42 <courmisch> git access over http seems broken
May 20 11:07:46 <courmisch> info/refs is missing
May 20 21:06:11 <aleksander_m> hi all
May 20 21:06:45 <aleksander_m> what's the status of this project? Is it usable in any actual handset?
May 20 21:27:17 <denkenz> no
May 20 21:27:25 <denkenz> still early stages
May 20 21:37:48 <aleksander_m> and how's the actual development going? how can someone test the changes being made?
**** ENDING LOGGING AT Thu May 21 02:59:57 2009

**** BEGIN LOGGING AT Thu May 21 02:59:57 2009
May 21 21:29:00 <denkenz> holtmann: Do we want to enforce the 80 character limit in test scripts?
May 21 22:57:53 <sabotage> denkenz, holtmann: is the plan to keep ofono running on the system bus (vs. session)?
May 21 23:20:27 <denkenz> sabotage: It has to be on the system bus
May 21 23:21:19 <sabotage> ok, I knew it was so far, didn't know it it "had" to be
May 21 23:21:28 <sabotage> but given that...
May 21 23:22:02 <denkenz> sabotage: I don't see how it could work on a session bus ;)
May 21 23:22:05 <sabotage> it seems most services running on system \tend\ to run as root, yet so far I've been running as \user\
May 21 23:22:48 <sabotage> what are the implications of runnign as root or running a system service as user, as far as security and distro maintainers are concerned?
May 21 23:22:55 <denkenz> sabotage: So far there is no specific requirement, however on real systems with real serial ports it most likely need to be run as root
May 21 23:23:14 <sabotage> ok
May 21 23:23:31 <sabotage> questions stem from my attempts to package this for moblin
May 21 23:23:50 <denkenz> Well, on my box for instance hald and dbus-daemon run as non-root
May 21 23:23:53 <sabotage> I've got one built, but trying to tweak it to autostart and have a working default config
May 21 23:23:57 <denkenz> so there's no 'hard' requirement
May 21 23:24:18 <sabotage> kk
May 21 23:24:50 <sabotage> I'll have patches then to add a service file, and install it correctly
May 21 23:25:09 <denkenz> sure, holtmann is really more experienced here
May 21 23:25:11 <sabotage> mail them to list cc'ing you and holtmann?
May 21 23:25:20 <denkenz> we'll do what he says :)
May 21 23:25:22 <sabotage> ok
May 21 23:25:28 <sabotage> also
May 21 23:26:00 <sabotage> my package is built from tip (currently 5/13, but will refresh to this evening when I get the auto start working)
May 21 23:26:13 <sabotage> but it REALLY should be from a "release" tar file
May 21 23:26:20 <sabotage> yet there are none :P
May 21 23:26:59 <denkenz> Yeah, I think holtmann doesn't have enough time, I'd also like to have API docs before we make a release
May 21 23:27:07 <sabotage> not sure what distro maintainers or holtmann will do (if they care) about that, just FYI
May 21 23:27:13 <denkenz> And he has to work them a bit AFAIK
May 21 23:27:24 <sabotage> k
May 21 23:27:55 <sabotage> then we'll likely have a package, but it won't be public until holtmann signs off I guess
May 21 23:29:01 <denkenz> nod, I think we're close, though I haven't heard any bug reports from you or raji, which makes me worried :)
May 21 23:30:00 <sabotage> denkenz: ;) 
May 21 23:30:15 <sabotage> sorry about the silence
May 21 23:30:48 <sabotage> last two weeks have been consumed with reworking code to match just released UI
May 21 23:32:05 <denkenz> Nod, I'm reworking some implementation details too, and simplify some things
May 21 23:32:18 <denkenz> Hopefully I can get back to SMS next week
May 22 00:14:55 <balrog-kun> denkenz: according to 27.007 the subscriber numbers can be stored on the mt or sim, I assume we want them on the sim dbus interface anyway?
May 22 00:15:46 <balrog-kun> denkenz: this is andrew by the way
May 22 00:59:03 <denkenz> balrog-kun: I assume +CNUM actually takes care of that
May 22 00:59:50 <denkenz> balrog-kun: I also saw subscriber numbers being stored in dedicated SIM storage, so I assume that this is what happens in practice anyway
May 22 01:00:00 <denkenz> balrog-kun: So yeah, put them there for now
May 22 01:26:02 <balrog-kun> okays
May 22 01:26:27 <balrog-kun> denkenz: yes, +CNUM works regardless
May 22 01:57:16 <holtmann> sabotage: We will stick with system bus, but in theory it can be run in chroot or a different user. Not sure if it is worth the effort.
May 22 01:58:18 <holtmann> Before we go with ofono-0.1, we still have to work through some minor corrections. For example /etc/ofono/modem.conf support for configuration.
May 22 01:59:40 <denkenz> holtmann: And we should get the api docs sorted out
May 22 02:00:00 <holtmann> That is my job.
May 22 02:00:44 <denkenz> holtmann: I know ;)
May 22 02:39:11 <sabotage> holtmann: nod
May 22 02:39:51 <sabotage> I need a package for my testing and demos, but will keep it internal until you're ready to make a release
May 22 02:40:46 <sabotage> I'll send a patch in the morning with the changes I made to configure.ac and src/Makefile.am to add a new file, org.ofono.service
**** ENDING LOGGING AT Fri May 22 02:59:57 2009

**** BEGIN LOGGING AT Fri May 22 02:59:57 2009
May 22 03:52:02 <holtmann> sabotage: Sure. I will review them and make sure they apply properly.
May 22 03:58:46 <sabotage> nod
May 22 06:27:21 <lpotter> denkenz: how goes it?
May 22 14:12:39 <denkenz> lpotter: Nod bad, yourself?
May 22 18:46:21 <lpotter> denkenz: I'm good. still employed :) 
May 22 18:47:09 <denkenz> lpotter: Heh, but do you guys still get free lunch is the more important question ;)
May 22 18:47:11 <lpotter> denkenz: seems ofono was dissed by some FSO/openmoko devs. "reinventing the wheel"
May 22 18:47:28 <lpotter> denkenz: yes, indeed. and flexispend too
May 22 18:48:01 <lpotter> can you share what hardware you are developing this on?
May 22 18:48:06 <denkenz> lpotter: Yeah I followed the thread for a little bit, until I read a great post by rasterman
May 22 18:48:21 <denkenz> lpotter: We have no hardware yet actually
May 22 18:48:47 <lpotter> I know of some crappy, buggy calypso modem hardware :)
May 22 18:48:59 <denkenz> lpotter: Yeah, I have a Neo V02
May 22 18:49:22 <denkenz> lpotter: Writing the at parser for that thing was a nightmare
May 22 18:49:25 <lpotter> I can;t believe some of the media thinks ofono is 'yet another embedded platform' wtf?!
May 22 18:50:06 <lpotter> I've been working with NetworkManager lately...
May 22 18:50:17 <denkenz> lpotter: And half the commands don't work on T-Mobile for some reason :)
May 22 18:50:55 <lpotter> could always try a universal
May 22 18:51:05 <lpotter> HTC...
May 22 18:52:07 <lpotter> in a way I miss working with the neo, and in a way I hate that frickin thing
May 22 18:52:38 <denkenz> Btw, did you guys ever figure out whether those OMAP3 boards had GSM module?
May 22 18:52:43 <lpotter> the 'buzz fix' parties are a riot
May 22 18:53:06 <denkenz> heh, i just use the Neo as an AT parser stress test :)
May 22 18:53:42 <lpotter> not real sure, can ask on Monday
May 22 18:54:17 <lpotter> if you ever want to come back to brissie, we are still hiring... :)
May 22 18:54:28 <denkenz> Heh
**** ENDING LOGGING AT Sat May 23 02:59:57 2009

**** BEGIN LOGGING AT Sat May 23 02:59:57 2009
**** ENDING LOGGING AT Sun May 24 02:59:57 2009

**** BEGIN LOGGING AT Sun May 24 02:59:57 2009
**** ENDING LOGGING AT Mon May 25 02:59:57 2009

**** BEGIN LOGGING AT Mon May 25 02:59:57 2009
**** ENDING LOGGING AT Tue May 26 02:59:57 2009

**** BEGIN LOGGING AT Tue May 26 02:59:57 2009
**** BEGIN LOGGING AT Sun May 31 20:37:21 2009
**** ENDING LOGGING AT Mon Jun 01 02:59:57 2009

**** BEGIN LOGGING AT Mon Jun 01 02:59:57 2009
Jun 01 03:00:38 <Karadog> hi, all
Jun 01 05:56:56 <akiniemi> Karadog: hi
Jun 01 06:01:14 <Karadog> akiniemi: hi
**** ENDING LOGGING AT Tue Jun 02 02:59:57 2009

**** BEGIN LOGGING AT Tue Jun 02 02:59:57 2009
Jun 02 11:06:06 <akiniemi> holtmann: ping
Jun 02 16:02:10 <akiniemi> denkenz: ping
Jun 02 16:02:21 <denkenz> akiniemi: pong
Jun 02 16:02:49 <akiniemi> We asked around about phonesim, and it's not maintained any more
Jun 02 16:02:58 <akiniemi> So we're on our own on that :)
Jun 02 16:03:29 <denkenz> Nod, I guessed
Jun 02 16:03:50 <akiniemi> You used to work on it in a past life, no?
Jun 02 16:04:04 <denkenz> 'with it' :)
Jun 02 16:06:02 <denkenz> You guys have a preference whether it should be in-tree or a separate project?
Jun 02 16:06:41 <akiniemi> Well, I suppose it could start as in-tree and split out if necessary
Jun 02 16:07:57 <denkenz> It has 'hefty' requirements
Jun 02 16:08:21 <denkenz> So it'll probably be up to Marcel, if he wants to do automake magic for it we can put it in the tree
Jun 02 16:14:27 <akiniemi> Yeah, he seems to have a black belt in autotools ;)
Jun 02 16:15:16 <denkenz> Nod, he advertises it too ;)
Jun 02 16:16:24 <denkenz> We'll see if we can get our patches released in 2-3 weeks
Jun 02 16:16:55 <denkenz> Hopefully not longer than that
Jun 02 18:06:45 <denkenz> akiniemi: Do you guys have test cases for various SMS pdus?
**** ENDING LOGGING AT Wed Jun 03 02:59:57 2009

**** BEGIN LOGGING AT Wed Jun 03 02:59:57 2009
Jun 03 07:44:24 <akiniemi> denkenz: about the SMS TPDU test cases, yes, I was planning to add a bunch
Jun 03 07:45:31 <akiniemi> denkenz: also, some very recent additions to 23.038, namely the national language variants
Jun 03 15:11:08 <denkenz> akiniemi: It would be nice to get them in to test the existing tpdu parsing code
Jun 03 15:11:56 <denkenz> akiniemi: Are you referring to locking shift / single shift stuff?
Jun 03 18:26:23 <akiniemi> ~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[5~[5~[5~[6~[6~[6~/n
Jun 03 18:26:38 <denkenz> eh?
Jun 03 18:26:46 <josch> hrhr
Jun 03 19:08:19 * akiniemi wonders who just inserted garbage into his ssh session ;)
Jun 03 19:09:37 <akiniemi> denkenz: yup, nat'l variants define new single/locking shift tables and UDH elements to indicate their use
Jun 03 19:11:35 <denkenz> akiniemi: Ah good, that would be useful
Jun 03 19:11:58 <denkenz> akiniemi: And I was too lazy to actually implement it myself until someone started screaming :)
Jun 03 19:17:14 <denkenz> akiniemi: any etas other than 'soon'? :)
Jun 03 19:24:26 <akiniemi> denkenz: in the next 2 weeks
**** ENDING LOGGING AT Thu Jun 04 02:59:58 2009

**** BEGIN LOGGING AT Thu Jun 04 02:59:58 2009
Jun 04 12:49:42 <inz> i think i've hit a bug in gatchat
Jun 04 12:51:05 <inz> it seems to miss the terminating OK in some cases
Jun 04 14:41:52 <rzr__> hi
Jun 04 14:42:08 <rzr__> is ofono related to new nokia tablet  : Video about  N900 and maemo5 http://talk.maemo.org/showthread.php?p=293687&posted=1#post293687
**** ENDING LOGGING AT Fri Jun 05 02:59:57 2009

**** BEGIN LOGGING AT Fri Jun 05 02:59:57 2009
Jun 05 17:45:18 <Robot101> akiniemi: will the phonet backend exist soon? :) and will it let you use Nokia handsets via usb or bluetooth somehow?
Jun 05 20:42:43 <akiniemi> Robot101: working on it
Jun 05 20:43:29 <akiniemi> Robot101: and yes, the intention is you can use PhoNet over USB
Jun 05 20:47:38 <akiniemi> Should be able to use any phone's AT command inerface with cdc_acm?
Jun 05 22:36:24 <akiniemi> denkenz: ping
Jun 05 22:36:33 <denkenz> akiniemi: pong
Jun 05 22:37:08 <akiniemi> Can I get the at driver working over tty?
Jun 05 22:37:36 <denkenz> Sure, just finish writing the tty code for it
Jun 05 22:37:42 <denkenz> Beginnings of one is #if 0 oud
Jun 05 22:37:47 <denkenz> s/oud/out
Jun 05 22:38:07 <denkenz> Alternatively use netcat 
Jun 05 22:40:01 <denkenz> I also use ser2net on my Neo
Jun 05 23:01:11 <tuukkah> i'd suggest socat. unfortunately i don't have the command line at the hand, but something like socat tcp4-listen:1234,fork open:/dev/ttyACM0,raw
Jun 05 23:02:07 <tuukkah> (this will listen on localhost:1234 and pipe the connections to /dev/ttyACM0)
Jun 05 23:02:13 <denkenz> nod, whatever works.  Of course I wouldn't mind a patch that implements tty natively one of these days :)
Jun 05 23:16:18 <tuukkah> akiniemi, i've used this one before: socat -v -dddd TCP4-LISTEN:1234,reuseaddr,fork file:/dev/ttySAC0,crtscts,echo=0,raw
Jun 05 23:18:08 <tuukkah> still no faq... i suppose i should post these on the mailing list
Jun 05 23:41:31 <denkenz> akiniemi: Do you know by any chance whether TP-SRI field needs to be cared about in any way?
Jun 05 23:45:28 <denkenz> I currently CNMA all deliver pdus
Jun 05 23:45:39 <denkenz> Wondering if CNMA should only be sent if SRI is set
**** ENDING LOGGING AT Sat Jun 06 02:59:58 2009

**** BEGIN LOGGING AT Sat Jun 06 02:59:59 2009
**** ENDING LOGGING AT Sun Jun 07 02:59:57 2009

**** BEGIN LOGGING AT Sun Jun 07 02:59:57 2009
Jun 07 20:19:54 <akiniemi> denkenz: Hmm... I think the SRI is informational
Jun 07 20:21:23 <akiniemi> denkenz: the actual STATUS REPORT is sent by the SMSC, triggered off a received DELIVER-REPORT
Jun 07 20:25:58 <akiniemi> denkenz: But the SMSC always needs the DELIVER-REPORT, so the CNMA seems in order
**** ENDING LOGGING AT Mon Jun 08 02:59:57 2009

**** BEGIN LOGGING AT Mon Jun 08 02:59:57 2009
Jun 08 06:04:37 <inz> I made a fairly simple patch to add tty support to ofono: http://inz.fi/ofono-dev.diff for my own testing purposes
Jun 08 06:04:44 <inz> Maybe it's useful for someone else too.
Jun 08 07:06:51 <courmisch> well surely it should have TTY support at some point
Jun 08 07:07:01 <courmisch> as most AT modems are exposed that way
Jun 08 07:18:38 <inz> Had do do some major hacks to gatchat to get it up and running with N95...
Jun 08 09:46:18 <akiniemi> inz: my recollection is N95's AT interface is, krhm, limited ;)
Jun 08 09:48:29 <inz> akiniemi, well, maybe, but gatchat makes some rather rude assumptions
Jun 08 09:49:01 <inz> akiniemi, like that the modem will only return data on every other row (i.e. returned data is in form \r\nfoo\r\n\r\nbar\r\n\r\nOK\r\n
Jun 08 09:51:15 <akiniemi> inz: smells like a bug, denkenz?
Jun 08 09:51:26 <inz> I haven't found anything related to this in the spec (checked ETSI 07.07) but I think it is safe to assume \r\nfoo\r\nbar\r\nplop\r\n\r\nOK\r\n
Jun 08 09:51:55 <inz> But nothing more
Jun 08 09:52:51 <inz> I hope that someone else takes a catch on fixing it, my quick fix is really horrible ;)
Jun 08 09:53:47 <inz> Better fix might involve wider changes in the parser, and I didn't want to go there, I just wanted it to run so I could test it.
Jun 08 09:53:59 <inz> At least I got the N95 to call, so there's some functionality ;)
Jun 08 10:57:41 <iscape> any word about the API documentation? the doc page still only shows the diagram...
Jun 08 11:06:26 <inz> iscape, dbus-send + Introspect ;)
Jun 08 11:31:09 <iscape> inz: yes. and i can look into the source code too - but a doc on the web page would also be good ;)
Jun 08 16:09:30 <denkenz> akiniemi: regarding SRI, I suspected the same as well.  Probably its related to whether SUBMIT had an SRR set
Jun 08 16:09:45 <denkenz> akiniemi: e.g. no practical value for SRI that I can tell
Jun 08 16:10:16 <denkenz> inz: Can you give me an example where GAtChat didn't work?
Jun 08 16:11:21 <denkenz> iscape: The documentation will be posted as soon as holtmann gets back from vacation
Jun 08 16:11:49 <iscape> denkenz: thx
Jun 08 19:11:29 <denkenz> inz: I've submitted a new patch to gatchat to fix the issue you reported
Jun 08 19:11:51 <denkenz> inz: Let me know if it works, also, care to submit the at patch to the mailing list using git format-patch?
Jun 08 19:12:24 <denkenz> inz: s/at patch/serial patch/
**** ENDING LOGGING AT Tue Jun 09 02:59:57 2009

**** BEGIN LOGGING AT Tue Jun 09 02:59:57 2009
Jun 09 09:46:00 <inz> denkenz, yeah, now it seems to work
Jun 09 10:41:58 <inz> denkenz, and now the patch is sent too; had to configure exim to send mail first =)
**** ENDING LOGGING AT Wed Jun 10 01:42:29 2009

**** BEGIN LOGGING AT Wed Jun 10 01:42:50 2009
**** ENDING LOGGING AT Wed Jun 10 01:54:52 2009

**** BEGIN LOGGING AT Wed Jun 10 01:55:15 2009
**** ENDING LOGGING AT Wed Jun 10 02:59:57 2009

**** BEGIN LOGGING AT Wed Jun 10 02:59:57 2009
Jun 10 16:36:29 <denkenz> akiniemi: Hey do you guys have any reqs to support Smart Messaging stuff? E.g. VCards VCals over SMS?
Jun 10 19:50:57 <denkenz> holtmann: ping
**** ENDING LOGGING AT Thu Jun 11 02:59:57 2009

**** BEGIN LOGGING AT Thu Jun 11 02:59:57 2009
Jun 11 18:53:27 <holtmann> akiniemi: Do me a favor and run major autoconf/automake changes first via the mailing list. There is some hidden magic behind some details.
Jun 11 18:53:39 <holtmann> Also please no signed-off-by since this is not kernel code.
Jun 11 18:54:37 <holtmann> +int isi_client_error(const struct isi_client *client)
Jun 11 18:54:38 <holtmann> +{	/* The only possible error at the moment */
Jun 11 18:54:38 <holtmann> +	return ETIMEDOUT;
Jun 11 18:54:38 <holtmann> +}
Jun 11 18:54:55 <holtmann> And stuff like this is no no. Use negative return values. So -ETIMEDOUT.
Jun 11 18:57:11 <holtmann> akiniemi: I would prefer if we call this gisi or whatever we agreed. Mainly to clearly indicate that this is with GLib mainloop integration.
Jun 11 18:57:24 <holtmann> I know we talked about it.
Jun 11 19:12:10 <courmisch> are errno values warranted to be positive?
Jun 11 19:12:16 <courmisch> on Linux sure
Jun 11 19:12:22 <courmisch> but...
Jun 11 19:12:52 <courmisch> returning -error makes sense when you return positive values for success
Jun 11 19:13:15 <courmisch> OTOH POSIX returns the error code as is in many functions when success is 0
Jun 11 19:13:53 <holtmann> functions returning an error are either return -1 and set errno (which is racy like hell) or just return -errno.
Jun 11 19:14:18 <holtmann> And yes errno values are all defined as positive values.
Jun 11 19:14:21 <courmisch> what functions?
Jun 11 19:14:33 <holtmann> Any kind of function you write.
Jun 11 19:15:09 <holtmann> We wanna be able to do if (something(...) < 0) etc.
Jun 11 19:15:10 <courmisch> Which you?
Jun 11 19:15:38 <akiniemi> holtmann: ack on major changes to autoconf/automake
Jun 11 19:16:17 <holtmann> What do you mean by that? Function return 0 on success or -E* something on failure. That is basic convention for kernel coding style and we duplicate that here.
Jun 11 19:16:22 <akiniemi> holtmann: about gisi vs isi, the current API exposes no G-ness, so gisi and g_ prefixes didn't really seem warranted
Jun 11 19:16:42 <holtmann> I saw GMainLoop integration. That is enough for g*
Jun 11 19:17:26 <akiniemi> holtmann: of course, internally
Jun 11 19:17:35 <holtmann> And that is my only point. If it plays nicely with GMainLoop we prefix it with a g to indicate that. In case we do put this in a separate project at some far future point of time,
Jun 11 19:26:28 <courmisch> hmm yeah then again how could you write code into oFono without gmainloop?
Jun 11 19:26:43 <courmisch> it's kinda self-evident
Jun 11 19:28:51 <denkenz> not really, e.g. dbus doesn't use gmainloop, but gdbus adapts it to
Jun 11 19:29:36 <courmisch> I think that's completely orthogonal to my point
Jun 11 19:41:54 <denkenz> we're talking about whether it should have g_ prefix.  If it uses g_ functions it probably should
Jun 11 19:41:56 <denkenz> Since it is a library and positioned at top level of the tree
Jun 11 19:42:09 <akiniemi> I can understand gatchat, since that is exposing plenty of G-types in the API.
Jun 11 19:42:35 <courmisch> hmm yeah, the library name should probably be fixed
Jun 11 19:44:17 <denkenz> Btw, pet peeve:
Jun 11 19:44:20 <denkenz> #ifndef OFONO_PHONET_SOCKET_H
Jun 11 19:44:20 <denkenz> #define OFONO_PHONET_SOCKET_H 1
Jun 11 19:44:27 <denkenz> Can we not include 1 at the end?
Jun 11 19:45:05 <denkenz> holtmann: Also, we need to standardize on the #ifndef format
Jun 11 19:45:17 <denkenz> Half of oFono uses #ifdef __FILE_NAME_H__
Jun 11 19:46:11 <courmisch> oooh violation of C standard here
Jun 11 19:46:26 <courmisch> leading _ is reserved for the run-time
Jun 11 19:46:59 <courmisch> but nobody knows
Jun 11 19:47:11 <courmisch> I once got a bug report about that in another project though
Jun 11 19:47:13 <denkenz> Again, I don't care what it is, as long as we all agree and stick to it
Jun 11 19:48:15 <courmisch> I'd rather have the OFONO name in it so I don't risk clashing with someone's else header
Jun 11 19:48:17 <holtmann> No #ifdef for non-public header files. I wanna catch broken circular includes.
Jun 11 19:48:24 <courmisch> but that may be theoretical
Jun 11 19:48:43 <holtmann> For ISI no OFONO prefix.
Jun 11 19:49:05 <holtmann> Same as we don't use one for GATCHAT.
Jun 11 19:49:38 <courmisch> well I'm totally not going to call it SOCKET_H... but yeah we can remove them
Jun 11 19:50:23 <akiniemi> courmish: call it GISI_PHONET_SOCKET :)
Jun 11 19:50:26 <denkenz> holtmann: Point is, what is the standard?
Jun 11 19:50:36 <denkenz> is it __FILE_NAME_H?
Jun 11 19:50:51 <akiniemi> courmisch: ^
Jun 11 19:51:11 <holtmann> #ifndef __CONNMAN_TYPES_H
Jun 11 19:51:11 <holtmann> #define __CONNMAN_TYPES_H
Jun 11 19:51:11 <holtmann> #ifdef __cplusplus
Jun 11 19:51:11 <holtmann> extern "C" {
Jun 11 19:51:11 <holtmann> #endif
Jun 11 19:51:18 <holtmann> That is what we prefer.
Jun 11 19:51:45 <denkenz> sounds good to me
Jun 11 19:52:22 <courmisch> _.* is for predefined macros according to the book
Jun 11 19:54:56 <akiniemi> how about types: CamelCase or not?
Jun 11 19:55:28 <denkenz> akiniemi: Approach taken so far is CamelCase in G_ style libraries
Jun 11 19:55:32 <denkenz> not inside ofono
**** ENDING LOGGING AT Fri Jun 12 02:59:56 2009

**** BEGIN LOGGING AT Fri Jun 12 02:59:56 2009
Jun 12 06:01:44 <akiniemi> denkenz: about vCards etc: yeah, sure
Jun 12 06:02:23 <akiniemi> denkenz: there should be an API to register handlers for any application port
Jun 12 06:03:51 <akiniemi> denkenz: by installing some config file to a well known location
Jun 12 06:04:14 <akiniemi> denkenz: maybe also at run-time, via D-Bus
Jun 12 06:04:49 <akiniemi> denkenz: but other than that, no -- so no need for a vCard parser in utils :)
Jun 12 06:12:32 <zgli> hi, someone know this issue with today version?
Jun 12 06:12:37 <zgli> netlink.c:43:26: error: linux/phonet.h: No such file or directory
Jun 12 06:13:08 <zgli> some special configration needed?
Jun 12 06:19:10 <akiniemi> zgli: you need a recent enough kernel with PhoNet support
**** ENDING LOGGING AT Fri Jun 12 06:20:50 2009

**** BEGIN LOGGING AT Fri Jun 12 06:21:13 2009
Jun 12 06:27:54 <zgli> oho, which kernel version would be good one?
Jun 12 06:49:04 <akiniemi> zgli: at least 2.6.28 should work
Jun 12 06:49:21 <akiniemi> zgli: alternatively, you can remove isi from SUBDIRS in Makefile.am
Jun 12 06:51:20 <akiniemi> zgli: you can do that now, since there isn't yet a modem driver that would use isi
Jun 12 16:16:45 <denkenz> holtmann: We need to have a switch in configure to disable phonet support
Jun 12 16:17:34 <denkenz> holtmann: Not all have the bleeding edge kernels with it supported
Jun 12 18:27:47 <akiniemi> denkenz: I don't see why. It will trickle down to the modem driver as well, causing unnecessary ifdefs
Jun 12 18:28:17 <akiniemi> denkenz: IMHO, by the time we're close to 1.0, PhoNet will hardly be bleeding edge
Jun 12 18:28:59 <akiniemi> denkenz: (until then, people without it can just disable it manually)
Jun 12 18:29:12 <courmisch> disabling ISI just for some stupid ifdefs, yeah kinda stupid
Jun 12 18:29:32 <courmisch> we can always copy the file if people whine too much
Jun 12 18:30:18 <akiniemi> courmisch: I would actually much prefer that
Jun 12 18:36:46 <akiniemi> denkenz: did you get a chance to test my short-to-string patch?
Jun 12 18:38:18 <akiniemi> denkenz: it seems to work ok with N95, except the AT interface there doesn't allow proper operator listings
Jun 12 19:23:53 <denkenz> akiniemi: I haven't tested it because I can't build yet
Jun 12 19:24:22 <denkenz> akiniemi: My VM is running 2.6.27, no phonet there
Jun 12 19:25:38 <denkenz> akiniemi: Again, IMO we should disable this in the build system, particularly when people start porting this to Linux distros from OEMs
Jun 12 19:25:38 <akiniemi> denkenz: crikey! :)
Jun 12 19:25:53 <denkenz> akiniemi: Those are yeeears behind
Jun 12 19:27:03 <denkenz> btw, the atmodem plugin should also have the option to be disabled
Jun 12 19:27:35 <akiniemi> denkenz: true. We need to figure out how to handle multiple builtin drivers
Jun 12 19:28:06 <akiniemi> For instance, I can't name files in the same way in the ISI driver as in the AT driver
Jun 12 19:28:46 <denkenz> Nod, I'm not particularly fond of the way builtins are handled
Jun 12 19:29:03 <denkenz> holtmann has already indicated he will make configure option to build as builtin or plugin
Jun 12 19:29:09 <denkenz> but that hasn't happened yet
Jun 12 19:30:00 <denkenz> Btw, I'll push the patch out with a few style modifications once I get it tested
Jun 12 19:31:01 <akiniemi> denkenz: what were those? I could modify and push myself -- I have a couple of additional fixes piled up locally
Jun 12 19:31:36 <denkenz> Don't remember, nothing substantial but all over the place
Jun 12 19:32:42 <akiniemi> denkenz: still about the ISI support, I'd much rather include a phonet.h in the distribution, and have AC magic in configure.ac to switch between a system version and the local one
Jun 12 19:33:40 <denkenz> akiniemi: That seems complicated, but whatever works.  holtmann is the build system maintainer
Jun 12 19:33:45 <akiniemi> denkenz: sure, the driver won't work on systems without PhoNet, but at least it will always build
Jun 12 19:33:51 <denkenz> akiniemi: I don't want to touch automake with a 10 foot pole
Jun 12 19:34:03 <akiniemi> :)
Jun 12 19:36:25 <akiniemi> denkenz: BTW, can you explain a couple of things for me in util.c?
Jun 12 19:36:35 <denkenz> akiniemi: I can try
Jun 12 19:37:15 <akiniemi> denkenz: like what purpose exactly does the greek table serve?
Jun 12 19:39:05 <denkenz> easier to store
Jun 12 19:39:31 <denkenz> the 7bit set includes greek letters which are up in some silly codepage in unicode
Jun 12 19:39:41 <denkenz> So we store them as a separate table
Jun 12 19:40:09 <denkenz> that + the Euro sign are special cases
Jun 12 19:43:19 <denkenz> Its only used for conversion from utf8 to gsm btw
**** ENDING LOGGING AT Fri Jun 12 22:02:30 2009

**** BEGIN LOGGING AT Fri Jun 12 22:03:25 2009
**** ENDING LOGGING AT Sat Jun 13 02:59:57 2009

**** BEGIN LOGGING AT Sat Jun 13 02:59:57 2009
Jun 13 04:06:04 <holtmann> akiniemi: I will extend the build system so you can either select atmodem or phonet. There is no need to build both for embedded systems. For the desktop it does make sense.
**** ENDING LOGGING AT Sat Jun 13 07:19:27 2009

**** BEGIN LOGGING AT Sat Jun 13 07:20:00 2009
**** ENDING LOGGING AT Sat Jun 13 08:24:55 2009

**** BEGIN LOGGING AT Sat Jun 13 08:26:00 2009
**** ENDING LOGGING AT Sat Jun 13 08:27:09 2009

**** BEGIN LOGGING AT Sat Jun 13 08:27:40 2009
**** ENDING LOGGING AT Sun Jun 14 02:59:57 2009

**** BEGIN LOGGING AT Sun Jun 14 02:59:57 2009
**** ENDING LOGGING AT Mon Jun 15 02:59:57 2009

**** BEGIN LOGGING AT Mon Jun 15 02:59:57 2009
Jun 15 12:22:07 <akiniemi> inz: ping
Jun 15 15:04:14 <inz> akiniemi, pong
Jun 15 15:04:36 <inz> Or should I say ping timeout ;)
Jun 15 17:08:24 <akiniemi> inz: a bit of latency here it seems ;)
Jun 15 17:08:47 <akiniemi> inz: haven't seen that tty patch -- did you send it to the list?
Jun 15 17:09:38 <inz> akiniemi, I did, and I got it myself...
Jun 15 17:11:03 <inz> I guess I'll try resending it with thunderbird (instead of git-email)
Jun 15 17:11:42 <inz> Hmm, seems git CC's self by default, so that would explain why I received it
Jun 15 17:13:54 <inz> Maybe it wasn't such a good idea; it may be broken now...
Jun 15 17:14:09 <inz> But at least now it got on to the list
Jun 15 17:18:54 <inz> And seems that it didn't break after all, at least the patch looks good in archive
Jun 15 17:27:07 <denkenz> akiniemi: If you will be integrating that one, please break out the gatchat changes into a separate patch
Jun 15 17:27:25 <denkenz> akiniemi: those will need to go into connman as well
Jun 15 17:28:27 <akiniemi> inz: weird, I never saw it
Jun 15 17:28:43 <akiniemi> denkenz: sure
Jun 15 17:30:29 <denkenz> I also wouldn't mind the open to be non-blocking, but patch looks good to me otherwise
Jun 15 18:15:16 <inz> It makes some assumptions, like the 115200 bps rate (and other serial options)
Jun 15 18:15:46 <inz> But I just needed it to work, if anyone wants to improve it further, be my guest ;)
Jun 15 18:16:24 <denkenz> yes, the entire session parsing needs to be redone to be more flexible
Jun 15 18:16:34 <denkenz> e.g. a dict of parameters instead of a single string
Jun 15 18:33:15 <akiniemi> denkenz: those could be set in a configuration file
Jun 15 18:34:15 <denkenz> perhaps, but in that case we need to get rid of .at.Manager interface
Jun 15 18:34:41 <akiniemi> denkenz: I was actually assuming it was somehow temporary ;)
Jun 15 18:34:56 <denkenz> In the beginning it was
Jun 15 18:35:00 <denkenz> Now I'm not so sure
Jun 15 18:35:07 <akiniemi> I wasn't going to have an isi.Manager
Jun 15 18:35:32 <denkenz> You probably don't need one :)
Jun 15 18:35:51 <akiniemi> Yeah, the modem appears and disappears based on netlink events instead
Jun 15 18:35:57 <denkenz> But for atplugin we have to connect to: simulators, real modems, modems over bluetooth, handsfree devices
Jun 15 18:36:51 <denkenz> Most of those can't really be detected :)
Jun 15 18:37:00 <akiniemi> Right, but at least for BT, you could probably hook into a proper udev event?
Jun 15 18:37:24 <denkenz> AFAIK there isn't one
Jun 15 18:37:52 <denkenz> I'm not talking about USB devices, I'm talking about establishing RFCOMM over the air
Jun 15 18:41:24 <denkenz> So for now I'm thinking of making at.Manager take a dict of string / variant pairs
Jun 15 18:41:40 <akiniemi> But what then drives the client to call Create method on at.Manager?
Jun 15 18:41:53 <denkenz> with something like destination, source, port, etc
Jun 15 18:42:12 <denkenz> In the case of BT, an external app
Jun 15 18:42:39 <denkenz> In the case of real hardware, we could come up with a simple config file that would be parsed by the atmodem driver
Jun 15 18:42:47 <denkenz> and just simulate the at.Manager call
Jun 15 18:43:31 <akiniemi> Yeah, it would help testing, too. Not having to dbus-send every time I restart ofonod ;)
Jun 15 18:44:02 <denkenz> Nod, feel free to send patches :)  I know holtmann wanted to do something similar
Jun 15 18:44:11 <denkenz> But we still need the at.Manager interface I feel
Jun 15 18:44:14 <holtmann> denkenz: The D-Bus interface for the atmodem needs to go away. We want a config file or udev support.
Jun 15 18:44:39 <denkenz> How will you do BT devices?
Jun 15 18:45:54 <holtmann> Plugin based with access to BlueZ.
Jun 15 18:46:20 <denkenz> explain?
Jun 15 18:46:53 <holtmann> Same as we do in ConnMan and PulseAudio. Once paired we can detect them.
Jun 15 18:47:10 <denkenz> Ugg
Jun 15 18:47:33 <denkenz> Btw, are you planning on changing obexd to do the same?
Jun 15 18:47:51 <holtmann> No really. It is actually pretty simple. To be honest we will not see it that often. And if the Bluetooth over PhoNet it works on a different level anyway.
Jun 15 18:48:18 <holtmann> obexd works fine like it is. What needs changing. It is highly integrated already.
Jun 15 18:48:36 <denkenz> Well, I'm modeling oFono sorta like how obexd works
Jun 15 18:50:36 <denkenz> And btw, for HFP oFono won't use the silly BlueZ api 
Jun 15 18:50:41 <denkenz> Not the way it is right now
Jun 15 18:51:57 <holtmann> ???
Jun 15 18:52:17 <holtmann> We have an oFono plugin in BlueZ already. What is wrong with it.
Jun 15 18:53:15 <denkenz> server side, I'm talking about client side
Jun 15 18:54:02 <denkenz> e.g. org.bluez.audio.HeadsetGateway I think
Jun 15 18:55:27 <holtmann> Ah. You mean actually building a headset. Yeah, that part is kinda under-developed.
Jun 15 18:56:37 <denkenz> Nod, and we already have a guy working on HFP inside atmodem itself
Jun 15 18:56:50 <denkenz> So for that part I still need something like at.Manager
Jun 15 19:17:07 <holtmann> Maybe, but the common hardware setup should be modem.conf or udev based.
Jun 15 19:18:08 <denkenz> Agreed, but that can be done using at.Manager just as easily
Jun 15 19:18:41 <holtmann> Not really. Wasts boot time with sending D-Bus messages around.
Jun 15 19:19:34 <denkenz> No, I meant that atmodem would _also_ have a config parser
Jun 15 19:19:48 <denkenz> and re-use the code from at.Manager for setting up the device
Jun 15 19:20:13 <holtmann> You mean that way, yes of course it would be same code. I am just not sure of having a D-Bus API for adding devices.
Jun 15 19:21:06 <denkenz> Again, I'm willing to listen to suggestions.  Right now udev or config files don't satisfy the BT HFP/Serial case
Jun 15 19:22:54 <holtmann> I have to think about that one. Didn't bother me much to be quite honest.
Jun 15 19:23:08 <denkenz> and only sorta quasi satisfy the simulator case
Jun 15 19:24:07 <denkenz> Shrug, I know, and we need to sit down and talk about HFP in detail
Jun 15 19:24:11 <holtmann> phonesim with a config file is pretty simple and straight forward.
Jun 15 19:24:38 <holtmann> Latest at PlumbersConf. I am planning to come one week early. Will send email about that soon.
Jun 15 20:20:18 <denkenz> oFono should now have full SMS reception capabilities (except EMS, WAP & SmartMessaging stuff)
**** ENDING LOGGING AT Tue Jun 16 02:59:57 2009

**** BEGIN LOGGING AT Tue Jun 16 02:59:57 2009
**** ENDING LOGGING AT Wed Jun 17 02:59:57 2009

**** BEGIN LOGGING AT Wed Jun 17 02:59:57 2009
Jun 17 10:45:22 <inz> Does the modem object only have sms-interface, if the modem is detected to support SMSes?
Jun 17 14:04:25 <balrog-kun> have people successfully sent mails to ofono@ofono.org with git-send-email?
Jun 17 14:34:57 <denkenz> inz: Yes, the interface won't show up otherwise
Jun 17 14:43:15 <Kilominha> balrog-kun: I dont know but I think inz had to configure exim and send it that way, I think he had problems aswell
Jun 17 14:56:51 <balrog-kun> Kilominha: thanks for the note, i'll try something other than git-send-email on the next attempts, for now
Jun 17 15:24:47 <denkenz> holtmann: Do you have moderator rights to the ML to approve such patches?
Jun 17 15:34:27 <holtmann> If I actually find the password. I would.
Jun 17 15:34:31 <holtmann> Why?
Jun 17 15:35:10 <denkenz> holtmann: A couple people have actually sent patches that disappeared into the void
Jun 17 15:35:27 <denkenz> holtmann: Might be useful to trawl the bounces once a week
Jun 17 15:35:39 <holtmann> Any reason they got from the ML server? Too big or something?
Jun 17 15:36:17 <denkenz> holtmann: Not sure
Jun 17 17:20:11 <inz> balrog, I got exim configured so that I got the email sent by git-send-email myself (due to CC), but it did not appear on the list
Jun 17 17:21:05 <inz> holtmann, can't be too big; I did "edit as new" in thunderbird and sent just-as-it-was, and it got through
Jun 17 17:26:42 <holtmann> inz: What do you get back from mailman for the reason?
Jun 17 17:26:55 <holtmann> If mailman doesn't answer then this is a bigger problem.
Jun 17 17:27:02 <inz> holtmann, nothing
Jun 17 17:27:13 <inz> holtmann, hmm, I'll check my gmail spam, just a sec
Jun 17 17:27:32 <holtmann> Then I am out of ideas. So which address did you use as sender?
Jun 17 17:27:47 <inz> ofono@ofono.org
Jun 17 17:28:00 <holtmann> sender.
Jun 17 17:28:05 <holtmann> Your address ;)
Jun 17 17:28:16 <inz> inz@inz.fi
Jun 17 17:30:01 <holtmann> No admin emails for that address. Are you sure your setup is correct and you are sending proper RFC compliant emails.
Jun 17 17:30:36 <inz> The message that I sent manually should got the same route
Jun 17 17:32:31 <holtmann> Can you check the logs on your side what you get back from the mailserver.
Jun 17 17:33:03 <holtmann> I don't have direct access to that machine. So I am limited here. Fallback is always just to mail the patch to Aki, Dennis and me directly (fallback only please).
Jun 17 17:34:55 <inz> hmm
Jun 17 17:44:38 <inz> Think I founds it
Jun 17 17:44:48 <inz> Jun  9 13:41:16 idle postfix/smtp[14808]: AAA594F3C6: to=<ofono@ofono.org>, relay=mail.ofono.org[174.36.13.144]:25, delay=1.6, delays=0.04/0/1.1/0.41, dsn=5.5.2, status=bounced (host mail.ofono.org[174.36.13.144] said: 504 5.5.2 <inz@l4p>: Sender address rejected: need fully-qualified address (in reply to RCPT TO command))
Jun 17 17:45:11 <inz> Where l4p is my laptop's name
Jun 17 17:45:25 <holtmann> Sounds like it.
Jun 17 17:45:37 <inz> i.e. git-send-email uses user@host for MAIL FROM:
Jun 17 17:45:59 <inz> Erm; it actually doesn't, exim does
Jun 17 17:47:21 <inz> git-send-email just does sendmail ofono@ofono.org...
Jun 17 17:49:45 <inz> So I'll need to conf exim more
Jun 17 17:51:33 <holtmann> I just use my SMTP server to git-send-email. It supports TLS and SASL so it is even secure and works fine with faking the sender address.
Jun 17 17:52:11 <inz> how'd you do that?
Jun 17 17:53:33 <inz> Ahh; found
Jun 17 17:59:06 <inz> Maybe I'll get to test it some day ;)
Jun 17 20:33:41 <balrog-kun> inz: same here, gmail accepted the mail but ofono.org didn't, so i got the cc but it didn't get through to the list
Jun 17 20:34:18 <balrog-kun> annoying the sendmail on my system didn't log it anywhere (not sure what sendmail flavour this is)
Jun 17 20:34:27 <balrog-kun> annoyingly*
Jun 17 20:37:50 <balrog-kun> oh it's ssmtp
Jun 17 21:12:45 <Robot101> .wg 'dai
Jun 17 21:12:57 * Robot101 re-orients himself at the keyboard, and tries again
**** ENDING LOGGING AT Thu Jun 18 02:59:57 2009

**** BEGIN LOGGING AT Thu Jun 18 02:59:57 2009
**** ENDING LOGGING AT Fri Jun 19 02:59:58 2009

**** BEGIN LOGGING AT Fri Jun 19 02:59:58 2009
**** ENDING LOGGING AT Sat Jun 20 02:59:57 2009

**** BEGIN LOGGING AT Sat Jun 20 02:59:57 2009
**** ENDING LOGGING AT Sun Jun 21 03:00:04 2009

**** BEGIN LOGGING AT Sun Jun 21 03:00:04 2009
**** ENDING LOGGING AT Mon Jun 22 02:59:57 2009

**** BEGIN LOGGING AT Mon Jun 22 02:59:57 2009
**** ENDING LOGGING AT Tue Jun 23 02:59:57 2009

**** BEGIN LOGGING AT Tue Jun 23 02:59:57 2009
Jun 23 07:48:45 <inz> Is there some reason why ofono counts exported networks with dbus_connection_list_registered, but then uses operator_list to fill in information
Jun 23 07:53:28 <inz> That causes a bit of a problem, should a modem report one network twice.
Jun 23 14:32:06 <denkenz> inz: Do you actually see a case like this or are you speculating?
Jun 23 15:08:06 <inz> denkenz, ran into it, ofonod crashed
Jun 23 15:09:08 <inz> denkenz, the spec doesn't really say that it should only return one entry / operator though
Jun 23 15:19:04 <denkenz> inz: Heh, the spec doesn't say alot of things
Jun 23 15:26:10 <denkenz> inz: anyways, an untested fix is in
Jun 23 15:26:28 <denkenz> inz: let me know if it solves that issue
Jun 23 16:59:47 <inz> denkenz, let's see, if it's the same as mine was =)
Jun 23 17:00:38 <denkenz> inz: Btw, feel free to post patches to the ML
Jun 23 17:01:02 <denkenz> inz: Also, can I inquire as to what you're using to test?
Jun 23 17:01:17 <holtmann> denkenz: Btw., please don't use dbus_connection_list_registered() for this stuff. It will bite you at some point.
Jun 23 17:01:36 <inz> denkenz, you can inquire, but I may not answer
Jun 23 17:02:02 <denkenz> inz: nod
Jun 23 17:02:05 <denkenz> holtmann: oh?
Jun 23 17:02:06 <holtmann> denkenz: The early BlueZ 2.x/3.x code did something similar and it was a disaster.
Jun 23 17:03:53 <denkenz> holtmann: feel free to suggest something
Jun 23 17:05:15 <inz> denkenz, seems your fix does the opposite of what mine did, but either should work
Jun 23 17:07:49 <denkenz> inz: my fix does not allow multiples, what is the opposite? :)
Jun 23 17:08:21 <inz> denkenz, make the array big enough to fit the multiples
Jun 23 17:14:38 <denkenz> inz: don't like that, reporting same path twice
Jun 23 17:15:02 <inz> denkenz, well was a good thing I didn't submit the patch to ML, 'innit ;)
Jun 23 17:15:26 <denkenz> inz: Shrug, I could always be wrong :)
Jun 23 17:15:53 <inz> denkenz, although I do think you should calculate the size of the array from the size of the data you're populating it with, not som'n that should be the same
Jun 23 17:16:41 <denkenz> inz: The problem is, I don't want to return paths that are not registered
Jun 23 17:17:03 <denkenz> inz: Which realistically shouldn't happen, but ...
Jun 23 17:20:49 <inz> The constant network scanning seems to mess up my N95
Jun 23 17:21:04 <inz> After I've done some testing with it, it always loses network connection
Jun 23 17:22:03 <inz> This is the problematic COPS answer: +COPS: (2,"SONERA","","44219",0),(2,"SONERA","","44219",2),(3,"elisa","","44250",2),(3,"dna","","44221",2),(3,"elisa","","44250",0),(3,"dna","","44221",0)
Jun 23 17:22:14 <inz> But as you know the symptoms and a fix, it's likely not too useful
Jun 23 17:22:41 <denkenz> inz: can you set the scan timeout higher?
Jun 23 17:22:49 <denkenz> inz: Its set for simulator useage right now
Jun 23 17:23:35 <inz> well, I could set it insanely high, I don't need it at all for what I'm doing
Jun 23 17:23:51 <denkenz> inz: nod, but sounds like it'll just hide the bug
Jun 23 17:23:52 <inz> It just crashed ofonod, so that was a bit of a problem
Jun 23 17:24:26 <denkenz> inz: so my fix didn't work eh? :)
Jun 23 17:24:57 <holtmann> Is this COPS non-sense that fact that some countries separate between 2G and 3G in the network list?
Jun 23 17:25:18 <denkenz> holtmann: Looks like it
Jun 23 17:25:28 <denkenz> holtmann: One is technology 2, other is technology 0
Jun 23 17:25:29 <inz> denkenz, oh it did, but it doesn't help the network-dropping on the N95
Jun 23 17:26:05 <holtmann> We are maybe to aggressive with the scanning. I was afraid that me might need quirks for different modems for this.
Jun 23 17:26:25 <denkenz> holtmann: The scan timeout is set at 300 seconds right now
Jun 23 17:26:37 <denkenz> holtmann: Its way too high, but we're only using phonesim right now
Jun 23 17:26:41 <holtmann> denkenz: Are we sorting this duplicates and combine them right now.
Jun 23 17:26:41 <inz> I really don't see any sane reason to do it when not requested
Jun 23 17:26:43 <denkenz> holtmann: So we need to bump that up
Jun 23 17:26:56 <inz> But I may just have missed some point
Jun 23 17:27:30 <denkenz> holtmann: No, I didn't think that it would report the same carrier twice with multiple tech
Jun 23 17:27:40 <denkenz> holtmann: So we need to re-encode the path to also include tech
Jun 23 17:27:59 <holtmann> inz: You do wanna scan in the background. First of all, all modem have to do that anyway in their firmware, second the UI waiting time for scans is not acceptable. We have to have results available.
Jun 23 17:28:13 <holtmann> denkenz: Why do you wanna support this non-sense.
Jun 23 17:28:36 <denkenz> holtmann: I'm not sure I do
Jun 23 17:28:38 <holtmann> denkenz: Or are these networks so bad that connecting to 44219 with tech 0 will never give you 3G.
Jun 23 17:28:56 <denkenz> holtmann: You can however register to a specific tech
Jun 23 17:29:13 <holtmann> akiniemi: Around?
Jun 23 17:29:21 <denkenz> holtmann: However, the modem is free to reselect to a different tech automagically
Jun 23 17:29:52 <holtmann> Do you know how these are internally represented. Maybe they are actually different networks and connection to the 2G one will not roam to the 3G and vise-versa.
Jun 23 17:29:52 <denkenz> holtmann: So maybe we just drop the tech entirely
Jun 23 17:29:54 <inz> Could the scan delay depend on the type of network the device is currently on?
Jun 23 17:30:08 <inz> If it's on home network, I guess the delay could be longer?
Jun 23 17:30:40 <denkenz> holtmann: They're the same network really, again the phone can reselect from 3G to 2G automagically
Jun 23 17:30:45 <holtmann> inz: Once connected we should back off and only scan on major location changes. However that is some advanced stuff.
Jun 23 17:31:14 <denkenz> inz: Nod, the intention was always to improve this
Jun 23 17:31:18 <holtmann> denkenz: I would assume that. However why to you get two results back. And not in Germany for example. We only get one.
Jun 23 17:31:28 <denkenz> inz: Also, once we have a proper multiplexer, it won't matter how often we scan
Jun 23 17:31:59 <holtmann> Are these networks clearly identified via 44219 for example. Or does the modem internally use additional identification. Hence the two results.
Jun 23 17:32:12 <holtmann> I don't know that part of the low-level GSM specs.
Jun 23 17:32:18 <holtmann> Aki might know.
Jun 23 17:32:25 <inz> denkenz, the scanning doesn't drain power?
Jun 23 17:32:53 <denkenz> inz: It does,  and we shouldn't do it too often
Jun 23 17:33:11 <holtmann> denkenz: We need to test that if connecting to the GSM one, still roams to the 3G and connection to the 3G one still roams back to GSM (if enabled).
Jun 23 17:33:23 <inz> denkenz, so even with multiplexer, it does matter ;)
Jun 23 17:33:29 <denkenz> holtmann: It does, its explicitly in 27.007
Jun 23 17:33:48 <holtmann> denkenz: If that works, then we should just combines duplicated with different techs into one network.
Jun 23 17:33:48 <inz> If you have the commands to throw at me, I can test it
Jun 23 17:33:50 <denkenz> inz: Sorta, right now the scan blocks all other commands
Jun 23 17:34:32 <denkenz> The access technology selected parameters, <AcT>, should only be used in terminals capable to register to more than one access technology. Selection of <AcT> does not limit the capability to cell reselections, even though an attempt is made to select an access technology, the phone may still re-select a cell in another access technology.
Jun 23 17:36:40 <denkenz> inz: AT+COPS=1,2,"mccmnc",<tech>
Jun 23 17:49:24 <denkenz> holtmann: It sounds like your suggestion is best, since we might not be notified of cell reselection
Jun 23 17:49:41 <denkenz> holtmann: So tracking of which operator / tech combo is probably not possible
Jun 23 17:50:02 <holtmann> Then just don't bother. Well built networks don't show you these details anyway.
Jun 23 17:50:24 <holtmann> As I said, I have seen it in Finland and one other country. That is it.
Jun 23 17:53:13 <denkenz> holtmann: The only question is how to handle the 'Technology' property
Jun 23 17:53:38 <denkenz> holtmann: We might have to get rid of it, as (at least so far) it makes no sense in the real world
Jun 23 17:53:38 <holtmann> Informational only for now.
Jun 23 17:54:04 <holtmann> We do have to show on which Tech. we are on 3G or not. That is for sure. It is a hard UI requirement.
Jun 23 17:54:23 <holtmann> Also you do wanna have an option do Disable3G like the iPhone does. But nothing more I guess.
Jun 23 17:57:51 <denkenz> holtmann: The problem is, since its not combined, tech is bogus anyway
Jun 23 17:58:46 <holtmann> As I said, you want the option to disable 3G and we need feedback if we are on 3G, EDGE or GPRS (mostly for data connection this is important).
Jun 23 17:58:47 <denkenz> holtmann: There's a separate tech being shown on NetworkRegistration, which is what is used to show 3G / no 3G
Jun 23 18:11:57 <denkenz> akiniemi: Can you test whether/what kind of CREG updates are sent when you roam from 3G to non-3G or vice versa?  We probably need to add code to query current operator if lac/ci changes.  And this might allow using mcc/mnc/tech for operator identification
Jun 23 18:12:07 <denkenz> I can't test this here unfortunately
Jun 23 21:30:04 <tuukkah> "Intel and Nokia band together" http://news.bbc.co.uk/2/hi/technology/8114059.stm
Jun 24 00:27:08 <denkenz> holtmann: Btw, it sounds like for 3G/no 3G we need proper band selection interface
Jun 24 00:27:22 <denkenz> holtmann: And that is !standard
Jun 24 00:27:51 <holtmann> denkenz: Then we have to do so. That request will come up.
Jun 24 00:28:21 <denkenz> holtmann: I know, but we do it on a separate iface, with proper band selection properties
Jun 24 00:28:57 <holtmann> I would just call it an implementation detail and let the actual driver implement it.
Jun 24 00:29:35 <denkenz> holtmann: It is, but we need to do some research into what is commonly implemented
Jun 24 00:30:06 <denkenz> holtmann: Also, band selection affects GPRS Network Reg
Jun 24 00:30:08 <holtmann> Don't ask me here. I assumed the AT commands to select one specific technology are sufficiant.
Jun 24 00:30:28 <denkenz> holtmann: So I don't want it on the NetworkRegistration interface
Jun 24 00:31:02 <denkenz> holtmann: Sorta, there's all sorts of combinations, e.g. 3G only, 3g preferred, 2G only
Jun 24 00:31:28 <denkenz> Whoever wrote this spec needs to be shot
Jun 24 00:31:39 <holtmann> Multiple times to be sure.
Jun 24 00:32:10 <holtmann> So from my understanding the only one that makes sense is 2G only to save power for this specific case. All the other ones are non-sense.
Jun 24 00:32:34 <denkenz> holtmann: Don't know, some people use 3G only 
Jun 24 00:32:58 <denkenz> holtmann: Which might not make sense for a phone, but makes sense for data only devices
Jun 24 00:33:35 <holtmann> That is actually an illusion that it makes sense.
Jun 24 00:33:54 <holtmann> 3G only is a real problem since there are still gaps in the coverage.
Jun 24 00:34:21 <denkenz> holtmann: I know, or because some hardware is broken and doesn't select 3G properly if 2G is better
Jun 24 00:34:29 <denkenz> better = signal strength
Jun 24 00:35:20 <holtmann> Some modem firmware is pretty much crap when it comes to switching.
Jun 24 00:35:33 <denkenz> holtmann: However, this seems to indicate that same mccmnc reported multiple times is crap
Jun 24 00:36:01 <denkenz> holtmann: And that the proper way is to use proper Band selection
Jun 24 00:36:32 <holtmann> That is what I am thinking, too. However I am not an expert in low-level GSM stuff.
Jun 24 00:36:51 <holtmann> I don't even know how these networks fake the scan results to show up as two.
Jun 24 00:37:23 <denkenz> holtmann: Nod, and I don't know whether AT+COPS=0,,,<tech> is even acceptable
Jun 24 00:37:30 <denkenz> holtmann: Probably not :P
**** ENDING LOGGING AT Wed Jun 24 02:59:57 2009

**** BEGIN LOGGING AT Wed Jun 24 02:59:57 2009
Jun 24 08:02:53 <zgli> hi all,
Jun 24 08:03:35 <zgli> Could somebody know why connect-phonesim doesn't work with latest ofono?
Jun 24 09:32:12 <akiniemi> denkenz, inz: regarding tech and separate operators...
Jun 24 09:32:44 <akiniemi> that seems to be a quirk of the AT interface; using the native i/f, the operator is only listed once
Jun 24 09:34:08 <akiniemi> there is also a UMTS available flag per operator, and registration can be 2G only, 3G only, or dual mode, which will switch techs as necessary 
Jun 24 09:35:50 <akiniemi> denkenz: I'm also bit on the fence regarding background network scanning. It seems quite expensive compared to how often the results generally are required. Most people use automatic mode.
Jun 24 09:45:22 <holtmann> akiniemi: So it is all non-sense as we assumed with the double COPS results.
Jun 24 09:46:01 <holtmann> akiniemi: We need to improve the background scanning. As I said, we can detect big movements due to cell changes and location changes.
Jun 24 09:46:07 <inz> It's probably just broken H/W I have; but I think the case should be handled somehow
Jun 24 09:46:20 <inz> Maybe there's some other implementation that does the same
Jun 24 09:46:37 <holtmann> It is network specific as far as I know. Never seen it in Germany.
Jun 24 09:46:47 <holtmann> Anyway, I am off for the next few hours.
Jun 24 14:46:47 <denkenz> akiniemi: We need to make background scanning smarter I don't deny that
Jun 24 14:47:25 <denkenz> akiniemi: I'm also thinking we stop background tasks when we enter suspend mode
Jun 24 14:47:44 <denkenz> akiniemi: And resume only after wakeup & if the cell has changed
Jun 24 14:56:33 <denkenz> inz: There are a couple of options to handle multiple COPS thing
Jun 24 14:57:20 <denkenz> inz: 1 - Drop all multiply listed operators and drop the Tech attribute from NetworkOperator interface.  Then hope that BandSelection settings and AT+COPS are sufficient
Jun 24 14:58:06 <denkenz> inz: 2 - Track operators by mcc, mnc and tech.  This is a bit tricky since we must also update the current operator when tech changes
Jun 24 14:58:50 <denkenz> I'm leanin towards #1 as that makes the information presented to the UI more consistent
Jun 24 15:07:19 <inz> denkenz, #1 sounds good, for me it is enough that it doesn't crash ;)
**** ENDING LOGGING AT Thu Jun 25 02:59:57 2009

**** BEGIN LOGGING AT Thu Jun 25 02:59:57 2009
Jun 25 15:07:18 <anthm> hello
**** ENDING LOGGING AT Fri Jun 26 02:59:57 2009

**** BEGIN LOGGING AT Fri Jun 26 02:59:57 2009
Jun 26 08:37:32 <holtmann> usr/bin/ld: Dwarf Error: Offset (560) greater than or equal to .debug_str size (337).
Jun 26 08:37:32 <holtmann> plugin.o:(.data+0x18): undefined reference to `__ofono_builtin_phonet'
Jun 26 08:37:33 <holtmann> collect2: ld returned 1 exit status
Jun 26 08:38:38 <holtmann> Nevermind. I new bootstrap-configure call fixed it.
**** BEGIN LOGGING AT Fri Jun 26 10:29:06 2009
Jun 26 11:41:31 <inz> holtmann, there are some things in the build process that could be improved
Jun 26 11:42:21 <inz> IMO it's quite nasty that you have to make clean if you do changes in the support libs
Jun 26 11:42:27 <inz> (or rm src/ofonod ;)
Jun 26 12:31:23 <holtmann> That is clearly a bug I have to fix.
Jun 26 15:26:16 <courmisch> I had a fix for that
Jun 26 15:26:21 <courmisch> but it's dangling in aki's tree
Jun 26 15:26:48 <courmisch> DEPENDENCIES on ofonod shound include the imported .la files
**** ENDING LOGGING AT Sat Jun 27 02:59:56 2009

**** BEGIN LOGGING AT Sat Jun 27 02:59:56 2009
**** ENDING LOGGING AT Sun Jun 28 02:59:57 2009

**** BEGIN LOGGING AT Sun Jun 28 02:59:57 2009
**** ENDING LOGGING AT Mon Jun 29 02:59:56 2009

**** BEGIN LOGGING AT Mon Jun 29 02:59:56 2009
Jun 29 17:55:29 <akiniemi> courmisch: I just pushed that patch in, with a small modification
Jun 30 00:37:01 <dilinger> holtmann: hi.  what hardware have you been playing around with/testing ofono with?
Jun 30 00:37:27 <holtmann> dilinger: I haven't used any hardware so far. Denis worked with the OpenMoko phone.
Jun 30 00:39:10 <holtmann> akiniemi: What are these bootstrap-configure fixes about. It is suppose to be called from the toplevel dir only.
Jun 30 00:42:06 <dilinger> holtmann: ok, thanks.
Jun 30 00:43:19 <dilinger> (does anyone else who might also be using ofono have hardware suggestions?)
Jun 30 00:49:29 <holtmann> Nokia will be using PhoNet.
Jun 30 00:50:26 * dilinger nods
Jun 30 00:50:33 <dilinger> i saw the phonet driver
Jun 30 00:51:53 <dilinger> it looked much smaller than the atmodem driver, though (not sure if isimodem is layered on top of atmodem, or they're both standalone)
**** ENDING LOGGING AT Tue Jun 30 02:59:57 2009

**** BEGIN LOGGING AT Tue Jun 30 02:59:57 2009
Jun 30 03:54:33 <denkenz> dilinger: isimodem is an even more of a work in progress than atmodem driver
Jun 30 03:59:25 <dilinger> okay
Jun 30 04:00:17 <dilinger> i'm not picky, i'm just looking for hardware that i can test ofono with (and if i run into hardware issues, ideally bug someone in here to see how/if they bypassed them)
Jun 30 04:03:23 <denkenz> dilinger: About your only choices are FreeRunner or other hacked linux phones (e.g. Android ones or EZX ones)
Jun 30 04:03:51 <denkenz> dilinger: You might also be able to use phones over Bluetooth Serial as well
Jun 30 04:04:06 <denkenz> dilinger: And eventually Nokia phones once that driver is more feature complete
Jun 30 04:07:25 <dilinger> denkenz: i'm assuming you've got the ofono stack on top of one of the standard openmoko distributions and kernels?
Jun 30 04:07:54 <denkenz> dilinger: Nope, oFono is not aiming for a particular platform or hardware
Jun 30 04:08:34 <denkenz> dilinger: We're focused on enabling all features first, then concentrate on integration
Jun 30 04:08:35 <dilinger> denkenz: i mean for your testing..
Jun 30 04:09:00 <denkenz> dilinger: Nah, ser2net / netcat on the Neo exporting via tcp
Jun 30 04:09:47 <denkenz> dilinger: Though it cross-compiles just fine last I checked 
Jun 30 04:10:11 <dilinger> so you've got ofono running on a separate linux host, controlling the 'moko through serial?  interesting.
Jun 30 04:10:34 <denkenz> dilinger: Yep, moko via usbnet + ser2net is my setup
Jun 30 04:11:31 <dilinger> great, that sounds easier than what i'd been anticipating.  thanks!
Jun 30 04:12:44 <denkenz> just make sure to use "ti_calypso" as the driver and pass CFUN=1 before giving the modem to oFono, the CFUN command is not yet handled
Jun 30 04:21:06 <dilinger> ok, thanks
Jun 30 11:02:27 <courmisch> akiniemi: thanks
**** ENDING LOGGING AT Wed Jul 01 02:59:57 2009

**** BEGIN LOGGING AT Wed Jul 01 02:59:57 2009
Jul 01 10:37:07 <akiniemi> dilinger: the isimodem driver is going to be standalone, just like atmodem
Jul 01 10:37:26 <akiniemi> dilinger: it's just very much a work in progress
Jul 01 10:38:08 <akiniemi> dilinger: plus there is some userspace stuff missing, plus a CDC PhoNet kernel driver missing to be able to use a Nokia/ISI modem via USB
Jul 01 10:38:17 <akiniemi> dilinger: we're working on those, too
Jul 01 10:40:59 <courmisch> holtmann: bootstrap arguably yes. configure NO
Jul 01 10:41:37 <courmisch> autoconf explicitly supports build from subdir, which is needed for distcheck to work, not to mention that it is quite nicer than building from 
Jul 01 10:41:40 <courmisch> .
Jul 01 10:42:04 <courmisch> I agree that bootstrap from subdir is pointless, but then configure should be untangled from bootstrap
Jul 01 11:04:27 <akiniemi> holtmann: thanks for integrating thet tty patch, BTW. I had it sitting in my tree, completely forgot about it. :)
Jul 01 11:34:43 <Sage> Is there any plans to apply the following tty patch http://lists.ofono.org/pipermail/ofono/2009-June/000123.html ?
Jul 01 11:40:15 <holtmann> akiniemi: Please it or not, but I need that for ConnMan. However we have to improve details here or remove it later on if it gets too complicated.
Jul 01 11:40:19 <Sage> Just wondering if that has been forgotten or if there is a reason not to apply it.
Jul 01 11:40:27 <holtmann> s/Please/Believe/
Jul 01 11:41:46 <holtmann> Sage: Most likely it got missed. Looks good to me. Except for the sob line. We don't do that. This is not the kernel.
Jul 01 11:51:41 <akiniemi> Sage: I meant to push it, but just got sidetracked. I actually thought holtmann did that already, but that seems to be an unrelated tty patch. . Stay tuned, will Ãpush.
Jul 01 11:52:20 <holtmann> akiniemi: Please do git commit --amend and remove the signed-off-by line.
Jul 01 11:52:31 <holtmann> Before you push.
Jul 01 12:01:44 <akiniemi> holtmann: yeah
Jul 01 15:34:40 <holtmann> gatresult.c: In function ‘g_at_result_iter_next_hexstring’:
Jul 01 15:34:40 <holtmann> gatresult.c:165: warning: ‘bufpos’ may be used uninitialized in this function
Jul 01 15:44:54 <denkenz> lemme check
Jul 01 15:46:34 <denkenz> yeah, that's obviously wrong
Jul 01 15:49:58 <denkenz> about to push fix
Jul 01 15:50:27 <denkenz> pushed
Jul 01 15:51:17 <holtmann> Thanks.
Jul 01 15:59:35 <denkenz> akiniemi: Do you have any sample of a Cell Broadcast PDU with multiple pages?
Jul 01 17:39:17 <akiniemi> denkenz: nope, just a single paged one
Jul 01 17:50:52 <denkenz> akiniemi: Do you know whether they're even used in practice?
Jul 01 17:51:11 <denkenz> akiniemi: The spec is completely idiotic
Jul 01 17:56:08 <akiniemi> denkenz: dunno.
Jul 01 17:57:41 <denkenz> akiniemi, holtmann: Can we fix it so that oFono does not build the isi stuff if the kernel is not capable of it?
Jul 01 17:57:59 <denkenz> akiniemi, holtmann: It fails miserably and I'm getting ton of whines internally
Jul 01 18:05:30 <courmisch> kernel shouldn't be a problem... headers more so
Jul 01 18:09:48 <akiniemi> courmisch: how about just including a local copy of phonet.h?
Jul 01 18:11:19 <inz> Where does the ACK PDU for Status Reports in the AT modem come from; the 0340 doesn't seem to have RP-ACK for SMS-STATUS-REPORT
Jul 01 18:12:24 <denkenz> From CMGS
Jul 01 18:13:03 <denkenz> And atmodem doesn't handle status reports
Jul 01 18:13:11 <denkenz> And I'm not sure it ever will
Jul 01 18:13:16 <courmisch> ugly but feasible
Jul 01 18:14:29 <akiniemi> courmisch: maybe some configure.ac magic to go along with it, like checking for system copy first, then falling back to the local one with a big fat warning?
Jul 01 18:15:00 <denkenz> akiniemi: Can't we just have a simple compile check and disable the plugin if that fails?
Jul 01 18:15:07 <courmisch> this might get problematic if we ever extend it
Jul 01 18:16:04 <courmisch> I'd rather put the missing define via individual configure checks
Jul 01 18:16:20 <courmisch> it's just one constant and one struct really
Jul 01 18:16:34 <akiniemi> denkenz: I really want gisi and especially the isimodem driver to always build with the rest
Jul 01 18:17:13 <courmisch> denkenz: the build kernel headers is often unrelated to the run-time kernel though
Jul 01 18:17:13 <akiniemi> courmisch: works for me. Patch ready? ;)
Jul 01 18:17:14 <denkenz> akiniemi: And it will be in 99% of the cases anyway, since most people will have sane kernels by the time gisi is ready
Jul 01 18:17:33 <inz> denkenz, from CMGS? what does it say about ACK for +CDS?
Jul 01 18:17:52 <denkenz> inz: CDS has to be acked with a CNMA
Jul 01 18:17:53 <courmisch> denkenz: that's precisely why we don't want it silently disabled during the build
Jul 01 18:18:10 <inz> denkenz, yes, it does, but I was wondering what the PDU is
Jul 01 18:18:29 <denkenz> inz: Shrug, check smsutil.c, the PDU can be generated there
Jul 01 18:18:38 <denkenz> inz: Or 23.040
Jul 01 18:18:53 <denkenz> inz: We always send RP-ACK for success
Jul 01 18:19:17 <inz> denkenz, it seems to be the same as what is used for +CMT, but the 03.40 (or 23.040) doesn't list a RP-ACK for status reports at all
Jul 01 18:19:17 <denkenz> courmisch: I think you guys are blowing this out of proportion
Jul 01 18:19:46 <denkenz> inz: Yeah, the deliver ack is always used I think
Jul 01 18:19:54 <courmisch> if maintaining the VLC build system for 5 years told me something...
Jul 01 18:20:10 <courmisch> it's that silently enabling/disabling features causes lots of problems with distro packaging
Jul 01 18:20:32 <denkenz> So make an explicit --enable and fail if the plugin was asked for but couldn't be built
Jul 01 18:20:35 <courmisch> as well as new devs compiling from source
Jul 01 18:20:57 <courmisch> denkenz: I would suggest exactly that if it were an underlying library
Jul 01 18:21:04 <courmisch> but it's just a set of definitions here...
Jul 01 18:21:16 <denkenz> which is different how? :)
Jul 01 18:21:53 <inz> denkenz, but if I interpret the spec correctly, there isn't applicable RP-ACK for those; so you could just do AT+CNMA=1
Jul 01 18:21:56 <courmisch> how do you replace a missing libavcodec with configure checks?
Jul 01 18:22:19 <courmisch> you don't - how do you replace a missing typedef? you typedef it
Jul 01 18:22:34 <denkenz> inz: Theoretically you don't need to send the PDU even for regular delivers
Jul 01 18:22:40 <denkenz> inz: CNMA=1 is enough
Jul 01 18:23:04 <denkenz> inz: I have to check 23.040, but I think it said that status reports are acked using deliver ack pdu
Jul 01 18:23:07 <inz> denkenz, true, but for those you have a spec that says what you can respond
Jul 01 18:24:26 <inz> denkenz, don't bother, found it
Jul 01 18:24:45 <inz> denkenz, weird that there's no word on it in the SMS-STATUS-REPORT -section, only in the SMS-DELIVER-REPORT
Jul 01 18:24:59 <denkenz> inz: Yeah, its a crap spec
Jul 01 18:25:20 <denkenz> inz: Btw, if you want, submit a patch that explains why we ack the +CDS using deliver ack PDU
Jul 01 18:25:30 <denkenz> inz: Referring to the particular section
Jul 01 18:25:58 <inz> Nah, I bet no one else really cares ;)
Jul 01 18:26:02 <denkenz> courmisch, akiniemi: Guys, I don't care really about the implementation, I just want the whining to stop from people running old kernels ;)
Jul 01 18:26:38 <inz> It was easy 'nuff to implement a --disable-phonet -flag to configure to get it compile
Jul 01 18:26:46 <inz> Some ppl are just lazy
Jul 01 18:29:14 <courmisch> denkenz: one thing is sure - I am not going to fix it outside my office hours
Jul 01 18:29:16 <courmisch> :P
Jul 01 18:30:28 <denkenz> courmisch: Heh, I just want it fixed before release, which is about 4 days overdue ;)
Jul 01 19:11:21 <akiniemi> Just pushed the tty patch in. Thanks inz!
Jul 01 19:18:44 <denkenz> akiniemi is a workaholic, btw, reply to the ML too ;)
Jul 01 19:48:05 <akiniemi> denkenz: Simple, I always work until sunset. You won't see me much in Nov ;)
Jul 01 19:51:52 <denkenz> akiniemi: Lol, we just have to ship you off to Australia
Jul 01 19:56:49 <akiniemi> denkenz: it's a deal ;)
Jul 01 19:58:43 <denkenz> akiniemi: Hehe nod, its a great place if you don't mind the locals :)
Jul 01 20:08:42 <courmisch> actually between the two tropics would be best in that regard (_not_ that I would want to go there)
Jul 01 20:09:12 <denkenz> courmisch: Well the Nokia office in Brisbane is nearly there, like ~1 degree off
Jul 01 20:09:36 <courmisch> akiniemi: I don't need to remind you that overtime "IS NOT ALLOWED"
Jul 01 20:09:39 <courmisch> :)
Jul 01 20:12:18 <courmisch> hmm, but the funny feeling when going to bed at 4AM right while the sun is rising is so unique
Jul 01 20:12:58 <courmisch> "Sun rises 4:01 and sets 22:47. Length of day is 18 h 46 min."
Jul 01 20:29:46 <akiniemi> courmisch: what?!? Seems I never got that memo... ;)
Jul 01 21:47:49 <holtmann> akiniemi: You are talking about missing header files from the kernel, right?
Jul 01 21:52:47 <denkenz> holtmann: define missing? We're talking about linux/phonet.h and friends
Jul 01 21:53:57 <holtmann> So for WiFi, we have one file that contains the netlink definitions. That just gets copied to userspace and kept in sync.
Jul 01 21:55:49 <denkenz> well at least on my distro phonet.h is included in linux-headers
Jul 01 21:56:14 <denkenz> but on older distros the linux-headers are not recent enough
Jul 01 22:10:11 <denkenz> From 23.041: "NOTE 5:	Code 00 is intended for use by the network operators for base station IDs."
Jul 01 22:10:31 <denkenz> What do you guys think of a new NetworkRegistration interface property which holds this value?
Jul 01 22:10:51 <denkenz> This is for a Cell Broadcast with Geo Scope == 00
**** ENDING LOGGING AT Thu Jul 02 02:59:57 2009

**** BEGIN LOGGING AT Thu Jul 02 02:59:57 2009
**** BEGIN LOGGING AT Thu Jul 02 10:34:15 2009
Jul 02 23:07:45 <dilinger> yeah, the phonet header stuff is kind of annoying
Jul 02 23:12:58 <dilinger> though it's not the only problem one runs into when building with older kernel headers (ie, debian's 2.6.26)
**** ENDING LOGGING AT Fri Jul 03 02:59:57 2009

**** BEGIN LOGGING AT Fri Jul 03 02:59:57 2009
Jul 03 09:38:33 <akiniemi> dilinger: courmisch just sent me a set of patches that will fix this. Pushing them in a bit.
Jul 03 13:59:14 <dilinger> akiniemi: cool.  don't forget the phonet stuff in ./gisi/netlink.c
Jul 03 13:59:45 <dilinger> specifically, RTNLGRP_PHONET_IFADDR's usage (which isn't in older versions of linux/rtnetlink.h)
Jul 03 14:24:17 <courmisch> that one is trickier t ofix
Jul 03 14:24:28 <courmisch> because it is an enum, not a define
Jul 03 14:26:37 <holtmann> Okay. So I am thinking that we better check for proper kernel version and if not available, disable GISI at all.
Jul 03 14:26:52 <holtmann> courmisch: Can you sent the patches to the mailing list for review.
Jul 03 14:33:52 <courmisch> only if remi.denis-courmont@nokia.com is whitelisted for posting
Jul 03 14:34:15 <courmisch> the Microsoft mail server is so broken
Jul 03 14:36:08 <holtmann> Then attach the patch.
Jul 03 14:36:22 <holtmann> If you are subscribed to ofono@ofono.org then it is fine.
Jul 03 14:36:42 <holtmann> Also you can subscribe with two email addresses and set one to NOMAIL. That is what I normally do.
Jul 03 14:37:05 <courmisch> I know and I would normally do that
Jul 03 14:37:15 <courmisch> but it seems that the ofono mailer is blacklisted
Jul 03 14:37:35 <courmisch> so I cannot even answer to the subscribe request
Jul 03 14:38:24 <holtmann> That is not a problem on our side. Or is it. That is a Nokia IT problem?
Jul 03 14:39:03 <courmisch> I do not know if it is a problem with the Microsoft-provided Nokia spam filter, or with ofono.org
Jul 03 14:39:24 <courmisch> likely the earlier
Jul 03 14:42:32 <holtmann> Send them to marcel@holtmann.org and see if that works.
Jul 03 14:43:47 <courmisch> well sending email does work
Jul 03 14:43:57 <courmisch> it is receiving from ofono.org that does not work
Jul 03 14:44:04 <courmisch> hence I cannot subscribe
Jul 03 14:44:09 <courmisch> hence I cannot post to the mailing list
Jul 03 14:44:15 <holtmann> What? That is so weird. Then it is a Nokia problem.
Jul 03 14:45:42 <courmisch> I think ofono.org is hitting some anti-spam rule for some reason
Jul 03 14:46:22 <holtmann> Maybe it used to be a porn URL.
Jul 03 14:46:31 <holtmann> Yeah :)
Jul 03 14:49:15 <courmisch> posted as attachment anyway
Jul 03 14:53:35 <holtmann> I am scared now. Let's please not do it this way. Just ensure that we have a proper kernel includes available and if not disable GISI.
Jul 03 14:53:47 <holtmann> Patch 001 is fine though. I am going to apply that one.
Jul 03 14:56:26 <holtmann> courmisch: Let me work on this a little bit.
Jul 03 14:56:53 <holtmann> It should be possible to get this done the right way without making our life hard with deps and extra hacks.
Jul 03 14:56:56 <courmisch> well considering there is no userland support from glibc even now
Jul 03 14:57:16 <holtmann> the AF_PHONET is fine. That is not the problem.
Jul 03 14:57:22 <courmisch> nobody except me is going to be able to use it for a long time
Jul 03 14:57:34 <holtmann> We have been using AF_BLUETOOTH hacks like that for ages and that is included since a long time.
Jul 03 14:58:16 <holtmann> So my take on this one is. If you don't have kernel headers for this. Then not compile it in. Since it will not work anyway.
Jul 03 14:58:21 <courmisch> well I can ship a separate header file if you don t want to clutter config.h
Jul 03 14:58:32 <courmisch> but I doubt the autodetect option is practical in the short term
Jul 03 14:58:34 <holtmann> Do you have everything in one header file?
Jul 03 14:58:49 <courmisch> not yet
Jul 03 14:58:58 <courmisch> since AF_PHONET and PF_PHONET are suppoosed to be in sys/socket.h 
Jul 03 14:59:05 <holtmann> If yes, then lets ship that one. And only check for the missing netlink feature.
Jul 03 14:59:08 <courmisch> and RTNLGRP_... in linux/rtnetlink.h
Jul 03 14:59:31 <holtmann> ifdef AF_PHONET. That is what everybody else is doing and that is just fine. GLibc inclusion will take a year or two.
Jul 03 14:59:37 <courmisch> the only thing that fits cleanly in a header file is the sockaddr :(
Jul 03 14:59:55 <courmisch> ifdef trick wont work for RTNL
Jul 03 15:00:25 <courmisch> because it is an enum, it will choke on those people with recent kernel headers
Jul 03 15:00:30 <holtmann> Check /usr/include/bluetooth/bluetooth.h. We have been shipping that for ages since kernel includes are a pain in the ass.
Jul 03 15:00:46 <holtmann> Just create a phonet.h that includes everything you need and then we ship that.
Jul 03 15:00:56 <courmisch> holtmann: I need to include rtnetlink.h for other stuff...
Jul 03 15:01:02 <courmisch> I cannot make something that conflicts with it
Jul 03 15:02:06 <holtmann> I am confused now.
Jul 03 15:02:21 <courmisch> #define RTNLGRP_PHONET_IFADDR xxx
Jul 03 15:02:28 <courmisch> will conflict with recent version of rtnetlink
Jul 03 15:02:38 <courmisch> syntax error in the enum
Jul 03 15:03:09 <holtmann> 	RTNLGRP_PHONET_IFADDR,
Jul 03 15:03:09 <holtmann> #define RTNLGRP_PHONET_IFADDR	RTNLGRP_PHONET_IFADDR
Jul 03 15:03:09 <holtmann> 	RTNLGRP_PHONET_ROUTE,
Jul 03 15:03:09 <holtmann> #define RTNLGRP_PHONET_ROUTE	RTNLGRP_PHONET_ROUTE
Jul 03 15:03:09 <holtmann> 	__RTNLGRP_MAX
Jul 03 15:03:18 <holtmann> And you can't ifdef or detect it why?
Jul 03 15:03:42 <courmisch> we can... but then we need to pre-include rtnetlink.h (and sys/socket.h)
Jul 03 15:04:00 <courmisch> oh well if it is just one file that needs it maybe
Jul 03 15:04:08 <holtmann> And that is a problem why?
Jul 03 15:04:45 <holtmann> Just help me here to understand the actual problem with just providing one phonet.h file that defines the kernel details you need.
Jul 03 15:05:09 <courmisch> I am really not keen on ripping large parts of rtnetlink
Jul 03 15:05:23 <holtmann> You don't have to.
Jul 03 15:05:50 <holtmann> Just include linux/rtnetlink.h in the new userspace phonet.h and then ifdef around the missing details.
Jul 03 15:21:22 <courmisch> what about this one ten?
Jul 03 15:21:23 <courmisch> then*
Jul 03 15:22:32 <holtmann> 0001 is already pushed upstream :)
Jul 03 15:23:18 <courmisch> wasnot when I checked
Jul 03 15:23:33 <courmisch> still is not
Jul 03 15:23:34 <holtmann> kernel.org might be slow today :(
Jul 03 15:23:42 <holtmann> That looks way better.
Jul 03 15:24:21 <holtmann> However 0003? Is that really needed. Why don't we always include local phonet.h until GLibc or kernel are actually present on all distros. Any downside on that?
Jul 03 15:26:21 <courmisch> it avoids a flag day
Jul 03 15:27:22 <holtmann> We can always use the local copy. Never hurt the Bluetooth subsystem.
Jul 03 15:27:43 <holtmann> One less bit to test when building releases etc.
Jul 03 15:28:29 <holtmann> You know what. Just let us use the local copy for now. This way we can speed up the development. And introducing the check for kernel copy vs our copy can be done at any time.
Jul 03 15:32:11 <courmisch> pfff, there you go
Jul 03 15:32:22 <holtmann> 0002 has been pushed now.
Jul 03 15:32:36 <courmisch> server info are not up to date I guess
Jul 03 15:33:14 <holtmann> Can you send me 0003 that just uses phonet.h and also includes it into Makefile.am (otherwise make distcheck breaks).
Jul 03 15:35:40 <courmisch> aarg
Jul 03 15:35:50 <courmisch> I should have known to run distcheck
Jul 03 15:37:34 <holtmann> git repo should be up-to-date now btw.
Jul 03 15:37:46 <courmisch> nope
Jul 03 15:38:02 <courmisch> at least not with http
Jul 03 15:39:31 <holtmann> I am using git:// all the time.
Jul 03 15:39:45 <holtmann> Let me guess. Stupid firewall.
Jul 03 15:40:46 <courmisch> while it is from my perspective, it might actually be useful in protecting those non-technical windows users against themselves
Jul 03 15:41:20 <courmisch> but most importantly, IT dept has no incentive to unblock the git port since the CEO does not want it
Jul 03 15:41:43 <holtmann> Nope. That is stupid IT. Once you open one port you can as well open all of them. Everything can be tunneled.
Jul 03 15:42:00 <holtmann> We are talking about outgoing traffic here and not incoming.
Jul 03 15:42:49 <holtmann> http://git.kernel.org/?p=network/ofono/ofono.git;a=summary
Jul 03 15:43:03 <holtmann> I do see them though. However US mirror are different than EU mirrors.
Jul 03 15:43:12 <holtmann> Try git.us.kernel.org :)
Jul 03 15:44:10 <courmisch> that does not work at all
Jul 03 15:44:16 <courmisch> but now it s up to date
Jul 03 15:48:07 <holtmann> And I pushed your use-phonet patch now. Should be all good.
Jul 03 15:48:21 <holtmann> Thanks.
**** ENDING LOGGING AT Sat Jul 04 02:59:57 2009

**** BEGIN LOGGING AT Sat Jul 04 02:59:57 2009
**** ENDING LOGGING AT Sun Jul 05 02:59:58 2009

**** BEGIN LOGGING AT Sun Jul 05 02:59:58 2009
**** ENDING LOGGING AT Mon Jul 06 02:59:56 2009

**** BEGIN LOGGING AT Mon Jul 06 02:59:56 2009
Jul 06 06:59:53 <akiniemi> Build is borked for me: socket.c:84: undefined reference to `pn_sockaddr_get_object'
Jul 06 07:00:13 <akiniemi> This should give a warning for the rest of you not using gisi, no?
Jul 06 07:02:53 <inz> hey, what would be the correct way to convert a number to the international format?
Jul 06 07:03:07 <inz> Should I use the country code where the phone is currently (and if, where to obtain it)
Jul 06 07:03:30 <inz> Or the "home" country code
Jul 06 07:29:55 <courmisch> inz: it is the country you are in (not the SIM card country )
Jul 06 07:30:43 <inz> courmisch, thanks
Jul 06 07:48:54 <inz> Should I then have a MCC => Area Code mapping and use the MCC of current network?
Jul 06 07:52:32 <inz> Does anyone know of such list?
Jul 06 07:53:11 <inz> Also, it would be quite nice to have some easier way to find the current operator than browsing through the AvailableOperator objects and asking which has "Status" == "current"
Jul 06 07:53:39 <inz> Like property "CurrentOperator" or similar
Jul 06 08:19:52 <inz> Hmm, didn't find such mapping, but was able to generate one
Jul 06 08:20:03 <inz> If anyone needs it, poke me =)
Jul 06 08:36:50 <inz> Armh, now I recall that the MCC/MNC export was removed at some point; so I only get it from the object path (which isn't too nice)
Jul 06 09:08:36 <akiniemi> inz: What do you mean removed?
Jul 06 09:09:28 <inz> akiniemi, or then it was never implemented, not sure, I just recall it being discussed at some point
Jul 06 09:09:46 <inz> akiniemi, anyway, the D-Bus interface doesn't tell the MCC (except in the object path)
Jul 06 09:10:15 <akiniemi> inz: Right, via NetworkRegistration i/f, but itÃ's there in NetworkOperator i/f
Jul 06 09:11:41 <inz> Hmm, must've read the wrong place, indeed it is there.
Jul 06 09:12:57 <inz> Ah, yes, I was reading the dbus-monitor print, and indeed no PropertyChanged signals are sent for it (which kind of makes sense, as it cannot change ;)
Jul 06 09:13:32 <inz> I guess I was doing /"MCC" in the source, which obviously gives no hits, as it's "MobileCountryCode"
Jul 06 09:14:21 <inz> But do I really have to listen to all operators found ever and check which one is in "current" state to get the current oper...
Jul 06 09:14:53 <akiniemi> inz: I agree a CurrentOperator property that gives an object path would make sense...
Jul 06 09:15:18 <akiniemi> inz: ...in NetworkRegistration interface
Jul 06 09:15:34 <inz> Yup, would be rly nice
Jul 06 15:48:49 <denkenz> inz: Most applications rarely if ever need the operator information, are you using this specifically to find the local dialing code?
Jul 06 16:02:44 <inz> denkenz, yes
Jul 06 16:03:43 <inz> denkenz, is there some harm in making access to current operator easy?
Jul 06 16:03:50 <denkenz> inz: I'm actually thinking that country dialing codes should be part of oFono
Jul 06 16:04:06 <denkenz> inz: Available on NetworkReg iface
Jul 06 16:04:17 <denkenz> inz: NetworkOperator is really only intended for Manual Registration app
Jul 06 16:04:35 <denkenz> inz: But I'm open to adding OperatorPath to NetworkReg iface as well
Jul 06 16:04:39 <denkenz> care to submit a patch?
Jul 06 16:06:26 <inz> I'd love to, but I'll need to figure out some bureaucratic things and it's pending due to vacations...
Jul 06 16:06:32 <inz> Better if you (or someone else) does it.
Jul 06 16:06:54 <inz> (don't ask, it's complicated ;)
Jul 06 16:07:36 <denkenz> inz: nod, for now you're the only one with this itch ;)
Jul 06 16:08:22 <inz> Well, if no one else has the itch for ~two months, I guess I can create and submit the patch... ...eventually
Jul 06 16:09:52 <inz> I obtained the mcc => idc list with wikipedia and Telephony::CountryDialingCodes; don't really know if either (or both) is out of date.
**** ENDING LOGGING AT Tue Jul 07 03:00:06 2009

**** BEGIN LOGGING AT Tue Jul 07 03:00:06 2009
**** BEGIN LOGGING AT Tue Jul 07 04:18:13 2009
Jul 07 15:50:39 <inz> Hmm, why is the operator obtained with AT+COPS? flagged with status -1; isn't that always current operator (and thus 2)
Jul 07 15:51:37 <denkenz> I'm pretty sure the daemon ignores the status in that case
Jul 07 15:51:51 <denkenz> it knows its current anyway 
Jul 07 15:51:57 <inz> denkenz, I mean the daemon flags it as -1
Jul 07 15:52:21 <denkenz> can you tell me line number and file?
Jul 07 15:53:11 <inz> drivers/atmodem/network-registration.c:181
Jul 07 15:54:49 <denkenz> Yeah, so if you look at what current_operator_callback does in src/network.c
Jul 07 15:54:58 <denkenz> You'll see that status is ignored :)
Jul 07 15:55:23 <denkenz> daemon implicitly knows that status == 2
Jul 07 15:58:04 <inz> Hmm, weird, it doesn't seem to work though.
Jul 07 15:58:50 <inz> I get "unknown" with get_properties, until the first +COPS=?
Jul 07 15:59:07 <inz> At which point I get a PropertyChanged for Status = current
Jul 07 15:59:28 <inz> When I changed that = -1 to = 2, it works correctly...
Jul 07 16:01:54 <inz> It seems to me that the operator is flagged as current in that function only if it already was on the list
Jul 07 16:02:51 <inz> Which it obviously isn't as this is done during initialization
Jul 07 16:03:56 <denkenz> actually you're right, we don't handle the case where the operator isn't on the known list
Jul 07 16:06:53 <denkenz> Can you test this patch? http://pastebin.ca/1487023
Jul 07 16:09:54 <inz> Yup, works
Jul 07 16:10:10 <denkenz> Ok, i'll push that later today
Jul 07 17:13:27 <inz> Hmm another thing; aren't the PDU-commands allowed to fail before the PDU is inserted?
Jul 07 17:14:21 <inz> Currently gatchat assumes that errors may only appear after the whole multi line command has been sent
Jul 07 17:14:49 <inz> (and should there be an error, gatchat will wait for a '> ' indefinitely
Jul 07 17:14:53 <inz> )
Jul 07 17:34:06 <denkenz> inz: I'm assuming you have seen this case :)
Jul 07 17:35:10 <inz> denkenz, sure, but I'd like to keep it theoretical, didn't really find anything in the spec about this
Jul 07 17:35:29 <denkenz> inz: The spec is extremely unspecific
Jul 07 17:35:49 <denkenz> inz: But yes, in theory they can fail
Jul 07 17:35:57 <denkenz> inz: Like you describe
Jul 07 17:36:41 <inz> I would guess that at least if the PIN hasn't been entered, CMGS would fail before entering the PDU
Jul 07 17:36:53 <inz> (not that oFono really supports that situation anyway ;)
Jul 07 17:37:26 <denkenz> Yes, I'm actually hoping to ignore this case
Jul 07 17:37:35 <denkenz> We will always bootstrap the PIN first
Jul 07 17:37:44 <denkenz> I don't see why CMGS should fail otherwise
Jul 07 17:38:21 <denkenz> however, I'll see if I can fix this :)
Jul 07 17:45:17 <inz> It might be a removal of one if () -clause
Jul 07 17:45:39 <inz> But I am not quite certain if it will cause troubles.
Jul 07 17:47:17 <denkenz> Well, the culprit is gatchat.c:469
Jul 07 17:47:56 <denkenz> I'm thinking I should just move the terminator checking right before that if statement
Jul 07 17:48:12 <denkenz> so it catches errors regardless if the entire command was sent
Jul 07 17:48:32 <denkenz> Is this something you can test on your side relatively painlessly?
Jul 07 17:48:57 <inz> Umm; yeah, I think so
Jul 07 17:59:33 <denkenz> inz: Try http://pastebin.ca/1487138
Jul 07 19:14:36 <denkenz> inz: Ok, this actually works for me after fixing an off by 1 error :)
**** ENDING LOGGING AT Wed Jul 08 02:59:59 2009

**** BEGIN LOGGING AT Wed Jul 08 02:59:59 2009
**** ENDING LOGGING AT Thu Jul 09 02:59:56 2009

**** BEGIN LOGGING AT Thu Jul 09 02:59:56 2009
**** ENDING LOGGING AT Mon Jul 27 05:58:11 2009

**** BEGIN LOGGING AT Mon Jul 27 06:00:14 2009
**** ENDING LOGGING AT Mon Jul 27 06:02:16 2009

**** BEGIN LOGGING AT Mon Jul 27 06:03:37 2009
Jul 27 23:11:05 <dilinger> hm
Jul 27 23:11:21 <dilinger> Jul 27 19:10:42 mycelium ofonod[2518]: export_entries_one_storage_cb with "SM" failed
Jul 27 23:11:24 <dilinger> Jul 27 19:10:42 mycelium ofonod[2518]: export_entries_one_storage_cb with "ME" failed
Jul 27 23:11:33 <dilinger> that's w/ a g1  :/
Jul 27 23:15:13 <denkenz> interesting, I've just pushed a couple fixes to phonebook stuff
Jul 27 23:15:24 <dilinger> though CPBR=? seems to list (1-6),30,30
Jul 27 23:15:31 <denkenz> See if they have any effect, otherwise can you trace where exactly it fails?
Jul 27 23:15:41 <dilinger> +CPBR: 1,"411",129,"411 & More/M"                                                                                                
Jul 27 23:15:47 <dilinger> sure
Jul 27 23:15:51 <dilinger> yeah, this is still 0.1
Jul 27 23:16:06 <denkenz> Nah, the G1 should work
Jul 27 23:16:22 <dilinger> also, voicecalls work much better now.  dbus-send actually returns modem1/voicecall01 rather than an error :)
Jul 27 23:16:36 <denkenz> Excellent :)
Jul 27 23:18:48 <denkenz> btw, we actually made 0.2, but I don't think we ever announced it
Jul 27 23:27:35 <dilinger> does that include the phonebook fixes?
Jul 27 23:28:22 <dilinger> oh, i made a manpage for ofonod for the debian package.  i should send a patch if you folks are interested
Jul 27 23:28:59 <denkenz> yeah, send it to the list
Jul 27 23:29:11 <denkenz> No, the phonebook stuff is post 0.2
Jul 27 23:30:16 <dilinger> ok.  i'll probably ignore 0.2 until ofono breaks out of NEW, then.
Jul 27 23:30:24 <dilinger> by then, 0.3 might be out anywyas
Jul 27 23:33:09 <denkenz> yeah, we'll probably do a release every 2 weeks or so
Jul 28 00:20:19 <dilinger> Jul 27 20:19:41 mycelium ofonod[10141]: Phonebook not supported by this modem.  If this is in error please submit patches to support this hardware
Jul 28 00:24:36 <denkenz> nice
Jul 28 00:24:54 <denkenz> tell me where it fails, most likely the character set
Jul 28 00:30:56 <dilinger> ofonod[10584]: at_list_charsets_cb got result: 1
Jul 28 00:31:01 <dilinger> ofonod[10584]: Final response: OK
Jul 28 00:31:01 <dilinger> ofonod[10584]: Response line: +CSCS: ("IRA","GSM")
Jul 28 00:31:13 <dilinger> which comes just prior to the line above
Jul 28 00:31:39 <denkenz> Ok, this tells me that G1 does not support non-english characters
Jul 28 00:31:50 <denkenz> Which is just plain creepy :P
Jul 28 00:32:17 <denkenz> If you do AT+CSCS="UCS2"
Jul 28 00:32:21 <denkenz> What does it tell you?
Jul 28 00:33:54 <dilinger> ERROR
Jul 28 00:36:06 <denkenz> Heh
Jul 28 00:36:37 <denkenz> Ok, wrong assumption on my part that in 2007+ modems would support international character sets
Jul 28 00:36:50 <denkenz> Whoever designed the G1 modem needs to be shot :)
Jul 28 00:36:54 <dilinger> :)
Jul 28 00:46:45 <denkenz> ok, just for the hell of it, try this patch: http://pastebin.ca/1509510
Jul 28 00:47:20 <dilinger> hrm
Jul 28 00:47:22 <dilinger> User-Agent is required to request raw files for security reasons.
Jul 28 00:47:27 <denkenz> dilinger: Without UTF8 or UCS2 support, we just hope the modem doesn't ever get a SIM with international chars
Jul 28 00:47:35 <dilinger> no epiphany-webkit love there.  weird.
Jul 28 00:49:20 <dilinger> denkenz: that didn't give a phonebook error..
Jul 28 00:49:43 <dilinger> woo
Jul 28 00:49:51 <dilinger>    string "BEGIN:VCARD
Jul 28 00:49:54 <dilinger> ..and so on
Jul 28 00:49:59 <denkenz> good :)
Jul 28 00:50:28 <denkenz> I will clean up the patch with strong wording of why this is a bad idea
Jul 28 00:50:48 <dilinger> thanks
Jul 28 00:50:49 <denkenz> I'm *really* surprised the G1 doesn't have proper support though
Jul 28 00:52:01 <dilinger> is that something that a firmware update could fix, or is it hardware-dependent?
Jul 28 00:52:48 <denkenz> Theoretically it probably can be fixed in firmware
Jul 28 00:53:13 <denkenz> But it may be that Google simply does not use the SIM phonebook for anything, or is only sold in English countries
Jul 28 00:53:27 <denkenz> Both being poor excuses :)
**** ENDING LOGGING AT Tue Jul 28 02:59:57 2009

**** BEGIN LOGGING AT Tue Jul 28 02:59:57 2009
Jul 28 16:39:43 <denkenz> holtmann: Can you comment on the manpage patch?  Looks good to me
Jul 28 22:21:21 <dilinger> denkenz: don't suppose you have any ideas as to why the g1's reporting that SMS isn't supported, do you?  AT+CSMS=? gets me ERROR.   :/
Jul 28 22:24:12 <denkenz> dilinger: Because the modem is freaking stupid?  How about AT+CSMS?
Jul 28 22:25:14 <denkenz> and also AT+CSMS=1
Jul 28 22:25:16 <dilinger> i just tried that as well.  actually, everything is getting me errors at this point.  wonder what's going on..
Jul 28 22:25:24 <denkenz> Ah, AT+CFUN=1
Jul 28 22:25:49 <denkenz> If you haven't initialized it yet
Jul 28 22:28:25 <dilinger> AT+CFUN=1 gets me an error
Jul 28 22:28:49 <dilinger> sec, there's definitely something screwy here..
Jul 28 22:30:06 <denkenz> You had it working yesterday ;)
Jul 28 22:36:44 <dilinger> yeah.  today, not so much :(
Jul 28 22:36:49 <dilinger> minicom: cannot open /dev/rfcomm0: No such file or directory
Jul 28 22:41:10 <denkenz> sounds like your bt link isn't there
Jul 28 22:41:53 <dilinger> ok, all of the above result in ERROR
Jul 28 22:42:02 <dilinger> AT+CNUM works
Jul 28 22:42:20 <dilinger> AT+CFUN=1, AT+CSMS=1, AT+CSMS=?, and AT+CSMS? all result in ERROR
Jul 28 22:44:15 <denkenz> Strange, are you running natively or connecting to Bluetooth Serial?
Jul 28 22:44:25 <dilinger> bluetooth serial
Jul 28 22:44:50 <dilinger> i haven't dug into this thing yet
Jul 28 22:45:05 <denkenz> I mean it should theoretically work, but isn't guaranteed
Jul 28 22:45:24 <dilinger> how are people using it?  running ofono on the g1 itself?
Jul 28 22:45:30 <denkenz> oFono is really more of take full control of the modem type stack 
Jul 28 22:46:01 <denkenz> Well, that's the plan really
Jul 28 22:46:17 <dilinger> sure
Jul 28 22:46:27 <dilinger> i know that's the long term plan.. what i'm wondering is what works now ;)
Jul 28 22:46:53 <denkenz> Right now I have an OpenMoko FreeRunner I test with
Jul 28 22:46:55 <denkenz> That works
Jul 28 22:47:05 <denkenz> I know Andrew has a GTA01
Jul 28 22:47:32 <denkenz> Most development is done on phonesim, which we're releasing 'any day now'
Jul 28 22:48:12 <denkenz> If you were to hack your G1, install linux on it, I'm sure that would work after we figure out how to initialize it properly
Jul 28 22:48:38 <denkenz> Some phones will work over Bluetooth or USB, but I can't guarantee that
Jul 28 22:51:09 <denkenz> See if you can google anything about G1 being able to send SMS over Bluetooth Serial
Jul 28 22:51:13 <dilinger> denkenz: ok.  i thought i remembered someone saying that they used a g1 w/ ofono, but maybe i'm mistaken.  either way, it's sounding like i should root this thing.
Jul 28 22:51:28 <denkenz> Maybe some setting is missing
**** ENDING LOGGING AT Wed Jul 29 02:59:57 2009

**** BEGIN LOGGING AT Wed Jul 29 02:59:57 2009
**** ENDING LOGGING AT Thu Jul 30 02:59:57 2009

**** BEGIN LOGGING AT Thu Jul 30 02:59:57 2009
Jul 30 23:54:42 <dilinger> i don't suppose anyone's gotten ofono running on a g1?
Jul 31 00:34:45 <dilinger> mm.  looks like rild uses /system/lib/libreference-ril.so to deal w/ the GSM modem (and contains strings like "AT+CSMS=1")
Jul 31 00:47:42 <dilinger> ah!
Jul 31 00:47:43 <dilinger> AT+CSMS=?                                                                    
Jul 31 00:47:43 <dilinger> +CSMS: (0)    
Jul 31 00:48:45 <dilinger> 'stop rild', 'mknod /dev/smd0 c 254 0', open up smd0 in minicom, and i'm set.  cool.
Jul 31 00:56:42 <denkenz> nice, now see if you can actually get an SMS sent :)
Jul 31 00:59:52 <dilinger> yeah.  i've got a debian lenny chroot on it, so i can pull in stuff quite easily
Jul 31 01:00:08 <dilinger> this is also much stabler than bluetooth ;)
Jul 31 01:03:39 <dilinger> (a captain obvious comment, i know)
Jul 31 02:51:28 <tmzt> g1?
Jul 31 02:51:49 <tmzt> the at commands are standard gsm for the most part
Jul 31 02:52:05 <tmzt> data is over rmnet and has to be brought up by echoing something to /dev/qmi though
Jul 31 02:52:14 <tmzt> dilinger: 
Jul 31 02:53:14 <tmzt> the audio routing has to be done through ioctl's to devices in /dev
Jul 31 02:54:16 <dilinger> tmzt: except various AT commands aren't supported over bluetooth
Jul 31 02:54:26 <dilinger> tmzt: but speaking directly to smd0 works
Jul 31 02:54:46 <dilinger> i haven't played w/ the qmi devices at all
Jul 31 02:55:37 <tmzt> over bluetooth it will only support dun commands, or whatever channel you were connected to
Jul 31 02:56:16 <tmzt> good to know you can stop rild without crashing andorid though, didn't know that
**** ENDING LOGGING AT Fri Jul 31 02:59:57 2009

**** BEGIN LOGGING AT Fri Jul 31 02:59:57 2009
Jul 31 03:02:56 <dilinger> i tried opening smd0 in minicom at first without stopping rild, and the phone crashed hard.  had to reboot it by pulling the battery :)
Jul 31 03:11:54 <tmzt> yeah
Jul 31 03:12:02 <tmzt> oh, crashed hard
Jul 31 03:12:05 <tmzt> also interesting
Jul 31 13:34:55 <dilinger> netlink.c: In function ‘g_pn_nl_process’:
Jul 31 13:34:55 <dilinger> netlink.c:75: error: cast increases required alignment of target type
Jul 31 13:34:55 <dilinger> netlink.c:107: error: cast increases required alignment of target type
Jul 31 13:34:55 <dilinger> netlink.c:108: error: cast increases required alignment of target type
Jul 31 13:34:57 <dilinger> on arm
Jul 31 13:50:16 * dilinger wonders if he should upgrade this chroot to squeeze
Jul 31 14:28:50 <dilinger> same thing w/ 2.6.30 headers (was using 2.6.26 previously)
Jul 31 14:52:01 <denkenz> dilinger: Report those to the mailing list, maybe Remi can fix it
Jul 31 15:21:12 <dilinger> seems like just building that file w/out -Wcast-align would fix the issue
Jul 31 15:22:47 <dilinger> i'm not sure what the automake-fu is to specify CFLAGS for that particular file
Jul 31 15:23:39 <denkenz> Well you don't need gisi or isimodem
Jul 31 15:24:09 <denkenz> But I've no idea what's going on in that code, Remi or Aki need to fix it
Jul 31 16:29:49 <dilinger> man, this build is slow..
Jul 31 18:02:47 <dilinger> ** (ofonod:15054): CRITICAL **: Netlink error: Address family not supported by protocol
Jul 31 18:03:30 <denkenz> Does it crash or just print this?
Jul 31 18:04:00 <dilinger> it just prints that
Jul 31 18:04:44 <denkenz> Then just ignore
Jul 31 18:04:57 <denkenz> It simply says that there's no kernel support for isi
Jul 31 18:05:02 <denkenz> and you don't care about it anyway
Jul 31 18:05:45 <dilinger> okay
Jul 31 18:06:16 <dilinger> argh, crashed the phone
Jul 31 18:08:30 <denkenz> Yeah welcome to the ARM world, where hardware is crap and software is even worse :)
Jul 31 18:09:45 <denkenz> holtmann: you back yet?
Jul 31 18:09:50 <dilinger> hm, because 'stop rild' didn't actually stop rild this time.  blah.
Jul 31 18:12:34 <dilinger> right, it's 'stop ril-daemon'
Jul 31 18:15:56 <dilinger> sweet
Jul 31 18:15:56 <dilinger>    object path "/modem1"
Jul 31 18:16:14 <denkenz> Heh, nice
Jul 31 18:18:40 <dilinger> looks like some dbus methods aren't there, though.  or the api's changed while i wasn't looking
Jul 31 18:18:51 <dilinger> Error org.freedesktop.DBus.Error.UnknownMethod: Method "Import" with signature "" on interface "org.ofono.Phonebook" doesn't exist
Jul 31 18:19:24 <denkenz> no, it should be there
Jul 31 18:20:10 <denkenz> Has the phonebook been initialized according to the log?
Jul 31 18:21:02 <dilinger> apparently not
Jul 31 18:21:08 <dilinger> ofonod[953]: Registered call settings interface
Jul 31 18:21:09 <dilinger> ofonod[953]: Sending voice initialization commands
Jul 31 18:21:12 <dilinger> and that's the last line
Jul 31 18:21:43 <denkenz> Ok, sounds like parser's confused
Jul 31 18:22:36 <dilinger> installing gdb and strace, but this may take a little while
Jul 31 18:23:02 <denkenz> Nod, strace or a simple fprintf right after read() might work
Jul 31 18:24:12 <dilinger> writev(2, [{"ofonod[1152]: Sending voice initi"..., 51}, {"\n"..., 1}], 2ofonod[1152]: Sending voice initialization commands
Jul 31 18:24:20 <dilinger> write(4, "AT+CREG=2\r"..., 10)          = 10
Jul 31 18:24:31 <dilinger> read(4, "@HTCCSQ: 2\r\n"..., 4094)      = 12
Jul 31 18:25:06 <denkenz> WTF, that modem is not prefixing commands with a \r\n
Jul 31 18:25:34 <denkenz> Is it in V1 mode or something?
Jul 31 18:25:42 <dilinger> it seems to be looping with responses..
Jul 31 18:25:47 <dilinger> read(4, "@HTCCSQ: 3\r\n"..., 4096)      = 12
Jul 31 18:25:56 <dilinger> and back to read(4, "@HTCCSQ: 2\r\n"..., 4096)      = 12
Jul 31 18:26:02 <dilinger> i have no idea
Jul 31 18:27:20 <denkenz> Try sending an ATV1
Jul 31 18:28:06 <denkenz> But basically the parser expects \r\nresponse\r\n
Jul 31 18:28:17 <denkenz> Its not seeing that, so its getting confused
Jul 31 18:28:58 <dilinger> ATV1                                                                         
Jul 31 18:28:59 <dilinger> OK   
Jul 31 18:29:27 <denkenz> Now try oFono again?
Jul 31 18:30:41 <dilinger> read(4, "@HTCCSQ: 1\r\n"..., 4096)      = 12
Jul 31 18:30:59 <denkenz> Heh
Jul 31 18:32:06 <denkenz> Dunno, another thing to try is to initialize this modem with G_AT_CHAT_FLAG_NO_LEADING_CRLF gatchat flag set
Jul 31 18:32:17 <denkenz> see if that makes it work
Jul 31 18:35:22 <dilinger> -       at->parser = g_at_chat_new(io, 0);
Jul 31 18:35:23 <dilinger> +       at->parser = g_at_chat_new(io, G_AT_CHAT_FLAG_NO_LEADING_CRLF);
Jul 31 18:35:28 <dilinger> in atmodem.c, right?
Jul 31 18:35:35 <denkenz> yeah basically
Jul 31 18:36:54 <dilinger> i don't think it gets as far there
Jul 31 18:36:59 <dilinger> write(4, "AT+CREG=2\r"..., 10)          = 10
Jul 31 18:37:05 <dilinger> read(4, "0\r"..., 4096)                 = 2
Jul 31 18:37:05 <dilinger> read(4, 0x3e3ca, 4094)                  = -1 EAGAIN (Resource temporarily unavailable)
Jul 31 18:37:24 <denkenz> Ok, it is in V0 mode
Jul 31 18:37:48 <denkenz> So the first thing to do is to send a ATV1 for this modem
Jul 31 18:38:12 <denkenz> since gatchat doesn't support V0 mode
Jul 31 18:39:18 <dilinger> does ofono reset the mode when it starts?  manually setting ATV1 and then starting up ofonod doesn't seem to help
Jul 31 18:39:56 <denkenz> It might be that the modem resets itself
Jul 31 18:40:02 <denkenz> oFono doesn't do anything
Jul 31 18:40:18 <denkenz> Btw, it might be easier to use ser2net if you can tether the G1
Jul 31 18:40:43 <denkenz> Since you can just use telnet to manually insert init commands before giving it to oFono
Jul 31 18:40:48 <denkenz> Might be faster / easier
Jul 31 18:41:10 <denkenz> Once you know the sequence, just customize the driver for it
Jul 31 18:41:27 <dilinger> heh.   well, right now the g1 seems to go to sleep every 5 mins or so
Jul 31 18:41:44 <dilinger> in the process, it drops the wireless connection.  so, i need to manually press a button on the phone to get it to not sleep
Jul 31 18:41:57 <denkenz> heh
Jul 31 18:42:09 <denkenz> Don't worry, there's all kinds of craziness
Jul 31 18:42:17 <dilinger> i'm not sure that attempting to do even more stuff over wifi would be helpful (until i figure out a workaround) :)
Jul 31 18:42:20 <denkenz> For instance, the Calypso modem goes to sleep after 5 seconds
Jul 31 18:42:40 <denkenz> So you need to send a 'wakeup' command to hit it over the head once in a while
Jul 31 18:43:01 <dilinger> lovely
Jul 31 18:43:10 <denkenz> Well, you can do lots of testing in 5 mins, beats recompiling
Jul 31 18:45:29 * dilinger nods
Jul 31 18:47:54 <dilinger> adding ATV1 doesn't seem to make a difference :(
Jul 31 18:49:35 <dilinger> oh, nm, i added it to the wrong place
Jul 31 18:51:13 <dilinger> okay, that worked
Jul 31 18:51:25 <dilinger> ofonod[5240]: NetworkRegistration interface for modem: /modem1 created
Jul 31 18:51:48 <dilinger> note that that's without the CRLF flag
Jul 31 18:52:48 <denkenz> Ok good, it was simply the V0 mode
Jul 31 18:53:03 <dilinger> i don't see any phonebook init line, though
Jul 31 18:53:17 <dilinger> ofonod[5240]: crsm_info_cb: 90, 00, 15
Jul 31 18:53:30 <dilinger> that's the last line of debugging output (also, Phonebook.Import still doesn't work)
Jul 31 18:53:47 <dilinger> does it hurt to always specify V1 mode during init?
Jul 31 18:54:13 <dilinger> or should it be android-specific?
Jul 31 18:54:15 <denkenz> No, but it is usually the default
Jul 31 18:54:20 <denkenz> hence it should be in the specific driver
Jul 31 18:54:52 <denkenz> I'm working on making the drivers a bit easier to add / customize
Jul 31 18:55:16 <denkenz> Btw, are you seeing any debug output from phonebook related stuff?
Jul 31 18:55:38 <denkenz> e.g. at_read_charset
Jul 31 18:56:13 <denkenz> at_list_storages
Jul 31 18:56:33 <denkenz> It might be that the parser is still confused somewhere :)
Jul 31 19:03:04 <dilinger> yeah
Jul 31 19:03:09 <dilinger> ofonod[7542]: at_list_storages_cb got result: 1
Jul 31 19:03:19 <dilinger> ofonod[7542]: Response line: +CPBS: ("SM","DC","FD","LD","MC","ME","RC","EN","ON")
Jul 31 19:03:44 <denkenz> So it should register the phonebook there
Jul 31 19:05:52 <dilinger> localhost:~# dbus-send --system --print-reply --dest=org.ofono /modem1 org.ofono.Modem.GetProperties
Jul 31 19:05:58 <dilinger> Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Jul 31 19:06:13 <denkenz> Grab the introspection data on /modem1 path and see what's there
Jul 31 19:06:33 <dilinger> ofonod's strace wasn't showing any action there, so there's something screwy w/ dbus i think
Jul 31 19:06:38 <denkenz> Do you have /etc/dbus-1/system.d/ofono.conf installed?
Jul 31 19:06:58 <denkenz> or whatever Android does for dbus permissions?
Jul 31 19:07:14 <dilinger> yeah
Jul 31 19:07:28 <dilinger> this is a debian chroot, i set it up the same as the debian package
Jul 31 19:07:42 <dilinger> however, dbus-monitor is showing the following
Jul 31 19:07:52 <dilinger> signal sender=org.freedesktop.DBus -> dest=(null destination) path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
Jul 31 19:08:00 <dilinger> when i do the above dbus-send
Jul 31 19:08:29 <denkenz> Well, the funny thing is we should print a ton of errors if the interface registration fails
Jul 31 19:08:46 <denkenz> are you sure its on modem1 and are you sure you're using the proper dbus socket?
Jul 31 19:09:01 <dilinger> yeah
Jul 31 19:10:03 <dilinger> http://pastebin.com/m4d550054
Jul 31 19:10:42 <dilinger> those last 2 dbus signals are from Modem.GetProperties
Jul 31 19:10:50 <denkenz> Then it sounds like the signals can be sent, but the methods are blocked
Jul 31 19:10:57 <denkenz> check your dbus security policy
Jul 31 19:17:06 <dilinger> i'm at a loss
Jul 31 19:19:11 <denkenz> Can you introspect that interface at least?
Jul 31 19:19:24 <denkenz> If you can do that, then its definitely security issue :)
Jul 31 19:25:49 <dilinger> how is it a security issue if the at.Manager.Create call works?
Jul 31 19:26:18 <denkenz> Good point
Jul 31 19:26:35 <denkenz> No idea :)
Jul 31 19:26:39 <dilinger> that's the main reason i'm confused..
Jul 31 19:27:08 <denkenz> Maybe '/' is covered, but subpaths are not?
Jul 31 19:27:27 <denkenz> Or maybe oFono is simply stuck somewhere
Jul 31 19:27:40 <dilinger> do you know how i'd check?
Jul 31 19:27:52 <denkenz> gdb?
Jul 31 19:28:58 <dilinger> localhost:~# dbus-send --system --print-reply --dest=org.ofono /modem1 org.ofono.VoiceCallManager.GetProperties
Jul 31 19:29:01 <dilinger> method return sender=:1.0 -> dest=:1.6 reply_serial=2
Jul 31 19:29:08 <dilinger> ok, so subpaths work
Jul 31 19:29:39 <denkenz> Lemme check maybe I broke Modem interface
Jul 31 19:30:34 <denkenz> No, works for me here
Jul 31 19:31:10 <denkenz> Check what the modem reports for the CGMI, etc commands
Jul 31 19:31:37 <denkenz> Maybe that part is stuck
Jul 31 19:34:12 <dilinger> Modem.GetProperties, Phonebook.Import times out.  SimManager.GetProperties, VoiceCallManager.GetProperties succeed.  SmsManager.GetProperties gives me a "no such method" error.
Jul 31 19:35:16 <dilinger> i don't suppose there's a gatchat debug switch that'll print out every command and response it's seeing, is there?
Jul 31 19:43:02 <denkenz> no, I keep putting that off
Jul 31 19:43:46 <denkenz> Has SMS Manager been initialized according to the log?
Jul 31 19:43:59 <denkenz> It just sounds like gatchat is confused somewhere
Jul 31 19:44:10 <denkenz> gdb could probably tell
Jul 31 19:48:04 <dilinger> ofono_sms_manager_register never gets called
Jul 31 19:48:14 <dilinger> at_sms_init does
Jul 31 19:52:19 <dilinger> so at_sms_init
Jul 31 19:52:19 <dilinger> at_csms_query_cb
Jul 31 19:52:19 <dilinger> at_csms_set_cb
Jul 31 19:52:36 <dilinger> so i guess at_csms_status_cb never gets called
Jul 31 19:55:06 <dilinger> +CSMS: (0)
Jul 31 19:55:40 <dilinger> presumably (assuming that doesn't depend upon some other init), that means cnma_supported=FALSE.. so we send AT+CSMS=0, which returns +CSMS: 1,1,1 
Jul 31 19:56:09 <dilinger> at_csms_set_cb sends AT+CSMS?, which (for me) returns +CSMS: 0,1,1,1
Jul 31 19:56:24 <dilinger> but for some reason, at_csms_status_cb is never called
Jul 31 19:59:25 <denkenz> so that might be why everything is stalled
Jul 31 20:00:15 <dilinger> hm.  i'm missing something in the debugging output
Jul 31 20:00:32 <dilinger> unless.. it's not actually being written to the device
Jul 31 20:00:34 * dilinger raises eyebrow
Jul 31 20:00:44 <dilinger> ** (ofonod:10651): DEBUG: WROTE: 'AT+CSMS=?\u000d'
Jul 31 20:00:57 <dilinger> ** (ofonod:10651): DEBUG: WROTE: 'AT+CSMS=0\u000d'
Jul 31 20:01:12 <dilinger> but i never see the AT+CSMS?
Jul 31 20:02:26 <denkenz> put a dump_response in at_csms_set_cb
Jul 31 20:03:01 <denkenz> And some debug as to what is being read out
Jul 31 20:03:31 <dilinger> that's probably more useful than  my g_debug("moo!\n")
Jul 31 20:05:14 <dilinger> ofonod[12352]: Response line: +CSMS: 1,1,1
Jul 31 20:05:25 <dilinger> which is followed up by
Jul 31 20:05:26 <dilinger> ** (ofonod:12352): DEBUG: WROTE: 'AT+CPBS=?\u000d'
Jul 31 20:06:07 <denkenz> yeah its going to be all jumbled :)
Jul 31 20:06:56 <dilinger> but unless it's not going through can_write_data(), i don't believe the it's being sent
Jul 31 20:07:09 <dilinger> uh, the AT+CSMS?, that is
Jul 31 20:07:28 * dilinger adds some more debugging
Jul 31 20:09:47 <denkenz> no, that's the only place we write to the socket
Jul 31 20:13:35 <dilinger> ok, verified.  'AT+CSMS?' appears to get lost.  maybe a race?  off-by-one error in the cmd queue?
Jul 31 20:14:14 <denkenz> don't know, its been fairly stable for about 5 months or so
Jul 31 20:14:23 <denkenz> but anything's possible
Jul 31 20:15:54 <denkenz> Are you sure the previous command has actually finished?
Jul 31 20:16:06 <dilinger> you mean finished sending?
Jul 31 20:16:22 <denkenz> Well, gatchat can only have 1 command outstanding
Jul 31 20:16:34 <denkenz> so we send off the command and wait until the final response
Jul 31 20:16:46 <denkenz> It could be one of the commands never gets a response and is 'stuck'
Jul 31 20:17:44 <denkenz> So what does the modem send to confuse us?
Jul 31 20:17:51 <dilinger> what do you mean 1 command outstanding?
Jul 31 20:18:05 <denkenz> As in, you add 10 commands
Jul 31 20:18:15 <dilinger> i'm seeing a queue length of 11 commands before it starts sending the first
Jul 31 20:18:15 <dilinger> yeah
Jul 31 20:18:16 <denkenz> it takes one off the queue, sends it to them modem
Jul 31 20:18:32 <denkenz> but the rest are sitting there waiting until the first one finishes
Jul 31 20:20:25 <dilinger> ** (ofonod:14006): DEBUG: send_common: cmd=AT+CSMS?
Jul 31 20:20:27 <dilinger> ** (ofonod:14006): DEBUG: queue length: 9
Jul 31 20:20:42 <dilinger> so there the command is queued
Jul 31 20:20:53 <dilinger> ** (ofonod:14006): DEBUG: WROTE: 'AT+COPS?\u000d'
Jul 31 20:21:01 <dilinger> but that's the last command that's actually written to the device
Jul 31 20:21:07 <dilinger> ** (ofonod:14006): DEBUG: queue length: 8
Jul 31 20:21:10 <dilinger> at that point
Jul 31 20:21:12 <dilinger> then processing stops
Jul 31 20:21:33 <dilinger> so presumably the modem never response to AT+COPS?, or sends back something weird
Jul 31 20:21:49 <denkenz> could happen
Jul 31 20:21:57 <denkenz> for instance if the modem isn't properly initialized
Jul 31 20:22:08 <denkenz> Try it in minicom?
Jul 31 20:23:17 <dilinger> damnit.  crashed the phone again.
Jul 31 21:20:13 <dilinger> hrm.  i don't get it, that time it worked
Jul 31 21:20:38 <denkenz> ?
Jul 31 21:20:49 <dilinger> ** (ofonod:735): DEBUG: WROTE: 'AT+COPS?\u000d'
Jul 31 21:20:52 <dilinger> ofonod[735]: cops_numeric_cb got result: 1
Jul 31 21:20:58 <dilinger> ** (ofonod:735): DEBUG: queue length: 1
Jul 31 21:21:01 <dilinger> ** (ofonod:735): DEBUG: WROTE: 'AT+CNMI=2,1,2,1,0\u000d'
Jul 31 21:21:03 <dilinger> and it's done
Jul 31 21:21:10 <dilinger> queue empty
Jul 31 21:21:30 <dilinger> org.ofono.Modem.GetProperties works
Jul 31 21:22:11 <denkenz> Don't know, could be modem was initialized this time
Jul 31 21:22:11 <dilinger> org.ofono.Phonebook.Import still does not
Jul 31 21:22:31 <denkenz> So what does Import give ya in terms of debug?
Jul 31 21:24:03 <dilinger> nothing
Jul 31 21:24:06 <dilinger> it doesn't reach ofono
Jul 31 21:24:17 <dilinger> and i still get this:
Jul 31 21:24:17 <dilinger> localhost:~# dbus-send --system --print-reply --dest=org.ofono /modem1 org.ofono.SmsManager.GetProperties
Jul 31 21:24:21 <dilinger> Error org.freedesktop.DBus.Error.UnknownMethod: Method "GetProperties" with signature "" on interface "org.ofono.SmsManager" doesn't exist
Jul 31 21:24:36 <dilinger> so whatever was causing the modem or ofono to hang earlier during init was fixed by the reboot
Jul 31 21:24:41 <denkenz> introspect your /modem1
Jul 31 21:24:48 <denkenz> Tell me what interfaces are registered
Jul 31 21:27:25 <dilinger> http://pastebin.com/m14513c88
Jul 31 21:28:03 <denkenz> So SMS is still not being registered
Jul 31 21:28:09 <denkenz> I suspect its stuck in a different place now
Jul 31 21:29:12 <denkenz> Parser or the Modem is confused somewhere
Jul 31 21:32:12 <dilinger> sigh
Jul 31 21:32:46 <dilinger> ** (ofonod:735): DEBUG: WROTE: 'AT+CMGF=0\u000d'
Jul 31 21:33:05 <dilinger> ofonod[735]: at_cmgf_set_cb got result: 1
Jul 31 21:33:17 <dilinger> ofonod[735]: Final response: OK
Jul 31 21:34:06 <dilinger> ** (ofonod:735): DEBUG: send_common: cmd=AT+CPMS="ME","ME","ME"
Jul 31 21:35:02 <dilinger> ** (ofonod:735): DEBUG: WROTE: 'AT+CNMI=2,1,2,1,0\u000d'
Jul 31 21:35:52 <dilinger> hm, there's no debug statement in at_cnmi_set_cb
Jul 31 21:36:17 <dilinger> we're stuck again with a non-zero cmd queue, though
Jul 31 21:36:39 <denkenz> Ok, so something the modem is sending is confusing us
Jul 31 21:36:51 <denkenz> Can you put an fprintf right after read?
Jul 31 21:36:59 <denkenz> Maybe its some malformed string
Jul 31 21:38:15 <dilinger> a dump_response in at_cnmi_set_cb?  or some read elsewhere?
Jul 31 21:38:59 <denkenz> no in gatchat.c received_data
Jul 31 21:48:25 <dilinger> i'll paste it in all it's non-null-terminated glory
Jul 31 21:48:25 <dilinger> ** (ofonod:2392): DEBUG: WROTE: 'AT+CNMI=2,1,2,1,0\u000d'
Jul 31 21:48:38 <dilinger> ** (ofonod:2392): DEBUG: READ: '
Jul 31 21:48:38 <dilinger> +CMS ERROR: 303\u000d0,1,2,3),(0,2),(0,1,2),(0,1)
Jul 31 21:48:50 <dilinger> ** (ofonod:2392): DEBUG: READ: '0,1,2,3),(0,2),(0,1,2),(0,1)
Jul 31 21:49:09 <dilinger> so ERROR: 303, followed by 0,1,2,3),(0,2),(0,1,2),(0,1)
Jul 31 21:49:13 <dilinger> i don't know wth that is
Jul 31 21:49:37 <denkenz> Yeah that's just bogus
Jul 31 21:49:46 <dilinger> oh, i guess it's part of the prior response
Jul 31 21:49:50 <dilinger> ofonod[2392]: at_cnmi_query_cb got result: 1
Jul 31 21:49:56 <dilinger> ofonod[2392]: Response line: +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
Jul 31 21:49:57 <dilinger> ** (ofonod:2392): DEBUG: send_common: cmd=AT+CNMI=2,1,2,1,0
Jul 31 21:50:35 <denkenz> Where's the error coming from?
Jul 31 21:51:38 <dilinger> localhost:~# printf "AT+CNMI=2,1,2,1,0\r\n" > /dev/smd0 
Jul 31 21:51:44 <dilinger> ** (ofonod:2392): DEBUG: READ: '
Jul 31 21:51:44 <dilinger> +CMS ERROR: 303\u000dFFFFFFFFFFFFFFFFFFFFF
Jul 31 21:52:07 <dilinger> so it doesn't like that command
Jul 31 21:52:26 <denkenz> no \n
Jul 31 21:52:32 <denkenz> submission is terminated by \r
Jul 31 21:53:20 <denkenz> so if CNMI fails, you should see a big fat warning saying sms not supported
Jul 31 21:53:28 <dilinger> well, same thing
Jul 31 21:53:29 <dilinger> ** (ofonod:2392): DEBUG: READ: '
Jul 31 21:53:29 <dilinger> +CMS ERROR: 303\u000dFFF
Jul 31 21:53:46 <dilinger> i don't see any "sms not supported" error, though.   instead, it hangs
Jul 31 21:53:56 <denkenz> OK, I think I see
Jul 31 21:54:07 <denkenz> the final response is not well formed
Jul 31 21:54:14 <denkenz> it should be \r\n terminator
Jul 31 21:54:18 <denkenz> wtf is that FFF?
Jul 31 21:55:45 <denkenz> So basically the modem tells us, 'Sure I support these modes'.  Then when we try to set the modes it barfs
Jul 31 21:55:49 <denkenz> Lovely :)
Jul 31 21:58:13 <dilinger> 'just kidding!'
Jul 31 21:58:28 <dilinger> lemme get some better debugging
Jul 31 22:20:19 <dilinger> hm
Jul 31 22:20:19 <dilinger> atmodem/atmodem.c:33:24: error: ofono/dbus.h: No such file or directory
Jul 31 22:20:30 <dilinger> atmodem/atmodem.c:34:25: error: ofono/modem.h: No such file or directory
Jul 31 22:20:58 <denkenz> cd include; make clean; make
Jul 31 22:23:28 <dilinger> thanks
Jul 31 23:03:00 <denkenz> dilinger: Can you git format-patch your manpage submission?
Jul 31 23:03:17 <denkenz> dilinger: Just resubmit to ML, I'll go ahead and apply it
Jul 31 23:07:10 <dilinger> not sure what you mean (the patch was generated w/ format-patch).  you mean resend with the Date/From/Subject lines still intact?
Jul 31 23:10:46 <denkenz> Nod, so I can just git am and preserve the author info
Jul 31 23:13:36 <holtmann> denkenz: Clone a temp tree and see what git am does. If it is only the commit message, then git commit --amend can fix it before pushing out.
Jul 31 23:13:54 <holtmann> dilinger: Using git send-email does always the right thing.
Jul 31 23:14:23 <denkenz> holtmann: I know I can play those silly tricks, but I'd rather just have a proper format patch :)
Jul 31 23:16:20 <dilinger> holtmann: i'm assuming it always does the right thing as long as one's local MTA is set up correctly? :)
Jul 31 23:22:53 <denkenz> make distcheck fails
Jul 31 23:22:56 <denkenz> Making all in doc
Jul 31 23:22:58 <denkenz> make[2]: Entering directory `/home/denkenz/ofono-master/ofono-0.2/_build/doc'
Jul 31 23:22:59 <denkenz> make[2]: *** No rule to make target `ofonod.8', needed by `all-am'.  Stop.
Jul 31 23:23:01 <denkenz> make[2]: Leaving directory `/home/denkenz/ofono-master/ofono-0.2/_build/doc'
Jul 31 23:25:01 <holtmann> Man pages have to be added to EXTRA_DIST with $(man_MANS)
Jul 31 23:25:15 <holtmann> autotools are stupid here.
Jul 31 23:25:41 <holtmann> Actually they are not since manpage can be autogenerated and then you don't want the extra add to dist stuff.
Jul 31 23:26:56 <denkenz> diff --git a/doc/Makefile.am b/doc/Makefile.am
Jul 31 23:26:57 <denkenz> index 85f6023..97aac2d 100644
Jul 31 23:26:58 <denkenz> --- a/doc/Makefile.am
Jul 31 23:27:00 <denkenz> +++ b/doc/Makefile.am
Jul 31 23:27:02 <denkenz> @@ -1,6 +1,6 @@
Jul 31 23:27:03 <denkenz>  
Jul 31 23:27:04 <denkenz> -EXTRA_DIST = overview.txt
Jul 31 23:27:06 <denkenz> -
Jul 31 23:27:08 <denkenz>  MAINTAINERCLEANFILES = Makefile.in
Jul 31 23:27:09 <denkenz>  
Jul 31 23:27:11 <denkenz>  man_MANS = ofonod.8
Jul 31 23:27:12 <denkenz> +
Jul 31 23:27:14 <denkenz> +EXTRA_DIST = overview.txt $(man_MANS)
Jul 31 23:27:15 <denkenz> Makes distcheck pass
Jul 31 23:27:17 <denkenz> holtmann: approve
Jul 31 23:27:23 <denkenz> ?
Jul 31 23:28:50 <holtmann> That should do it.
Jul 31 23:29:05 <holtmann> Actually move the man_MANS on top of EXTRA_DIST.
Jul 31 23:29:23 <denkenz> sorry? its already on top
Jul 31 23:29:28 <holtmann> The MAINTAINERCLEANFILES should always be the last entry.
Jul 31 23:29:38 <denkenz> ah ok
Jul 31 23:29:55 <holtmann> man_MANS, then EXTRA_DIST then MAINTAINERCLEANFILES.
Jul 31 23:30:16 <denkenz> diff --git a/doc/Makefile.am b/doc/Makefile.am
Jul 31 23:30:18 <denkenz> index 85f6023..049d8c1 100644
Jul 31 23:30:19 <denkenz> --- a/doc/Makefile.am
Jul 31 23:30:21 <denkenz> +++ b/doc/Makefile.am
Jul 31 23:30:22 <denkenz> @@ -1,6 +1,5 @@
Jul 31 23:30:24 <denkenz> +man_MANS = ofonod.8
Jul 31 23:30:25 <denkenz>  
Jul 31 23:30:27 <denkenz> -EXTRA_DIST = overview.txt
Jul 31 23:30:28 <denkenz> +EXTRA_DIST = overview.txt $(man_MANS)
Jul 31 23:30:30 <denkenz>  
Jul 31 23:30:31 <denkenz>  MAINTAINERCLEANFILES = Makefile.in
Jul 31 23:30:33 <denkenz> -
Jul 31 23:30:35 <denkenz> -man_MANS = ofonod.8
Jul 31 23:31:51 <denkenz> holtmann: pushing that one out unless you scream soon :)
Jul 31 23:32:23 <holtmann> Looks good.
Aug 01 01:59:14 <dilinger> denkenz: ping?
Aug 01 02:01:59 <dilinger> ttp://dev.queued.net/~dilinger/0002-ofono-add-rawdebug-option-for-logging-raw-output-fro.patch
Aug 01 02:02:06 <dilinger> er, http://dev.queued.net/~dilinger/0002-ofono-add-rawdebug-option-for-logging-raw-output-fro.patch
Aug 01 02:02:43 <dilinger> i haven't actually tested it, as this build is taking forever.. but if you're bored, i wouldn't mind hearing comments
Aug 01 02:06:20 <denkenz> dilinger: The right way to do this is to register a debug func with gatchat
Aug 01 02:06:48 <denkenz> something like g_at_chat_register_debug(parser, void (*write)(const char *data))
Aug 01 02:07:21 <denkenz> Then make it escape \r \n sequences properly inside g_at_chat before calling write
Aug 01 02:08:00 <denkenz> Then simply register ofono_debug or equivalent as the write function
Aug 01 02:08:19 <dilinger> there's read and write
Aug 01 02:09:12 <denkenz> Then simply prefix it with '>' for data from modem, and '<' for data to modem
Aug 01 02:09:13 <dilinger> also, having length attached is useful; i'd like to know if the device is spewing crap (like all those FFFFs that i was seeing earlier)
Aug 01 02:09:33 <dilinger> but i see what you're saying
Aug 01 02:10:00 <denkenz> length shouldn't be an issue if you escape the control chars
Aug 01 02:10:16 <denkenz> and if we're seeing anything other than '\r' and '\n' that's bad, mmk?
Aug 01 02:15:43 <denkenz> oh, the only other control character you should see is Ctrl-Z (26)
Aug 01 02:15:57 <denkenz> But only on 'to the modem' side
Aug 01 02:19:44 <dilinger> ok, thanks
**** ENDING LOGGING AT Sat Aug 01 02:59:58 2009

**** BEGIN LOGGING AT Sat Aug 01 02:59:58 2009
**** ENDING LOGGING AT Sun Aug 02 02:59:57 2009

**** BEGIN LOGGING AT Sun Aug 02 02:59:57 2009
**** ENDING LOGGING AT Mon Aug 03 02:59:57 2009

**** BEGIN LOGGING AT Mon Aug 03 02:59:57 2009
Aug 03 07:55:52 <Sage> sim.c: In function ‘sim_op_retrieve_cb’:
Aug 03 07:55:54 <Sage> sim.c:336: error: ignoring return value of ‘write’, declared with attribute warn_unused_result
Aug 03 07:55:55 <Sage> sim.c: In function ‘sim_op_info_cb’:
Aug 03 07:55:57 <Sage> sim.c:462: error: ignoring return value of ‘write’, declared with attribute warn_unused_result
Aug 03 07:56:12 <Sage> With the latest git version.
Aug 03 07:59:04 <Sage> with gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
Aug 03 15:48:08 <dilinger> denkenz: yeah, it looks like i'm seeing strings that don't start w/ \n
Aug 03 15:48:22 <dilinger> ofonod[9701]: RAW READ: '+CREG: 1,"144E","0000A34B"
Aug 03 15:48:24 <dilinger> '
Aug 03 15:48:30 <dilinger> vs
Aug 03 15:48:40 <dilinger> ofonod[9701]: RAW READ: '
Aug 03 15:48:40 <dilinger> +CREG: 1,"144E","0000A349"
Aug 03 15:48:41 <dilinger> '
Aug 03 15:49:10 <denkenz> sigh
Aug 03 15:49:24 <denkenz> so its not precending the unsolicited notification with \r\n?
Aug 03 15:49:32 <denkenz> s/precending/preceding
Aug 03 15:50:05 <dilinger> would appear not.  i need to start escaping control characters, i think
Aug 03 15:50:48 <denkenz> Yes, that would be nice as it'll tell us exactly what's going on
Aug 03 15:51:17 <denkenz> I wonder if there's some stupid vendor command we need to send to make the modem behave properly
Aug 03 16:33:46 <denkenz> holtmann: Have you checked Remi's patch?
Aug 03 16:38:27 <dilinger> ofonod[3167]: at_cnmi_query_cb got result: 1
Aug 03 16:38:40 <dilinger> ofonod[3167]: Response line: +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
Aug 03 16:38:40 <dilinger> ofonod[3167]: > AT+CNMI=2,1,2,1,0\r
Aug 03 16:38:40 <dilinger> ofonod[3167]: < \r\n+CMS ERROR: 303\r0,1,2,3),(0,2),(0,1,2),(0,1)\r\n\r\nOK\r\nFFFFFFFFFFFFFFFFFFFFF\r\n\r\nOK\r\n
Aug 03 16:39:20 <denkenz> whoa invalid format batman
Aug 03 16:40:01 <dilinger> http://pastebin.com/m7ae77c8b
Aug 03 16:40:46 <denkenz> btw, the socket is opened nonblock, so len of 0 simply means nothing in the buffer
Aug 03 16:40:51 <denkenz> Feel free to squash those messages
Aug 03 16:41:01 <holtmann> denkenz: The configure bashim patch is fine. Not sure where he find a system with bash2.x though.
Aug 03 16:41:03 <dilinger> yep
Aug 03 16:41:22 <holtmann> denkenz: Feel free to apply it. I couldn
Aug 03 16:41:22 <denkenz> holtmann: Ok, I apply it then in my next push
Aug 03 16:41:29 <holtmann> 't care less about these old system.
Aug 03 16:41:39 <denkenz> holtmann: Heh ok
Aug 03 16:41:40 <dilinger> denkenz: it's a <1 || >1024 check, i haven't gotten around to separating them out
Aug 03 16:43:06 <denkenz> even this part looks fishy: \r\n+CSMS: 0,1,1,1\r\n\r\nOK\r\n@",4\r\n\r\nOK\r\n50102011E\r\n\r\nOK\r\n")\r\n\r\nOK\r\n
Aug 03 16:44:26 <denkenz> It sounds like the modem firmware is fucked, its reusing an old buffer or something
Aug 03 16:48:03 <dilinger> or the buffer isn't null terminated
Aug 03 16:48:08 <dilinger> ofonod[3843]: < \r\n+CSMS: 1,1,1\r\n\r\nOK\r\n0D0A349"\r\n\r\nOK\r\n\nOK\r\n (22 bytes)
Aug 03 16:48:27 <denkenz> exactly, its just overwriting the contents and sending the entire thing out
Aug 03 16:48:44 <denkenz> Without updating the len, ugh, monkeys implementing this thing?
Aug 03 16:49:08 <dilinger> no, i mean the debug buffer
Aug 03 16:49:42 <denkenz> Ah, the buffer in gatchat?
Aug 03 16:49:56 <denkenz> Lol of course not, you have to keep track of the length
Aug 03 16:50:25 <dilinger> i was null terminating manually, but not since swithing to g_strescape
Aug 03 16:50:26 <dilinger> :/
Aug 03 16:51:49 <denkenz> Hehe, where are you hacking into the string display?
Aug 03 16:51:56 <denkenz> right after read or elsewhere?
Aug 03 16:53:36 <dilinger> sorry about that.  here's saner looking output:  http://pastebin.com/m1ced2c7e
Aug 03 16:54:12 <denkenz> Ok, that makes more sense
Aug 03 16:54:21 <denkenz> The problem is +CMS Error is not properly terminated
Aug 03 16:55:11 <denkenz> The error meaning is "Operation not supported"
Aug 03 16:55:26 <dilinger> yeah, directly after the g_io_channel_read
Aug 03 16:56:07 <denkenz> Does your RIL .so contain any CNMI init strings?
Aug 03 16:56:35 <denkenz> The modem is just bizarre, considering it told us it supports all these modes on the previous command
Aug 03 16:58:09 <dilinger> AT+CSMS=1
Aug 03 16:58:10 <dilinger> +CSMS:
Aug 03 16:58:10 <dilinger> AT+CNMI=1,2,2,1,1
Aug 03 16:58:31 <dilinger> i don't see a "AT+CNMI=?" string in the binary
Aug 03 17:08:07 <denkenz> Does the binary contain AT+CNMA
Aug 03 17:08:09 <denkenz> ?
Aug 03 17:09:14 <dilinger> AT+CNMA=1
Aug 03 17:09:14 <dilinger> AT+CNMA=2
Aug 03 17:09:16 <courmisch> holtmann: scratchbox...
Aug 03 17:09:42 <holtmann> courmisch: Aren't you guys suppose to be have updated scratchboxes.
Aug 03 17:10:12 <courmisch> the problem is with the devkits really
Aug 03 17:10:21 <courmisch> that's a terrible and terribly annoying hack
Aug 03 17:11:33 <courmisch> and I guess bash is not the top priority when it comes to updating
Aug 03 17:14:59 <denkenz> dilinger: Ok first thing first, can you add a quirk to gatchat to handle +CMS ERROR not being terminated
Aug 03 17:19:06 <holtmann> courmisch: I feel for you guys that you have to deal with outdated details. I thought after the N810 this would be finally get all updated to modern stuff.
Aug 03 17:19:46 <holtmann> courmisch: Btw. you should not build the final binary packages with --enable-maintainer-mode. That might be the reason Johan never complained about this for the BlueZ packages.
Aug 03 17:19:57 <courmisch> some things yes (we finally have  gcc 4.2.1 !) but shell...
Aug 03 17:21:18 <courmisch> yes but it cannot hurt to try a manual build from within SB
Aug 03 17:22:19 <denkenz> dilinger: It looks like these guys use CNMI to route messages directly to TE using +CMT, and even use CNMA, yet the modem doesn't support CSMS service 1
Aug 03 17:22:35 <denkenz> dilinger: According to 27.005 section for CNMA: Execution command confirms reception of a new message (SMS-DELIVER or SMS-STATUS-REPORT) which is routed directly to the TE  (refer command +CNMI tables 2 and 4). This acknowledgement command shall be used when +CSMS parameter <service> equals 1
Aug 03 17:24:29 <denkenz> So its a bit vague whether CNMA can be used when service=0
Aug 03 17:24:37 <holtmann> courmisch: Yeah. With BlueZ we don't really have to bother with the embedded devices anymore. We can test everything on a normal PC.
Aug 03 17:30:11 <denkenz> dilinger: We can try a few things once the parser issue is fixed.  Worst case we write a driver specifically for G1
Aug 03 17:30:18 * dilinger nods
Aug 03 17:36:20 <dilinger> http://pastebin.com/m3c8cc5cb
Aug 03 17:38:16 <denkenz> Now see if AT+CNMI=2,2,2,1,1 is accepted by the modem
Aug 03 17:38:34 <dilinger> http://pastebin.com/m3bb0c48e
Aug 03 17:39:36 <denkenz> or AT+CNMI=2,2,2,1,0 rather
Aug 03 17:46:04 <dilinger> ofonod[7023]: > AT+CNMI=2,2,2,1,0\r (18 bytes)
Aug 03 17:46:05 <dilinger> ofonod[7023]: < \r\n+CMS ERROR: 303\r\n (19 bytes)
Aug 03 17:47:35 <denkenz> how about AT+CNMI=1,2,2,1,0
Aug 03 17:50:59 <dilinger> ofonod[7863]: > AT+CNMI=1,2,2,1,0\r (18 bytes)
Aug 03 17:50:59 <dilinger> ofonod[7863]: < \r\nOK\r\n (6 bytes)
Aug 03 17:52:06 <dilinger> http://pastebin.com/m269e0b28
Aug 03 17:52:22 <dilinger> (note SmsManager)
Aug 03 17:52:38 <denkenz> Yep, now see if you can receive / send SMS
Aug 03 17:59:41 <dilinger> hm
Aug 03 17:59:59 <dilinger> rx provided this output: ofonod[7863]: < \r\n+CMT: ,24\r\n07912160130300F4040B916171052144F500039080303195516905D93728FF06\r\n (79 bytes)
Aug 03 18:00:15 <dilinger> tx:
Aug 03 18:00:20 <dilinger> ofonod[7863]: Got 1 recipients
Aug 03 18:00:20 <dilinger> ofonod[7863]: ref: 1, offset: 0
Aug 03 18:00:20 <dilinger> ofonod[7863]: pdu_len: 26, tpdu_len: 25
Aug 03 18:00:20 <dilinger> ofonod[7863]: tx_next: 0x410c0
Aug 03 18:00:36 <dilinger> but the number that i sent the sms to hasn't gotten anything yet
Aug 03 18:06:45 <holtmann> cc1: warnings being treated as errors
Aug 03 18:06:45 <holtmann> network.c: In function ‘sim_pnn_read_cb’:
Aug 03 18:06:45 <holtmann> network.c:1246: error: ‘total’ may be used uninitialized in this function
Aug 03 18:09:11 <holtmann> denkenz: That goto handling is ugly as hell.
Aug 03 18:09:27 <denkenz> yeah I know
Aug 03 18:11:13 <holtmann> Am I allowed to make this readable again?
Aug 03 18:11:22 <denkenz> which part?
Aug 03 18:11:32 <denkenz> I'm taking out the goto check
Aug 03 18:11:56 <denkenz> that part is silly to keep going, since we're missing half the PNN records
Aug 03 18:13:43 <holtmann> cc1: warnings being treated as errors
Aug 03 18:13:43 <holtmann> sim.c: In function ‘sim_msisdn_read_cb’:
Aug 03 18:13:43 <holtmann> sim.c:181: error: ‘total’ may be used uninitialized in this function
Aug 03 18:14:03 <holtmann> I would have a proper fix for it. That is actually readable, but be my guest and fix it.
Aug 03 18:14:18 <denkenz> fix sim.c
Aug 03 18:14:20 <holtmann> And after the fix sim.c has a similar non-sense.
Aug 03 18:14:31 <holtmann> I was talking about network.c
Aug 03 18:14:58 <denkenz> Well for MSISDN if we get only x / n records, its still OK to display them
Aug 03 18:15:20 <denkenz> for PNN, if we get x / n records, we can't make a full EONS database
Aug 03 18:15:49 <holtmann> And btw. this is a total broken concept of using goto. They all need fixing. This double !ok check clearly shows that nobody thought about the code flow inside that function. This is hackish code.
Aug 03 18:17:42 <denkenz> Sigh, now that I actually look at it...  We really should just be g_freeing the thing on !ok and be done with it
Aug 03 18:17:48 <denkenz> Is this your fix?
Aug 03 18:18:46 <holtmann> You can have a if (record != total) return in front of the label if you really want to, but in the end what are you trying to work-around here?
Aug 03 18:19:16 <denkenz> Well, when we are reading a record based file, its actually done via n commands for n records
Aug 03 18:19:20 <holtmann> And then omit the second !ok check, because that is already part of it.
Aug 03 18:19:28 <denkenz> Potentially any one of them can fail
Aug 03 18:19:51 <holtmann> let me push the obvious code flow patches first. This is just stupid code.
Aug 03 18:19:57 <denkenz> Go ahead
Aug 03 18:22:07 <holtmann> Done. Please double-check.
Aug 03 18:22:26 <holtmann> I assume we have more of these weird constructs now.
Aug 03 18:23:29 <denkenz> Don't know, the gotos got introduced in the latest patch
Aug 03 18:23:42 <denkenz> I tend not to use them quite this way
Aug 03 18:24:03 <denkenz> Ok that's fine
Aug 03 18:24:17 <denkenz> Lets leave it the way you have it, its a really bizarre case anyway
Aug 03 18:24:22 <holtmann> These clearly show that nobody attempted to understand the code flow and in that case they do more harm than good. It looked like a quick fix. And a bad one.
Aug 03 18:25:19 <denkenz> Well considering Andrew wrote much of it :P
Aug 03 18:25:26 <denkenz> Though I restructured it
Aug 03 18:26:26 <denkenz> Any insights on how we can fix the 'write' return ignored warning?
Aug 03 18:26:41 <holtmann> It fall over with -Werror so badly that I would assume it has not even been compile tested properly. We are not ignoring gcc compiler warnings.
Aug 03 18:26:59 <holtmann> So Andrew is not using --enable-maintainer-mode. That is bad.
Aug 03 18:27:11 <denkenz> I distcheck and test compile on mine
Aug 03 18:27:20 <denkenz> Maybe I haven't bootstrapped lately
Aug 03 18:27:56 <holtmann> Should make no difference.
Aug 03 18:28:10 <denkenz> Then my compiler is more forgiving
Aug 03 18:28:21 <holtmann> Could be. Mine is gcc (GCC) 4.4.0 20090506 (Red Hat 4.4.0-4)
Aug 03 18:28:40 <denkenz> gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5)
Aug 03 18:28:45 <denkenz> So that might be why
Aug 03 18:34:55 <denkenz> dilinger: It doesn't sound like the AT+CSMS actually was successful, at least tx_finished is never called
Aug 03 18:39:12 <dilinger>   ofonod[7863]: > AT+CSMS=0\r (10 bytes)
Aug 03 18:39:13 <dilinger> ofonod[7863]: < \r\n+CSMS: 1,1,1\r\n\r\nOK\r\n (22 bytes)
Aug 03 18:39:36 <denkenz> sorry not CSMS, CMGS
Aug 03 18:40:52 <denkenz> holtmann: Are you sure this isn't related to -O2 somehow?
Aug 03 18:41:07 <denkenz> holtmann: I remember we had this discussion already
Aug 03 18:41:37 <dilinger> CMGS or CMGF?  i don't see a CMGS in the logs..
Aug 03 18:42:07 <denkenz> Sending an SMS should result in a CMGS
Aug 03 18:42:57 <dilinger> bbiab, will look closer then
Aug 03 19:47:13 <denkenz> holtmann: looks like newer gcc detects these errors
Aug 03 19:47:20 <denkenz> holtmann: Any suggestions for:
Aug 03 19:47:30 <denkenz> sim.c: In function ?sim_op_retrieve_cb?:
Aug 03 19:47:32 <denkenz> sim.c:347: error: ignoring return value of ?write?, declared with attribute warn_unused_result
Aug 03 19:47:33 <denkenz> sim.c: In function ?sim_op_info_cb?:
Aug 03 19:47:35 <denkenz> sim.c:473: error: ignoring return value of ?write?, declared with attribute warn_unused_result
Aug 03 19:47:50 <courmisch> not gcc. Those are glibc warnings
Aug 03 19:48:22 <denkenz> Well, I didn't see them when running gcc 3.2
Aug 03 19:48:29 <denkenz> err 4.3
Aug 03 19:48:34 <denkenz> now running 4.4 I do
Aug 03 19:48:57 <courmisch> I have had them for a long time
Aug 03 19:49:02 <courmisch> and I don't even have 4.4 yet
Aug 03 19:49:11 <courmisch> they're coming from FORTIFY_SOURCE
Aug 03 19:49:25 <courmisch> then glibc sets the warn_unused_result attribute to some functions
Aug 03 19:49:36 <courmisch> in its header files
Aug 03 19:49:53 <denkenz> Regardless, we need to squash 'em
Aug 03 19:50:12 <courmisch> handle write() errors...
Aug 03 19:50:29 <denkenz> And do what besides printing an error
Aug 03 19:50:47 <courmisch> stop write()ing at least
Aug 03 19:51:29 <denkenz> that part isn't even in a loop
Aug 03 19:51:44 <courmisch> well it should be. Sockets and TTYs can return short writes
Aug 03 19:52:06 <courmisch> or is it to a file?
Aug 03 19:52:15 <denkenz> file
Aug 03 19:52:36 <naouri> hello is there any documentation how to run and test ofono on phone and wich phone it works or phone simulator  and to guet involved debuging don t know how to start 
Aug 03 19:52:37 <courmisch> then you're screwed. Turn FORTIFY_SOURCE off or take Werror out
Aug 03 19:52:58 <denkenz> exactly, one of those times the warning is bogus
Aug 03 19:53:40 <denkenz> naouri: There isn't yet, but people here can help you get started.  The only phone quasi working with oFono today is the OpenMoko GTA01 or GTA02
Aug 03 19:54:05 <courmisch> well the real question is, what to do if the file write actually fails? (which can always happen)
Aug 03 19:54:20 <courmisch> maybe the file should be deleted and an error sent to log
Aug 03 19:54:21 <denkenz> we simply read from SIM
Aug 03 19:55:05 <denkenz> Though really, opening a file, lseeking and then getting a failure? Could happen
Aug 03 19:55:10 <courmisch> AFAIK, the glibc rationale is that write() can always fail
Aug 03 19:55:32 <naouri> denkenz  what about modem or phone simulator 
Aug 03 19:55:44 <courmisch> it can happen if the device gets full, or if there is a hardware error, at least
Aug 03 19:56:08 <denkenz> naouri: phone simulator works as well, but you are better off waiting for oFono to release it publically (its modified Qtopia phonesim)
Aug 03 19:56:17 <denkenz> naouri: We have a slightly fixed up version
Aug 03 19:56:22 <dilinger> denkenz: so, uh, going back to the SMS send stuff; at_cmgs_cb has a dump_response right at the start of it
Aug 03 19:56:43 <dilinger> denkenz: but i don't see that in the output
Aug 03 19:56:57 <denkenz> dilinger: exactly, the modem isn't sending a prompt
Aug 03 19:57:06 <denkenz> dilinger: Or sending a prompt that is malformed
Aug 03 20:00:40 <denkenz> courmisch: so where does it end, considering unlink also returns stuff :)
Aug 03 20:01:29 <dilinger> so it's pushed onto the tx queue, tx_next is scheduled; tx_next is called, but it never makes it as far as ops->submit
Aug 03 20:01:57 <courmisch> denkenz: unlink is not warn_unused_result, is it?
Aug 03 20:02:19 <naouri> denkenz  i see just have to wait for a while lol , i had compiled ofono on ubuntu 64  station and i don t know what i do just read a code source and try to understand it lol 
Aug 03 20:03:07 <denkenz> naouri: You can always try with any device that you have, some are known to work OK (like some Nokia devices, and Sony Ericcson)
Aug 03 20:04:54 <denkenz> courmisch: Don't know if it is today, but it can be in the future anyway
Aug 03 20:05:51 <denkenz> dilinger: How could that be, there's nothing preventing it from getting to ops->submit?
Aug 03 20:06:03 <naouri> denkenz I have motorolal7    just wondering if i can usued it 
Aug 03 20:07:11 <denkenz> naouri: Try and see
Aug 03 20:07:37 <dilinger> denkenz: nm.  i was looking at at_cmgs_cb rather than at_cmgs
Aug 03 20:08:46 <naouri> okay thank s guys hope i cach u again  have a nice day bye 
Aug 03 20:12:44 <courmisch> 0x8e5b368] libmpeg2 decoder error: DpbDisplayPicture called on an invalid picture
Aug 03 20:12:44 <courmisch> [0x8e5b368] libmpeg2 decoder error: DpbUnlinkPicture called on an invalid picture
Aug 03 20:12:48 <courmisch> oups
Aug 03 20:30:11 <dilinger> denkenz: yeah.. something's stopped the tx stuff from happening
Aug 03 20:30:13 <dilinger> ** (ofonod:9929): DEBUG: queue length: 2
Aug 03 20:30:31 <dilinger> prior to that:
Aug 03 20:30:38 <dilinger> can write data!
Aug 03 20:30:38 <dilinger> ofonod[9929]: > AT+COPS=?\r (10 bytes)
Aug 03 20:30:38 <dilinger> ofonod[9929]: < [WCDMA] Current RRC Status = 0\r\n (32 bytes)
Aug 03 20:31:14 <dilinger> at that point, queue length (this is the txq) is 1.  we send the SMS, txq is 2, but we're already stuck
Aug 03 20:31:43 <denkenz> AT+COPS=? can take a while
Aug 03 20:32:05 <denkenz> But no more than 3 mins or so
Aug 03 20:32:05 <dilinger> just now:
Aug 03 20:32:06 <dilinger> ofonod[9929]: < \r\n+COPS: (1,"Voicestream Wire","VSTREAM","31026",0),(2," T-Mobile?e"," TMO@","310260",2),(1,"Cingular","Cingular","310410",0),,(0,1,2,3,4),(0,1,2)\r\n\r\nOK\r\n (154 bytes)
Aug 03 20:32:33 <dilinger> and nothing's happening at this point
Aug 03 20:32:53 <dilinger> attempting to send another SMS doesn't even get as far as tx_next
Aug 03 20:33:05 <denkenz> Probably because [WCDMA] is not a valid AT line
Aug 03 20:33:09 <denkenz> its confusing the parser
Aug 03 20:38:15 <balrog__> courmisch: if the write() to a file during SIM read, the file will be shorter and will be treated as if it didn't exist and perhaps get overwritten next time the SIM is read
Aug 03 20:38:44 <balrog__> in theory write()s and read()s should be in loops, checking for EAGAIN and short writes
Aug 03 20:40:12 <denkenz> There's a second issue, where you write the info
Aug 03 20:40:22 <balrog__> I did look at file io in bluez though and it didn't bother doing that so I thought it's probably standard
Aug 03 20:40:30 <denkenz> If that fails, you still can potentially write the contents or attempt to anyway
Aug 03 20:41:04 <courmisch> denkenz: EAGAIN cannot occur on a regular file
Aug 03 20:41:50 <courmisch> http://www.remlab.net/op/nonblock.shtml
Aug 03 20:42:55 <denkenz> that isn't the issue here
Aug 03 20:43:05 <denkenz> we don't nonblock these
Aug 03 20:43:14 <denkenz> And EAGAIN can't happen, like Remi says
Aug 03 20:43:16 <balrog__> denkenz: the contents will also never get read if the info (the GET RESPONSE info) couldn't be read in
Aug 03 20:44:13 <courmisch> this whole non-blocking hoax comes from some stupid glib guys who posted some "clever" blog article that "blocking file I/O was evil"
Aug 03 20:44:15 <denkenz> Again, my opinion is these are fine the way they are
Aug 03 20:44:27 <denkenz> But we need to squash the warnings
Aug 03 20:44:48 <courmisch> #undef _FORTIFY_SOURCE
Aug 03 20:47:39 <denkenz> balrog__: I'm not sure about that.  you use lseek and write in retrieve_cb
Aug 03 20:48:02 <denkenz> balrog__: Suppose info write failed, won't that result in garbage in the initial header?
Aug 03 20:50:09 <denkenz> I suggest we simply unlink the file in all cases that write fails
Aug 03 20:50:19 <balrog__> denkenz: whoah, true
Aug 03 20:50:21 <denkenz> Though the likelyhood of this happening is probably astronomical
Aug 03 20:50:48 <balrog__> it'll result in zeros filled in in the places we didn't write to
Aug 03 20:51:05 <balrog__> or set op->cache to zero
Aug 03 20:51:40 <denkenz> Or both even
Aug 03 20:52:22 <balrog__> i'll send a patch, i'll also cast the writes and reads to (void) where we explicitely ignore result
Aug 03 20:53:08 <denkenz> how will you check the return?
Aug 03 20:53:56 <balrog__> i won't cast to void where we want to check the return value :)
Aug 03 20:54:06 <balrog__> i think casting to void removes the warning? (i may be wrong)
Aug 03 20:54:19 <denkenz> well, there's only two places right now where the warning shows up
Aug 03 20:54:28 <denkenz> sim.c 347, 473
Aug 03 20:55:03 <denkenz> 347 is probably ok to cast to void
Aug 03 20:55:18 <denkenz> though better to simply unlink there as well
Aug 03 20:55:28 <denkenz> 473 you definitely want to unlink / cached = false
Aug 03 20:57:09 <balrog__> ok
Aug 03 20:57:36 <balrog__> iirc it's common to wrap writes and reads in a macro called TFR(), e.g. TFR(write(blah)), which is either defined in our own code or somewhere in standard headers with _GNU_SOURCE and that checks for EINTR
Aug 03 20:58:58 <denkenz> I think that's just being paranoid
Aug 03 20:59:29 <denkenz> but it could be useful, submit as a separate patch and see what holtmann says
Aug 03 21:16:11 <courmisch> checking for EINTR makes sense... if we have at least one signal handler
Aug 03 23:07:22 <denkenz> balrog__: The pop to peek patch makes no sense
Aug 03 23:08:18 <denkenz> Shouldn't we be popping the command off?
Aug 03 23:14:19 <denkenz> Ah I see, that patch is wrong, since you don't pop head on a success
Aug 03 23:16:27 <dilinger> denkenz: so i added a new state called PARSER_STATE_GARBAGE, and i have the parser transition to that state when it starts getting data that's not \r and it's in IDLE state (and NO_LEADING_CRLF isn't set)
Aug 03 23:17:08 <dilinger> denkenz: that seems to fix the issue of the parser getting confused (previously, it was staying in idle state until it reached the line's trailing \r, at which point it thought it should be getting more data..)
Aug 03 23:17:08 <denkenz> dilinger: Sounds good so far
Aug 03 23:18:52 <denkenz> dilinger: Though in your case the data is crlf terminated, which makes it even more fun to figure out wtf is going on
Aug 03 23:19:15 <dilinger> denkenz: it would be really nice to have different debug zones, fwiw
Aug 03 23:19:36 <dilinger> denkenz: if i want to see what's going across the serial line, vs if i want to see what the parser is up to.. etc
Aug 03 23:20:29 <denkenz> dilinger: True, feel free to suggest something.  I'll probably take your read/write debug stuff at least
Aug 03 23:20:40 <dilinger> so anyways, i send a msg..
Aug 03 23:20:49 <dilinger> ofonod[13465]: > AT+CMGS=23\r (11 bytes)
Aug 03 23:20:57 <dilinger> ofonod[13465]: newline missing, appending one
Aug 03 23:21:02 <dilinger> ofonod[13465]: < > \r\n (4 bytes)
Aug 03 23:21:53 <denkenz> err
Aug 03 23:21:57 <denkenz> WTF is wrong with this modem
Aug 03 23:22:20 <denkenz> the TA shall send a four character sequence <CR><LF><greater_than><space> (IRA 13, 10, 62, 32) after command line is terminated with <CR>; after that text can be entered from TE to ME/TA.
Aug 03 23:22:40 <denkenz> This is the spec for how to send a CMGS
Aug 03 23:22:44 <dilinger> but ok
Aug 03 23:22:52 <dilinger> so we're missing the CRLF there as well
Aug 03 23:23:10 <denkenz> The leading, there should be no terminal one
Aug 03 23:23:15 <dilinger> ..except that > shouldn't be treated as garbage (which is what it currently does).  sigh.
Aug 03 23:23:35 <denkenz> Btw, this works on every sane modem I've tested
Aug 03 23:23:38 <dilinger> right, the leading CRLF
Aug 03 23:25:33 <denkenz> So the modem simply sends '> ' without crlf? or are your changes eating it somehow?
Aug 03 23:27:03 <dilinger> i just found the ril code
Aug 03 23:27:12 <dilinger> http://android.git.kernel.org/?p=platform/hardware/ril.git;a=blob;f=reference-ril/atchannel.c;h=f878b351a2444e6c82e515b070661320e5b9b23d;hb=HEAD
Aug 03 23:27:18 <dilinger> well, i'm assuming that's the ril code
Aug 03 23:27:55 <dilinger> the readline() function simply ignores the leading CRLF
Aug 03 23:28:21 <dilinger> that would explain why it doesn't spit up when the modem does this
Aug 03 23:28:30 <dilinger> (also, c++.. ugh)
Aug 03 23:29:02 <denkenz> nod, it might be that we need to make the parser state pluggable in gatchat
Aug 03 23:29:27 <denkenz> I was hoping the quirk flags would take care of most of the issues
Aug 03 23:29:58 <denkenz> but if a modem is braindead that it can't follow 27.007, there's maybe no hope anyway :)
Aug 03 23:31:11 <denkenz> You can try enabling that in gatchat as well btw, (ignoring the leading crlf)
Aug 03 23:31:27 <denkenz> You'll get a bunch of false lines, but it might get you there
Aug 03 23:31:59 <dilinger> denkenz: is there an absolute need to look for leading CRLF?
Aug 03 23:32:21 <dilinger> denkenz: if enough modems screw this up, maybe it's worth just ignoring the leading CRLFs?
Aug 03 23:33:24 <denkenz> You end up breaking other stuff
Aug 03 23:33:45 <denkenz> As you now have to introduce command knowledge into the parser itself
Aug 03 23:34:06 <dilinger> i see
Aug 03 23:34:34 <dilinger> so it's more the desire to keep command and parser stuff separate..
Aug 03 23:34:55 <denkenz> Nod, and uncomplicated
Aug 03 23:35:50 <denkenz> And I don't want to go the regexp route
Aug 03 23:39:23 <denkenz> Still, the no_leading_crlf quirk might get you there
Aug 03 23:47:05 <denkenz> btw, the missing \n is a known bug on HTC modems apparently
Aug 03 23:47:19 <denkenz> after the +CMS ERROR
Aug 03 23:48:05 <dilinger> should that be quirk'd, or is it safe to just always add a newline if it isn't there?
Aug 03 23:49:19 <denkenz> it should be quirked
Aug 03 23:49:31 <denkenz> Lets stay pure for proper modems
Aug 04 00:13:41 <balrog__> denkenz: yeah, sorry, i'll send a proper fix tomorrow
Aug 04 00:14:34 <balrog__> it's the error handling that's wrong and apparenlty i changed whatever caught my eye to just make it work in one use case
Aug 04 00:19:26 <denkenz> nod, in either case it works for one path and breaks the other
Aug 04 00:39:42 <denkenz> dilinger: If you want, we can get rid of quirks and make the parser something a client can override
Aug 04 00:41:19 <denkenz> dilinger: we might have to expose have_line & have_pdu and see what can be done about guess_multiline state
Aug 04 01:23:36 <tmzt> is it working on g1 then?
Aug 04 01:24:30 <tmzt> the HTC modmems default into e0v0 mode for some reason
Aug 04 01:46:28 <denkenz> kinda, the modem sends weird [WCDMA] command that doesn't have crlf
Aug 04 01:46:35 <denkenz> So it throws the parser off
Aug 04 01:51:43 <tmzt> what is it?
Aug 04 01:56:08 <denkenz> [15:30] <dilinger> ofonod[9929]: < [WCDMA] Current RRC Status = 0\r\n (32 bytes)
Aug 04 01:56:20 <denkenz> no leading crlf as you can see
Aug 04 02:52:14 <tmzt> ah
Aug 04 02:52:24 <tmzt> put it in ATE1V1
Aug 04 02:52:37 <tmzt> after reset
Aug 04 02:53:09 <dilinger> tmzt: we're already sending ATV1
**** ENDING LOGGING AT Tue Aug 04 02:59:57 2009

**** BEGIN LOGGING AT Tue Aug 04 02:59:57 2009
Aug 04 03:06:20 <dilinger> tmzt: the crlf is still missing from that and some prompts
Aug 04 03:12:50 <tmzt> oh, ok
Aug 04 10:00:14 <Sage> When there is incoming call should this send busy signal to the caller: dbus-send --system --print-reply --dest=org.ofono /modem1/voicecall01 org.ofono.VoiceCall.Busy
Aug 04 10:01:45 <Sage> I'm getting "method return sender=:1.174 -> dest=:1.238 reply_serial=2" as a response and the call is still incoming and phone ringing.
Aug 04 14:26:21 <denkenz> Sage: Busy or Hangup should work in the incoming call case
Aug 04 14:27:02 <denkenz> Sage: What I find funny is that sending Busy works (it sends back a reply that isn't an error) but the modem doesn't drop the call
Aug 04 14:28:58 <denkenz> Sage: In the case of the 6100, can you check whether +CLCC even works on that modem?  Its reporting an error and without it the reference implementation won't work
Aug 04 19:43:54 <dilinger> denkenz: fyi, simply setting G_AT_CHAT_FLAG_NO_LEADING_CRLF causes ofono to hang after issuing ATV1
Aug 04 19:44:48 <denkenz> dilinger: Nod, I later realized it probably would
Aug 04 19:45:08 <denkenz> I think it literally means no leading crlf, not just ignore it
Aug 04 19:46:47 <denkenz> I will fix gatchat to enable custom parsers, since this is the only fully flexible way
Aug 04 19:47:03 <dilinger> i get a weird result when looking for a prompt
Aug 04 19:47:07 <dilinger> http://pastebin.com/m25c5c77f
Aug 04 19:52:22 <denkenz> I don't know what's going there
Aug 04 20:01:41 <dilinger> denkenz: how is this supposed to work?
Aug 04 20:02:12 <dilinger> "After invoking the write command wait for the prompt ">" and then start to write the message. "
Aug 04 20:02:43 <denkenz> Ok, ofono submits a PDU + tpdu length
Aug 04 20:03:17 <dilinger> yep
Aug 04 20:03:18 <denkenz> which results in AT+CMGS=<tpdu_length>\r<PDU>
Aug 04 20:03:32 <denkenz> gatchat sends the command up until and including the \r
Aug 04 20:03:37 <denkenz> and waits until it gets the prompt
Aug 04 20:04:03 <denkenz> at that point it sends more of the command, terminated by CtrlZ
Aug 04 20:04:15 <dilinger> what code actually sends the PDU?
Aug 04 20:04:17 <denkenz> If there are multiple \r, then multiple prompts will be waited for
Aug 04 20:04:40 <dilinger> at_cmgs sends the AT+CMGS=<tpdu_len>\r
Aug 04 20:04:43 <dilinger> and encodes PDU
Aug 04 20:04:51 <denkenz> drivers/atmodem/sms.c
Aug 04 20:05:29 <dilinger> but the callback appears to be at_cmgs_cb, and it looks to me like it's looking for +CMGS: prefix
Aug 04 20:06:05 <denkenz> Yes, so the result of the AT+CMGS shenanigans should be a +CMGS: <mr>\r\n\r\nOK\r\n
Aug 04 20:06:14 <denkenz> or ERROR
Aug 04 20:06:33 <dilinger> ok, so something in gatchat should be sending the PDU
Aug 04 20:06:38 <dilinger> after receiving the prompt
Aug 04 20:07:06 <denkenz> grep for STATE_PROMPT_COMPLETE
Aug 04 20:08:44 <dilinger> ** (ofonod:449): DEBUG: byte == ' ', state == 13
Aug 04 20:09:00 <dilinger> so that's in STATE_PROMPT, it should be setting STATE_PROMPT_COMPLETE
Aug 04 20:09:25 <dilinger> and thus we wake up writer
Aug 04 20:09:45 <denkenz> yep
Aug 04 20:11:10 <dilinger> i guess what i'm not understanding is.. we have a buffer 'pdu' that's associated with that command
Aug 04 20:11:34 <dilinger> at_cmsg encodes it, but it doesn't send it off w/ the command
Aug 04 20:11:40 <denkenz> sure it does
Aug 04 20:12:10 <denkenz> Look more carefully at the encode_hex call
Aug 04 20:13:28 <dilinger> oh, it appends it to buf?
Aug 04 20:13:50 <denkenz> yah
Aug 04 20:14:17 <dilinger> ah.  subtle :(
Aug 04 20:14:18 <dilinger> thanks
Aug 04 20:23:34 <dilinger> the modem keeps getting stuck after the ATV1.  sigh.  i'm getting pretty demotivated..
Aug 04 20:24:17 <denkenz> Ok first thing first, is your debugging patch in a state where you can submit it to the ML?
Aug 04 20:25:28 <dilinger> no, i need to rework it.  i was planning to send everything at once, but it's looking like that's not going to happen.
Aug 04 20:25:44 <denkenz> nah, send things in small logical chunks
Aug 04 20:25:47 <denkenz> easier for me to review
Aug 04 20:25:51 <dilinger> i'll keep working on it a bit, and if i fail to get SMS working today i'll just update patches and send
Aug 04 20:26:02 <dilinger> right, i meant a series of patches though
Aug 04 20:27:23 <denkenz> Ok, so tell me your setup right now, you set the no_leading_crlf flag?
Aug 04 20:27:51 <dilinger> no, setting the no_leading_crlf flag consistently gets stuck at ATV1
Aug 04 20:28:36 <denkenz> Ok, so part of the problem is that sending ATV1 we don't know whether the modem replies in V1 mode or V0 mode
Aug 04 20:28:47 <denkenz> This should be done outside of gatchat
Aug 04 20:29:25 <dilinger> right now i'm sending ATV1, expecting CRLFs; i've got a workaround for commands that lack newlines, i've got another workaround for garbage from the modem (that [WCDMA] crud that lacks a leading CRLF), and another workaround that looks for '>' when parser is idle and sets state to prompt (rather than thinking that it's garbage)
Aug 04 20:29:52 <dilinger> and i've also got tons and tons of debugging included
Aug 04 20:30:39 <dilinger> for whatever reason, sometimes ATV1 also hangs even when i don't have the no_leading_crlf flag; it seems to be happening randomly. this wasn't happening yesterday. 
Aug 04 20:30:51 <dilinger> rebooting the phone fixes it for at least a little while
Aug 04 20:31:20 <denkenz> So what part of the no leading crlf prompt workaround is not working?
Aug 04 20:31:50 <dilinger> i'm not sure.  it does the same thing (hangs after issuing ATV1 and waiting for a response), but it's consistent
Aug 04 20:31:58 <dilinger> rather than seemingly random
Aug 04 20:34:25 <denkenz> hard to tell without seeing the code
Aug 04 20:37:44 <denkenz> So to sum up, the modem is basically compliant, except it sends random garbage with a <crlf> terminator, but no <crlf> lead, the prompt doesn't have <crlf> lead and the +CMS ERROR is not terminated by <lf>
Aug 04 20:42:45 <dilinger> denkenz: what are your thoughts as to doing something similar to what telepathy does for debugging (except instead of using an ENV variable, taking it via command-line)?  you'd have something like "--debug=all" or "--debug=driver,parser", debug zones that are specified by bits, and each 'zone' passes its name to ofono_debug as the first arg?
Aug 04 20:45:02 <denkenz> Probably we can consider it
Aug 04 20:45:18 <denkenz> Propose it and see what aki & holtmann think
Aug 04 20:46:50 <denkenz> though arguably debugging within a plugin should be a plugin configure option
Aug 04 20:47:05 <denkenz> either via env, file system or other setup
Aug 04 20:47:31 <dilinger> well, i guess if you turn the parser into a plugin, sure
Aug 04 20:48:09 <denkenz> That's why I told you to make gatchat take a debug function as a parameter
Aug 04 20:48:31 <denkenz> Also, there's some stuff in the works which will make writing device drivers a bit easier
Aug 04 20:52:26 <dilinger> i don't really understand the point of making the debug function something you register
Aug 04 20:53:07 <denkenz> Because gatchat is used in oFono and connman today
Aug 04 20:53:16 <denkenz> Eventually probably in other projects too
Aug 04 20:53:37 <dilinger> okay
Aug 04 20:53:43 <denkenz> We can't assume any particular debug architecture
Aug 04 20:53:55 <dilinger> originally the debug stuff ignored gatchat, though, and was just for atmodem
Aug 04 20:54:11 <dilinger> which i believe you said should have the debug function registration as well
Aug 04 20:54:29 <denkenz> plugins are free to do what they want
Aug 04 20:55:29 <denkenz> I really don't want to make this ultra complicated
Aug 04 20:55:53 <denkenz> The debugging issues here are not in atmodem, they're in gatchat and the weird at command syntax the G1 uses
Aug 04 20:56:09 <dilinger> that's why i'm confused by the desire for debug function registrations. i get it for gatchat if you want to use gatchat outside of ofono..
Aug 04 20:56:21 <dilinger> well, no, they're in atmodem as well
Aug 04 20:56:51 <dilinger> i've been sprinkling debugging throughout
Aug 04 20:57:10 <dilinger> atmodem already has a bunch of debugging, which is nice
Aug 04 20:57:21 <denkenz> true, but those are peripheral, they're not what is causing this stuff to fail
Aug 04 20:57:59 <dilinger> i really don't care what the underlying mechanism looks like; whatever gets it accepted, really
Aug 04 20:58:14 <denkenz> nod, again, propose something
Aug 04 20:58:49 <denkenz> For gatchat we want debug function registration, for oFono, lets see
Aug 04 20:59:02 <dilinger> gotcha
Aug 04 20:59:03 <dilinger> okay
Aug 04 20:59:20 <dilinger> knowing that gatchat is used in other projects is helpful for designing such a thing
Aug 04 23:56:02 <denkenz> dilinger: Try http://pastebin.ca/1518539 & http://pastebin.ca/1518540
Aug 04 23:56:38 <denkenz> dilinger: You can create your own parser specifically for G1
Aug 04 23:56:56 <denkenz> dilinger: Still highly experimental though
Aug 05 00:55:47 <dilinger> denkenz: nifty.  do you happen to have a git branch or repo that i can work from and use as a base?
**** ENDING LOGGING AT Wed Aug 05 02:59:56 2009

**** BEGIN LOGGING AT Wed Aug 05 02:59:56 2009
Aug 05 03:01:38 <denkenz> dilinger: So far its in my master tree
Aug 05 03:01:52 <denkenz> dilinger: It seems to work on phonesim, so I just need to test it some more
Aug 05 03:02:03 <denkenz> dilinger: Everything goes well, I push it out soon
Aug 05 03:03:22 <dilinger> where's your master tree? :)
Aug 05 03:03:52 <denkenz> dilinger: its local right now, my git-fu is still kinda low
Aug 05 03:08:57 <dilinger> ok
Aug 05 03:09:25 <denkenz> dilinger: See if you can whip out a ~50 line parser to take care of the G1 :)
Aug 05 03:15:17 * dilinger has some frozen yogurt that urgently requires my undivided attention first ;)
Aug 05 18:34:48 <denkenz> holtmann: Any more news on api docs?
Aug 05 21:35:01 <dilinger> denkenz: once you commit the separate parser stuff, i'll send another debugging patch for it (the debug function becomes another parameter to g_at_syntax_new*)
Aug 05 21:35:21 <denkenz> err?
Aug 05 21:35:33 <denkenz> what does it have to do with syntax?
Aug 05 21:36:29 <dilinger> denkenz: gatchat knows nothing of debug zones; all it knows is debug callbacks
Aug 05 21:36:51 <dilinger> right now, the parser state stuff is contained within a GAtChat object
Aug 05 21:37:00 <dilinger> as is the channel writing stuff
Aug 05 21:37:18 <denkenz> Why do you need to debug the parser state?
Aug 05 21:37:35 <dilinger> because it's gotten stuck before?
Aug 05 21:39:05 <denkenz> I doubt you actually want to debug the parser state, that's just waay too detailed
Aug 05 21:39:29 <denkenz> Simple in/out from/to modem is enough
Aug 05 21:42:12 <dilinger> that's part of the reason for having debug zones
Aug 05 21:42:26 <dilinger> it may be too detailed, but you don't have to see it if you run w/ -d
Aug 05 21:42:39 <dilinger> only if you specifically select it via --debug=atparser
Aug 05 21:43:16 <dilinger> anyways, i don't care as much about that..  i'm hoping i'm actually done debugging the parser ;)
Aug 05 21:46:27 <denkenz> Trouble is you still pay the cost, which is nasty for per-character things
Aug 05 21:48:11 <dilinger> it should just be a function call
Aug 05 21:48:15 <dilinger> per character
Aug 05 21:48:25 <dilinger> er, sorry, not even that
Aug 05 21:48:52 <dilinger> if (syntax->debugf) syntax->debugf(...)
Aug 05 21:49:23 <dilinger> see the way i've done the gatchat debug stuff.  it only sets debugf if the flag is specified with --debug...
Aug 05 21:52:15 <denkenz> Can we make the debugf settable / gettable using something like set_debug_info(chat, func, data)?
Aug 05 21:52:51 <dilinger> sure, but to what end?
Aug 05 21:53:03 <denkenz> So you can turn debugging on / off
Aug 05 21:53:30 <dilinger> but you can't adjust the zones on the fly
Aug 05 21:53:46 <denkenz> but gatchat is used in multiple projects ;)
Aug 05 21:54:02 <dilinger> right, gotcha
Aug 05 21:54:51 <denkenz> Also, break up the patch into two
Aug 05 21:55:01 <dilinger> denkenz: mind following up to the list w/ comments?
Aug 05 21:55:05 <denkenz> One for gatchat, one for the zones stuff
Aug 05 21:55:05 * dilinger is about to run out for a little bit
Aug 05 21:55:11 <denkenz> sure no prob
Aug 05 21:55:14 <dilinger> thanks
Aug 05 21:55:15 <dilinger> bbl
Aug 06 02:10:08 <dilinger> denkenz: can you clarify your last comment?
Aug 06 02:10:16 <dilinger> "make the signature a simple void (*foo)(const char *str, void *data);"
Aug 06 02:10:25 <dilinger> you mean drop the printf format checking attribute?
Aug 06 02:10:33 <dilinger> or don't use a formatter at all?
Aug 06 02:21:13 <denkenz> just send string and length
Aug 06 02:25:17 <dilinger> the backported initramfs-tools should load redboot first
Aug 06 02:25:24 <dilinger> er, EWIN
**** ENDING LOGGING AT Thu Aug 06 02:59:57 2009

**** BEGIN LOGGING AT Thu Aug 06 02:59:57 2009
Aug 06 11:06:23 <admiral0> hello 
Aug 06 11:07:46 <admiral0> i would like to know what difference there is between freesmartphone.org(FSO) and ofono
Aug 06 11:07:56 <admiral0> are there the same APIs
Aug 06 11:07:57 <admiral0> ?
**** ENDING LOGGING AT Fri Aug 07 02:59:57 2009

**** BEGIN LOGGING AT Fri Aug 07 02:59:57 2009
Aug 07 05:18:36 <Sage> denkenz: It still segfaults, I posted the new segfault to ML.
Aug 07 18:58:06 <dilinger> denkenz: thanks for committing the first patch, but.. i don't get why you dropped the zone stuff
Aug 07 18:58:28 <denkenz> I haven't dropped it, holtmann needs to comment on it first
Aug 07 18:59:25 <dilinger> okay
Aug 07 18:59:26 <denkenz> That's why I asked you to separate them, btw
Aug 07 18:59:31 <dilinger> ah
Aug 07 19:02:09 <holtmann> denkenz: Fill me in.
Aug 07 19:03:08 <denkenz> holtmann: dilinger is proposing that we implemented 'zoned' debug
Aug 07 19:03:29 <denkenz> holtmann: You specify the zone at startup, and plugins can adjust their debugging accordingly
Aug 07 19:03:47 <holtmann> Might be not a bad idea. Do we have a patch for it?
Aug 07 19:03:53 <denkenz> holtmann: yeah its on the ML
Aug 07 19:05:02 <denkenz> It needs to be cleaned up a little most likely, but lets agree whether the concept is good
Aug 07 19:05:36 <holtmann> I think the idea is a good one. With ConnMan we reached a limit where debug output became pointless.
Aug 07 19:06:22 <holtmann> We could also see if we can make debug on a per plugin basis. That needs some fancy GCC hacking tricks though.
Aug 07 19:06:28 <denkenz> holtmann: Nod, I like it as well, wish you could adjust debugging dynamically though
Aug 07 19:06:59 <denkenz> holtmann: Perhaps by way of signals, inotify or other trickery
Aug 07 19:07:17 <holtmann> Lets cleanup the patches and have them send to the mailing list again. I have a look then.
Aug 07 19:08:26 <denkenz> dilinger: Can you rebase and resubmit the patch for zoned debug again, do it as is for now and lets go from there
Aug 07 19:09:11 <dilinger> sure
Aug 07 19:12:36 <dilinger> i'll ponder ways to adjust things dynamically as well, but not today.  my brain hurts from elevation changes
Aug 07 20:54:18 <denkenz> holtmann: I need to still look at the segfault on remove problem, otherwise we should be OK for release.  Any chance of you dumping the docs into the repo beforehand?
Aug 07 23:39:38 <holtmann> denkenz: I am on and off right now. Can we do that some time during the weekend.
Aug 07 23:40:01 <denkenz> holtmann: If I'm around ;)
Aug 07 23:40:31 <holtmann> If you fixed everything, do I need you around for it?
Aug 07 23:40:54 <denkenz> holtmann: Probably not
Aug 07 23:41:34 <denkenz> I give you the go ahead once I'm done, if not we wait for Monday
Aug 07 23:41:45 <holtmann> When you are heading offline for the weekend, then just tell me if it is ready or not, then I look at it during the weekend. Either it becomes a release or we do it next week.
Aug 07 23:42:09 <denkenz> nod, I do wanna see the api docs in our next release though
Aug 07 23:42:19 <denkenz> otherwise we should hold off
Aug 07 23:42:47 <holtmann> I just don't have time right now and will be most likely offline in a few minutes. I push the docs before the release. Have to see if they are still up-to-date. If not we can fix that in the next release :)
Aug 07 23:43:01 <denkenz> lol ok
Aug 08 01:16:44 <denkenz> holtmann: We should be good to go for a release
**** ENDING LOGGING AT Sat Aug 08 02:59:57 2009

**** BEGIN LOGGING AT Sat Aug 08 02:59:57 2009
Aug 08 09:44:30 <tmzt> what type of environment is the g1 driver being tested in? angstrom, etc. and what kernel?
Aug 08 20:53:05 <dilinger> tmzt: i'm using a 1.5adp+LF build
Aug 08 23:42:06 <dilinger> hrmph.  latest git fails to build
Aug 09 01:45:38 <tmzt> dilinger: what does that mean?
**** ENDING LOGGING AT Sun Aug 09 02:59:57 2009

**** BEGIN LOGGING AT Sun Aug 09 02:59:57 2009
Aug 09 04:26:30 <dilinger> tmzt: sorry, i meant JF
Aug 09 04:27:11 <dilinger> tmzt: http://jf.andblogs.net/2009/05/24/jfv151-images-are-out/
Aug 09 04:35:58 <tmzt> oh, so you are using an android image
Aug 09 04:35:59 <tmzt> I see
Aug 09 04:36:21 <tmzt> we (in #htc-linux) are currently working on a clean kernel and rootfs for the g1
Aug 09 04:43:34 <dilinger> oh, sorry
Aug 09 04:43:38 <dilinger> i should've been clearer
Aug 09 04:44:07 <dilinger> so yeah, i'm running that image, but i have a debian chroot that i'm using to build & run ofono
Aug 09 04:45:08 <dilinger> kind of a messy setup atm, but i'm just using it to bootstrap this stuff and get it working
Aug 09 04:46:12 * dilinger sleeps
**** ENDING LOGGING AT Mon Aug 10 02:59:57 2009

**** BEGIN LOGGING AT Mon Aug 10 02:59:57 2009
Aug 10 13:29:34 <Strid> Hi, I wonder when there will be similar handsets available with ofono?
Aug 10 13:31:35 <Strid> iphone similar
Aug 10 16:14:20 <denkenz> holtmann: No release?
**** ENDING LOGGING AT Mon Aug 10 21:05:15 2009

**** BEGIN LOGGING AT Mon Aug 10 23:46:18 2009
**** ENDING LOGGING AT Tue Aug 11 02:59:57 2009

**** BEGIN LOGGING AT Tue Aug 11 02:59:57 2009
Aug 12 01:20:43 * dilinger wishes someone would fix the build errors for ARM
Aug 12 02:30:20 <dilinger_> denkenz: ping
Aug 12 02:57:21 <denkenz> dilinger: Pong
**** ENDING LOGGING AT Wed Aug 12 02:59:57 2009

**** BEGIN LOGGING AT Wed Aug 12 02:59:57 2009
Aug 12 03:02:22 <dilinger_> denkenz: had a couple questions.  the G1 lists manufacturer/model as HTC/HTC, so i was going to specify the g1 syntax and handling by a dbus arg (passing "g1" rather than "at").  that sound in line with what you expect?
Aug 12 03:02:50 <dilinger> denkenz: #2, was wondering about the status of patches i resent to the list
Aug 12 03:05:18 <denkenz> dilinger: #1 sounds fine, but there's a new driver framework coming soon
Aug 12 03:05:48 <denkenz> dilinger: #2, I'm waiting for holtmann to review your patch for zoned debug
Aug 12 03:06:09 <denkenz> dilinger: Is there anything else for #2?
Aug 12 03:06:40 <dilinger> denkenz: the ATZ init patch
Aug 12 03:07:14 <dilinger> denkenz: and #3, i was going to hardcode the CNMI string for at->driver == g1 in atmodem/sms.c.  is there a better way to be doing that?
Aug 12 03:07:57 <denkenz> dilinger: ATZ should be sent in the same if (!strcmp(driver, "g1")) part
Aug 12 03:08:07 <denkenz> dilinger: Again, the new driver framework will make it much easier
Aug 12 03:08:24 <denkenz> dilinger: For #3, I'd rather you just write a sms driver specific for G1
Aug 12 03:08:34 <denkenz> dilinger: You can skip much of the initialization code
Aug 12 03:09:21 <dilinger> hm
Aug 12 03:09:31 <dilinger> that's a lot of duplicate code then, no?
Aug 12 03:10:02 <dilinger> also, i'm assuming that depends upon the new driver framework?
Aug 12 03:10:17 <denkenz> dilinger: A little, you'd be duplicating the CMT/CMTI notifications mostly
Aug 12 03:10:46 <denkenz> dilinger: and not really dependent, but made easier
Aug 12 03:11:02 <dilinger> so should i just be waiting, then?
Aug 12 03:11:43 <denkenz> diliger: Well, write a G1 implementation in a separate file
Aug 12 03:12:01 <denkenz> dilinger: Then just if (!strcmp(driver, "g1")) g1_sms_init()
Aug 12 03:13:35 <dilinger> oh, i see what you're saying.   rather than calling at_sms_init..
Aug 12 03:15:59 <dilinger> you really think that the ATZ init patch should be g1 specific?  i figured you'd always want to specify that to ensure all modems are in the same state..
Aug 12 03:19:45 <denkenz> dilinger: That one is debatable
Aug 12 03:20:08 <denkenz> dilinger: With the new driver framework it'll be moot anyway
Aug 12 03:47:40 <dilinger> okay
Aug 12 04:22:26 <denkenz> holtmann: Can you review Andres' patch btw?
Aug 12 04:22:47 <holtmann> denkenz: Sure. Give me a hint which one.
Aug 12 04:22:58 <denkenz> holtmann: Resend add zoned debug support from 8/8
Aug 12 04:25:49 <holtmann> -int __ofono_log_init(gboolean detach, gboolean debug);
Aug 12 04:25:49 <holtmann> +int __ofono_log_init(gboolean detach, gboolean debug, guint dflags);
Aug 12 04:26:09 <holtmann> I just reply to the email. So we have a record of it. So nevermind.
Aug 12 04:32:36 <holtmann> Sent.
Aug 12 04:37:17 <denkenz> holtmann: You're advocating replacing all instances of ofono_debug with DBG?
Aug 12 04:38:00 <holtmann> No. Fix all callers of ofono_debug with the proper zone.
Aug 12 04:38:42 <denkenz> Ah, btw, it might make sense to replace ofono_debug uses inside core to DBG
Aug 12 04:38:52 <denkenz> since that macro was added long after much of the core was written
Aug 12 04:39:11 <denkenz> But either way makes sense
Aug 12 04:42:28 <holtmann> Sure.
Aug 12 05:23:04 <Sage> denkenz: that create/destroy is now working fine.
**** ENDING LOGGING AT Wed Aug 12 05:26:18 2009

**** BEGIN LOGGING AT Wed Aug 12 05:28:14 2009
**** ENDING LOGGING AT Wed Aug 12 05:32:06 2009

**** BEGIN LOGGING AT Wed Aug 12 05:34:16 2009
Aug 12 09:26:06 <Sage> denkenz: Is there any plans of implementing other than AT+CHLD=1<callid> for hangup or AT+CHLD=0 for busy to the default AT driver? Referring to this http://lists.ofono.org/pipermail/ofono/2009-August/000314.html
Aug 12 13:57:32 <Sage> Does oFono currently assume that the modem that is used supports also optional features of 27.007?
Aug 12 15:12:27 <denkenz> Sage: Probably not, oFono might be able to send a hangup all when only 1 call is available instead of using chld
Aug 12 15:12:50 <denkenz> Sage: But even then, some modems will have different meanings for +CHUP vs ATH
Aug 12 15:13:03 <denkenz> Sage: And yes, we assume optional features of 27.007
Aug 12 15:17:47 <denkenz> Sage: Mostly because like half of 27.007 is optional :)
Aug 12 15:43:09 <Sage> denkenz: Do you know any modem that fully supports the 27.007 with optional features? I have tested already 7 Nokia phones already, seems that nokia phone AT set does not have many optional features of 27.007. Other brands might perform better, but haven't been able to get any for testing.
Aug 12 15:43:39 <denkenz> Sage: Yeah Nokia is notorious for having a crappy AT command implementation
Aug 12 15:44:01 <denkenz> Sage: But also keep in mind, this is meant to be used with full feature modems, not something exposed over USB / Bt
Aug 12 15:44:27 <denkenz> Sage: Also, if a feature is not available, usually it is OK
Aug 12 15:44:37 <denkenz> Sage: oFono will simply report the error up
Aug 12 15:45:40 <Sage> if AT+CIMI is not available ofono says that only emergency calls are available, however dialing still works.
Aug 12 15:46:08 <denkenz> Yeah, ignore that :)
Aug 12 15:46:30 <denkenz> Again, on a real phone this would be true
Aug 12 15:47:04 <denkenz> If you're using a mobile phone over USB, the driver might not want to expose the SIM Manager interface for that phone
Aug 12 15:48:04 <Sage> I also noticed that sometimes when calling with ofono the ofono waits for something and the call might start only after 30s or so.
Aug 12 15:48:42 <Sage> During that time, timeout has already occurred for the dbus message.
Aug 12 15:49:00 <denkenz> Sage: export OFONO_AT_DEBUG=1, restart oFono and see what it is
Aug 12 15:49:23 <Sage> I was a bit surpriced when after the timeout the phone started to call. :)
Aug 12 15:49:30 <denkenz> I suspect its a COPS=? running in the background.  We will turn that off unless the phone is multiplexed
Aug 12 15:50:40 <Sage> Well, I guess it is that because most of the cases (not all though) the call starts after the list of networks is printed by ofonod.
Aug 12 15:51:15 <denkenz> Yeah, for now just set the timeout really high
Aug 12 15:51:22 <denkenz> I will fix it in 0.4
Aug 12 15:53:29 <Sage> Ok.
Aug 12 15:58:31 <Sage> With Nokia 6310i the ofonod sometimes prints response 1 OK (the imsi value is (null)) for AT+CIMI eventhough the respose seems to be always ERROR with that phone. This might also be phone related thing.
Aug 12 15:59:39 <Sage> I'll check if I can get more details about that. If this is not known thing?
Aug 12 16:02:20 <denkenz> Nope, never seen that
Aug 12 16:03:39 <denkenz> Unless the parser's confused, that shouldn't happen actually
Aug 12 16:03:51 <denkenz> at_cimi_cb returns on an error
Aug 12 16:17:29 <denkenz> holtmann: If you have those API docs in semi-submittable state, can you push them and cut a 0.3 release?
Aug 12 16:17:53 <denkenz> holtmann: I will start breaking things in a major way for 0.4
Aug 12 23:27:43 <denkenz> dilinger: I try hard to do that, but that was a 1 liner ;)
Aug 12 23:45:19 * dilinger nods
Aug 12 23:45:38 <dilinger> denkenz: i'm seeing a segfault in the new phonebook stuff, btw
Aug 12 23:46:04 <denkenz> backtrace?
Aug 12 23:47:17 <dilinger> waiting for COPS=? to finish
Aug 12 23:47:37 <denkenz> heh, I really need to fix that
Aug 12 23:48:32 <dilinger> http://pastebin.com/m7dce3a5f
Aug 12 23:49:20 <denkenz> whats up with those 0000?
Aug 12 23:49:24 <dilinger> that's going through                         text_utf8 = ucs2_to_utf8(text);
Aug 12 23:50:04 <dilinger> no idea.  those entries were there from the simcard defaults
Aug 12 23:50:22 <denkenz> ugh, that's freaking evil
Aug 12 23:51:13 <denkenz> is it crashing in the at driver or core?
Aug 12 23:51:27 <dilinger> in core
Aug 12 23:51:40 <dilinger> the at driver is calling ofono_phonebook_entry w/ text == NULL
Aug 12 23:52:01 <dilinger> the first thing ofono_phonebook_entry does is strlen(text), so it crashes
Aug 12 23:52:48 <denkenz> Ok, so I'm not up on my VCard standard.  Can you have VCards with no name?
Aug 12 23:53:03 <denkenz> Or should we simply ignore these entries?
Aug 12 23:55:35 <Robot101> nokia S60 phones show them, if they just have a company name for example
Aug 12 23:55:44 <Robot101> series 40 just shows the number
Aug 12 23:55:46 <holtmann> denkenz: Do you want me to hold of building the release for this. I was going to do it right now.
Aug 12 23:56:14 <dilinger> not sure.  should i just email the list and see what folks like Yang Gu have to say?
Aug 12 23:56:29 <denkenz> holtmann: Yah hold off for now, I might push a quick fix and we address this properly later
Aug 12 23:56:54 <holtmann> Okay. Build tests have finished. So I can release this quickly at any time.
Aug 12 23:57:26 <denkenz> Well in dilinger's case we got only a phone number
Aug 12 23:58:01 <denkenz> Robot101: No name or company name.  So about the only thing we can do is store the number as the 'name'
Aug 12 23:58:03 <denkenz> Ugh :P
Aug 12 23:58:56 <Robot101> is the data structure which indexes name -> vcard yours, or something the sim is meant to have?
Aug 12 23:59:03 <Robot101> or does the sim actually just store a list of cards or what?
Aug 12 23:59:12 <denkenz> The SIM is a record based file
Aug 12 23:59:19 <denkenz> So record n will have some fields
Aug 12 23:59:28 <denkenz> any one of them can be blank
Aug 12 23:59:43 <denkenz> Today we assumed that at least the name & number must be there
Aug 13 00:00:21 <denkenz> Because at least according to 27.007 all of these fields are mandatory
Aug 13 00:00:32 <denkenz> Someone at T-mobile didn't get the memo
Aug 13 00:02:07 <Robot101> buh boh
Aug 13 00:02:20 <Robot101> assume that every way the spec can be violated by other devices, it will have been
Aug 13 00:02:35 <Robot101> you will not believe the amount of hassle it is to get vcards sending/receiving safely between devices... :(
Aug 13 00:02:53 <denkenz> Heh, the problem is without both of these fields a VCard is useless
Aug 13 00:03:30 <Robot101> no its not, it stores a phone number :)
Aug 13 00:04:26 <dilinger> denkenz: i should point out that  Phonebook.Import has worked before w/ this same information and sim (i haven't modified the addressbook since then) :)
Aug 13 00:05:24 <denkenz> Robot101: Yah but without a name?  I mean I seriously can just print a vcard without FN field
Aug 13 00:05:34 <denkenz> Robot101: But will anything out there accept it?
Aug 13 00:05:54 <denkenz> dilinger: I don't believe you :)
Aug 13 00:07:24 <holtmann> vcards without FN are not valid.
Aug 13 00:08:05 <denkenz> As I suspected, thanks for confirming
Aug 13 00:08:44 <holtmann> This doesn't mean some devices will successfully import them, but they are not valid vcards :)
Aug 13 00:09:41 <Robot101> well... if you validate data on other people's behalfs based on what /should/ be valid, expect bugs further down the line
Aug 13 00:09:48 <denkenz> Ok, what I'm going to do is generate FN field with number if text field is null or empty
Aug 13 00:10:11 <denkenz> Guys, oFono can't generate !valid VCards
Aug 13 00:10:27 <denkenz> That is simply silly
Aug 13 00:10:41 <Robot101> guess its the number then
Aug 13 00:10:41 <Robot101> :)
Aug 13 00:11:35 <Robot101> nobody else generates valid vcards though, so any phone software which also needs to interop vcards with anyone else is going to have to have a bulletproof vcard parser and not care at all if ofono feeds it misencoded broken crap
Aug 13 00:12:33 <denkenz> Robot101: Because of that philosophy GSM telephony software is a PoS
Aug 13 00:12:46 <denkenz> Robot101: Let us not repeat that
Aug 13 00:13:26 <Robot101> sure, be as correct as you can, but the rest of the system has to be robust when it comes into contact with reality, which sucks :)
Aug 13 00:14:06 <denkenz> dilinger: Try the following http://pastebin.ca/1527301
Aug 13 00:14:22 <dilinger> "be lenient in what you accept and strict in what you output"
Aug 13 00:14:47 <denkenz> yah, oFono is way too lenient actually
Aug 13 00:15:13 <denkenz> Whoever designed SIMs like this should be made to re-read 27.007 many times over
Aug 13 00:16:40 <dilinger> denkenz: i'm pretty sure the last time i exported the phonebook it was over bluetooth, so it could be the case that rild sanitizes the phonebook entries it gets from the hardware
Aug 13 00:17:01 <denkenz> dilinger: That would explain it
Aug 13 00:17:49 <denkenz> dilinger: I bet some Google engineer had fun things to say about T-mobile as well
Aug 13 00:19:00 <denkenz> dilinger: Not to mention the fact that as a user I've no fucking idea what *233 is
Aug 13 00:19:32 <dilinger> denkenz: i expect stupidity from telcos
Aug 13 00:20:07 <denkenz> dilinger: Actually I suspect the default phonebook driver is not suitable for G1
Aug 13 00:20:29 <denkenz> dilinger: There is a varying number of 0s, meaning there is character data
Aug 13 00:20:47 <denkenz> dilinger: But the character set we selected is not reporting it properly
Aug 13 00:21:34 <denkenz> dilinger: So that's a homework problem for you :)
Aug 13 00:22:17 <dilinger> denkenz: patch works
Aug 13 00:22:33 <denkenz> dilinger: Ok
Aug 13 00:22:43 <denkenz> holtmann: Can you eyeball it as well just in case?
Aug 13 00:22:49 <denkenz> holtmann: Then I push and we're good to go
Aug 13 00:23:12 <holtmann> #
Aug 13 00:23:12 <holtmann>         if ((text[len-2] == '/') &&
Aug 13 00:23:12 <holtmann> #
Aug 13 00:23:12 <holtmann>                ((c == 'w') || (c == 'h') || (c == 'm') || (c == 'o')))
Aug 13 00:23:12 <holtmann> #
Aug 13 00:23:12 <holtmann>                return TRUE;
Aug 13 00:23:32 <holtmann> Can I just complain about the indentation here.
Aug 13 00:23:41 <denkenz> sure
Aug 13 00:23:44 <denkenz> what's the problem?
Aug 13 00:23:50 <holtmann> If statements on the second line are at the same as the code. That is bad.
Aug 13 00:24:08 <holtmann> The second line of an if statement should indent twice at least.
Aug 13 00:24:11 <denkenz> Ah yeah
Aug 13 00:24:20 <denkenz> I do that, but sometimes I miss this during reviews
Aug 13 00:24:25 <denkenz> I fix it
Aug 13 00:24:26 <holtmann> Not that you patch did this. It was there before.
Aug 13 00:25:32 <holtmann> Patch looks fine. However question is if we really wanna just add the number as FN here?
Aug 13 00:25:39 <holtmann> Or better ignore that entry.
Aug 13 00:26:08 <denkenz> IMO is this a bizarre case
Aug 13 00:26:32 <denkenz> I think there is character data there, its just being mangled by the modem somehow
Aug 13 00:27:11 <denkenz> So I see no harm in allowing it
Aug 13 00:27:23 <denkenz> Perhaps at the driver level we should print a warning though
Aug 13 00:27:28 <holtmann> So you are hiding the real cause. Could set an empty FN. Just put the FN flied in put leave it "".
Aug 13 00:28:07 <denkenz> Is an empty FN valid?
Aug 13 00:28:54 <denkenz> Also, we would be outputting potentially multiple VCards with an empty FN
Aug 13 00:29:14 <denkenz> Sounds worse than multiple FNs with a phone number as the name
Aug 13 00:29:18 <denkenz> Though not by much :P
Aug 13 00:30:24 <denkenz> Do you want me to add an ofono_error to the driver if text & name result in a NULL?
Aug 13 00:30:34 <holtmann> I am checking that. It should be valid to leave FN empty.
Aug 13 00:31:22 <holtmann> If the spec. doesn't allow it, add an ofono_error. Better would be ofono_warn, but we don't have that.
Aug 13 00:31:40 <holtmann> Actually I am going to add ofono_warn right now. We need that anyway.,
Aug 13 00:32:35 <denkenz> ok, so I leave the patch to the core as is
Aug 13 00:32:50 <denkenz> and I add ofono_warn to the driver if text ends up null or empty
Aug 13 00:34:19 <holtmann> Yes. That is good enough for now.
Aug 13 00:34:27 <holtmann> Pushed.
Aug 13 00:37:51 <holtmann> denkenz: Push the patch and then I build the release.
Aug 13 00:38:01 <denkenz> holtmann: Nod, working on it
Aug 13 00:49:45 <denkenz> pushed
Aug 13 00:49:54 <denkenz> holtmann: eyeball them again just in case
Aug 13 00:58:40 <holtmann> Looks good.
Aug 13 01:00:27 <holtmann> Okay. Making the release now.
Aug 13 01:00:35 <denkenz> holtmann: cool
Aug 13 01:00:53 <denkenz> dilinger: Some of your parser hacks are just evil ;)
Aug 13 01:04:16 <holtmann> Is the G1 really such a fucked up phone? What kind of modem is in there?
Aug 13 01:04:47 <denkenz> Its got an HTC modem, which uses an ericsson chip
Aug 13 01:04:51 <dilinger> denkenz: i thought the newline one was actually nicer before the existence of gatsyntax.  but that code went away, and if there will eventually be a g1_feed.. then i figured what i committed should be good enough
Aug 13 01:05:06 <denkenz> The modem is totally fucked, e.g. it doesn't terminate +CMS ERROR with a newline
Aug 13 01:05:16 <denkenz> sends prompts without leading <cr><lf>, etc
Aug 13 01:05:56 <denkenz> dilinger: Well at least the checking for terminating \n could be better, you're not guaranteed the entire line in one feed session
Aug 13 01:07:45 <denkenz> holtmann: It makes the Calypso modem look sane in comparison
Aug 13 01:08:16 <denkenz> holtmann: Even taking into account Calypso's weird 'go to sleep after 5 seconds of inactivity' semantics
Aug 13 01:10:45 <holtmann> Do we have an AT modem test script that checks for weirdness of the modem. I think we should do something like that so we can check for known misbehavior.
Aug 13 01:11:02 <holtmann> Maybe that way we get vendors to fix the firmware.
Aug 13 01:13:02 <denkenz> we don't and we should, but we haven't really done too much integration yet
Aug 13 01:19:58 <holtmann> Maybe QA could do that for us :)
Aug 13 01:20:46 <holtmann> denkenz: Tarballs are uploading. Feel free to go nuts in repo now. I am off until later.
**** ENDING LOGGING AT Thu Aug 13 01:24:10 2009

**** BEGIN LOGGING AT Thu Aug 13 01:36:14 2009
**** ENDING LOGGING AT Thu Aug 13 01:36:17 2009

**** BEGIN LOGGING AT Thu Aug 13 01:38:14 2009
**** ENDING LOGGING AT Thu Aug 13 02:59:57 2009

**** BEGIN LOGGING AT Thu Aug 13 02:59:58 2009
Aug 13 08:29:51 <Sage> Is this valid response string "+CRING: VOICE\r\n\r\n+CLIP: "+358000000000",145\r\n" or is "\r\n" required in front? Nokia 6610i returns that and ofono is not able to identiry the +CRING at all.
Aug 13 13:31:48 <denkenz> CRING should have a \r\n on the front
Aug 13 20:56:28 <holtmann> In file included from example_history.c:33:
Aug 13 20:56:28 <holtmann> ../src/driver.h:22:25: error: ofono/types.h: No such file or directory
Aug 13 20:56:28 <holtmann> In file included from example_history.c:33:
Aug 13 20:56:28 <holtmann> ../src/driver.h:51: error: field ‘phone_number’ has incomplete type
Aug 13 20:56:28 <holtmann> ../src/driver.h:76: error: field ‘phone_number’ has incomplete type
Aug 13 20:56:29 <holtmann> cc1: warnings being treated as errors
Aug 13 20:56:31 <holtmann> ../src/driver.h:95: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:33 <holtmann> ../src/driver.h:95: error: its scope is only this definition or declaration, which is probably not what you want
Aug 13 20:56:36 <holtmann> ../src/driver.h:100: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:39 <holtmann> ../src/driver.h:104: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:42 <holtmann> ../src/driver.h:109: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:43 <holtmann> ../src/driver.h:113: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:45 <holtmann> ../src/driver.h:116: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:47 <holtmann> ../src/driver.h:121: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:50 <holtmann> ../src/driver.h:124: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:52 <holtmann> ../src/driver.h:127: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:53 <holtmann> ../src/driver.h:130: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:57 <holtmann> ../src/driver.h:133: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:57 <denkenz> eh? did you make clean; make in include?
Aug 13 20:56:58 <holtmann> ../src/driver.h:136: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:56:59 <holtmann> ../src/driver.h:140: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:57:02 <denkenz> Sometimes it does this
Aug 13 20:57:02 <holtmann> ../src/driver.h:143: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:57:03 <holtmann> ../src/driver.h:150: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:57:07 <holtmann> ../src/driver.h:154: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:57:09 <holtmann> ../src/driver.h:157: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:57:12 <holtmann> ../src/driver.h:161: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:57:14 <holtmann> ../src/driver.h:163: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:57:15 <holtmann> ../src/driver.h:255: error: ‘struct ofono_error’ declared inside parameter list
Aug 13 20:57:17 <holtmann> In 
Aug 13 20:58:01 <denkenz> holtmann: I ran a distcheck, so make sure you're doing make clean; make in ofono/include
Aug 13 20:58:32 <denkenz> holtmann: You might wanna fix that automake magic, since adding new files is currently requiring a make clean
Aug 13 20:58:52 <holtmann> You added a new include. Then it is clear why this happens :)
Aug 13 20:59:20 <holtmann> Have to look at that.
Aug 13 21:03:56 <denkenz> Nod, btw, I'll be adding lots of new files
Aug 13 21:04:06 <denkenz> Essentially breaking out driver.h into proper includes
Aug 13 21:05:13 <denkenz> Please don't paste all the errors you'll get then ;)
Aug 13 21:14:25 <holtmann> Good to know.
Aug 13 21:35:54 <denkenz> holtmann: What do you think of something like __ofono_atom_add_watch(modem, type, func, user)?
Aug 13 21:53:14 <holtmann> What it is suppose to do?
Aug 13 21:54:53 <denkenz> so today parts of the system need to communicate
Aug 13 21:55:07 <denkenz> e.g. netreg using sim manager to read files
Aug 13 21:55:22 <denkenz> or settings registering with ussd manager to handle various magic strings
Aug 13 21:56:08 <denkenz> This can be used to watch for a particular atom being registered, and take action
Aug 13 21:56:39 <denkenz> e.g. SIM Manager atom registered -> queue up reading sim files a particular interface needs
Aug 13 21:57:40 <holtmann> Should be fine. Go with it.
Aug 13 21:58:53 <denkenz> Just checking, maybe there's already a pattern for it that I'm not aware of
**** ENDING LOGGING AT Fri Aug 14 02:59:57 2009

**** BEGIN LOGGING AT Fri Aug 14 02:59:57 2009
Aug 14 12:56:29 * akiniemi back from vacation, kinda ;)
Aug 14 12:59:58 <Robot101> akiniemi: good vacation? :)
Aug 14 13:04:55 <akiniemi> Robot101: weather was nice, work out of mind most of the time, so decent, I guess :)
Aug 14 13:31:57 <Mirv> I started my work with catching a cold. not swine flu, yet
Aug 14 14:07:28 <akiniemi> Just pushed a couple of ISI patches in
Aug 14 16:59:33 <denkenz> holtmann, akiniemi: I've pushed out the initial evolution of the driver framework.  Have a looksie and comment on it
Aug 14 17:00:05 <denkenz> akiniemi: I've had to do some minor surgery on isiphonebook, it compiles, but I can't verify that I didn't break something
Aug 14 17:01:10 <denkenz> Not everything is ported yet, so if you can hold off on pushing new drivers with unported APIs, that would be good
Aug 14 17:05:38 <denkenz> holtmann: Btw, what is the coding standard for ifs?  Is it a space before and after every if statement?
Aug 14 17:06:33 <holtmann> Example please.
Aug 14 17:08:16 <holtmann> isimodem/isiphonebook.c:375: error: variable ‘ops’ has initializer but incomplete type
Aug 14 17:08:16 <holtmann> isimodem/isiphonebook.c:376: error: unknown field ‘export_entries’ specified in initializer
Aug 14 17:08:16 <holtmann> cc1: warnings being treated as errors
Aug 14 17:08:16 <holtmann> isimodem/isiphonebook.c:377: error: excess elements in struct initializer
Aug 14 17:08:16 <holtmann> isimodem/isiphonebook.c:377: error: (near initialization for ‘ops’)
Aug 14 17:08:32 <denkenz> e.g. 
Aug 14 17:08:56 <holtmann> Meaning how complex do you need it for ifs.
Aug 14 17:09:00 <denkenz>         if (!client) {
Aug 14 17:09:02 <denkenz>                 client = g_isi_client_create(PN_SIM);
Aug 14 17:09:03 <denkenz>                 if (!client)
Aug 14 17:09:05 <denkenz>                         return -ENOMEM;
Aug 14 17:09:06 <denkenz>         }
Aug 14 17:09:32 <denkenz> Or
Aug 14 17:09:34 <denkenz>                 p += subblock_len;
Aug 14 17:09:35 <denkenz>         }
Aug 14 17:09:37 <denkenz>         if (status == SIM_SERV_OK) {
Aug 14 17:09:38 <denkenz>                 ofono_phonebook_entry(pb, -1, number, -1, name, -1, NULL,
Aug 14 17:09:40 <denkenz>                                         snr, -1, adn, email, NULL, NULL);
Aug 14 17:09:42 <denkenz>                 return location;
Aug 14 17:09:43 <denkenz>         } else {
Aug 14 17:09:44 <denkenz>                 return -1;
Aug 14 17:09:46 <denkenz>         }
Aug 14 17:09:47 <denkenz> holtmann: Btw, make clean in include
Aug 14 17:09:49 <denkenz> holtmann: New files added
Aug 14 17:10:24 <denkenz> and fetch :)
Aug 14 17:13:09 <holtmann> denkenz: I did.
Aug 14 17:13:51 <holtmann> So about the top one. That is fine as it is. Especially in that case where you create something on demand.
Aug 14 17:13:59 <holtmann> The second one is bloody complicated.
Aug 14 17:14:12 <holtmann> If (status != SIM_SERV_OK)
Aug 14 17:14:15 <holtmann>   return -1;
Aug 14 17:14:23 <holtmann> ofono_ph..
Aug 14 17:14:26 <holtmann> return location.
Aug 14 17:17:31 <denkenz> holtmann: fetch again, I forgot the isi phonebook commit
Aug 14 17:17:46 <holtmann> Compiles fine now.
Aug 14 17:20:13 <denkenz> holtmann: nod
Aug 14 17:20:25 <denkenz> holtmann: So I generally tend to do space before & after every if
Aug 14 17:20:40 <denkenz> holtmann: That is a kernel standard, no?
Aug 14 17:20:56 <denkenz> holtmann: Regardless, isiphonebook.c is full of these really bad style issues
Aug 14 17:21:06 <holtmann> Yes. That is how it is suppose to be. However both examples do that.
Aug 14 17:21:38 <holtmann> single statements should not have { }, but there are a few exception if you work with macros.
Aug 14 17:22:09 <denkenz> Ok, so in the first example, the inner if doesn't have a space on the front
Aug 14 17:22:27 <holtmann> And in the case above if both call return, then the code flow is untterly complex.
Aug 14 17:22:44 <denkenz> The second example, the if doesn't have a space on the front either
Aug 14 17:22:45 <holtmann> In my case it does. Sorry, I might not see it.
Aug 14 17:23:16 <holtmann> Give me the lines inside the code and I look at the code.
Aug 14 17:23:34 <denkenz> #1: isiphonebook.c:393
Aug 14 17:23:53 <denkenz> #2: isiphonebook.c:242
Aug 14 17:24:44 <holtmann> These two are correct. Show me an example on how you expect it.
Aug 14 17:26:13 <denkenz> Ok, so at least for #2 it goes something like:
Aug 14 17:26:18 <denkenz> for () {
Aug 14 17:26:19 <denkenz> }
Aug 14 17:26:22 <denkenz> if () {
Aug 14 17:26:24 <denkenz> }
Aug 14 17:26:27 <denkenz> it should be:
Aug 14 17:26:30 <denkenz> for () {
Aug 14 17:26:31 <denkenz> }
Aug 14 17:26:33 <denkenz> newline
Aug 14 17:26:35 <denkenz> if () {
Aug 14 17:26:37 <denkenz> }
Aug 14 17:26:53 <holtmann> You are talking about the newline after it. Got it.
Aug 14 17:27:14 <holtmann> In theory there should be an empty line after an if, for, etc. statement.
Aug 14 17:27:34 <denkenz> also, I tend to do:
Aug 14 17:27:34 <holtmann> Not that it gets really 100% enforced all the time.
Aug 14 17:27:37 <denkenz> statement
Aug 14 17:27:39 <denkenz> statement
Aug 14 17:27:40 <denkenz> newline
Aug 14 17:27:42 <denkenz> if ()
Aug 14 17:27:46 <denkenz> tabstatement
Aug 14 17:27:48 <denkenz> newline
Aug 14 17:27:51 <denkenz> statement
Aug 14 17:27:54 <denkenz> statement
Aug 14 17:28:04 <holtmann> Yes. That is how it should be.
Aug 14 17:28:17 <holtmann> Not always strictly enforced.
Aug 14 17:29:00 <denkenz> Well one thing is not to enforce it strictly, another is to not enforce it :)
Aug 14 17:29:30 <holtmann> I normally tend to enforce it for the code I review, but every now and then it slips through.
Aug 14 17:35:09 <denkenz> holtmann: Nod, I'm just being nit-picky, learned from the master ;)
Aug 14 17:35:26 <denkenz> holtmann: Rest of isi looks OK, except for many instances of #1
Aug 14 17:40:22 <holtmann> I dislike the return in if and else clause. That could be done simple. As mentioned above.
Aug 14 17:42:51 <denkenz> holtmann: Agreed on that one, might wanna fix it
Aug 14 20:21:44 <akiniemi> denkenz: gotcha
**** ENDING LOGGING AT Sat Aug 15 02:59:59 2009

**** BEGIN LOGGING AT Sat Aug 15 02:59:59 2009
Aug 15 20:24:23 <gabriel> hi, i try to install ofono, but i think the "make install" is bugged, headers are copied well but not library (i have not libgdbus.la in /usr/lib) is it normal ?
Aug 15 20:56:36 <courmisch> gdbus is an internal library
Aug 15 20:56:54 <courmisch> only ofonod is supposed to be installed
Aug 15 21:04:10 <gabriel> but when i try to build a hello world application, i got : hello.c:(.text+0x10): undefined reference to `ofono_dbus_get_connection'
Aug 15 21:04:40 <gabriel> what am i suppose to link ?
Aug 15 21:17:39 <holtmann> gabriel: Use plain D-Bus bindings and not some internal oFono API. That is for the plugins only.
Aug 15 21:18:28 <gabriel> i have installed dbus-1 (we can't configure without this lib)
Aug 15 21:18:56 <gabriel> the problem is with a ofono function definition
Aug 15 21:19:04 <gabriel> (not exported in a static lib)
Aug 15 21:19:12 <gabriel> (or lib not installed :))
Aug 15 21:29:12 * dilinger uploads 0.3 to debian
Aug 15 21:29:34 <dilinger> it's probably not going to make it into any kind of released distro until those arm build errors are fixed, though (assuming they haven't already been fixed?)
Aug 15 21:30:55 <gabriel> euh i just build ofono on a debian arm, it works
Aug 15 21:38:24 <gabriel> any version .deb of ofono 0.3 ?
Aug 15 21:42:17 <holtmann> gabriel: You are not supposed to use any of the ofono_ function definitions from applications. They are meant to be used from plugins.
Aug 15 21:42:27 <holtmann> Just call the D-Bus API from your application.
Aug 15 21:44:23 <gabriel> im stupid ... why i tried that ... :P, sorry
Aug 15 22:44:44 <gabriel> "Failed to open connection to bus: /usr/bin/dbus-launch terminated abnormally without any error message" => any idea ?
**** ENDING LOGGING AT Sun Aug 16 02:59:57 2009

**** BEGIN LOGGING AT Sun Aug 16 02:59:57 2009
Aug 16 10:07:42 <gabriel> there is some example of code using ofono ?
Aug 16 14:27:24 <gabriel> "dbus-send --system --dest=org.ofono / org.ofono.NetworkRegistration.Status" => return nothing, is it normal ?
Aug 16 14:45:54 <inz> yes; you should do that call to a modem object, not to the root
Aug 16 14:46:16 <inz> or actually it should probably return no such method
Aug 16 14:49:43 <gabriel> can we list all modem ? or all method available ?
Aug 16 14:55:42 <inz> gabriel, dunno of that, but if you have not requested one, there wont be any
Aug 16 16:34:12 <dilinger> gabriel: GetProperties of some of the root objects will list all modems
Aug 16 19:55:59 <gabriel> i don't understand some thing : dbus-send --system --dest=org.ofono /modem0 org.ofono.NetworkRegistration.Status  => it should return me the Status no ? why i have nothing ?
Aug 16 19:57:51 <gabriel> dbus-send --system --dest=org.ofono / org.ofono.Manager.Modems => return me nothing too hmmmm strange
Aug 16 20:02:12 <gabriel> ok .... i forget --print-reply :)
**** ENDING LOGGING AT Mon Aug 17 02:59:56 2009

**** BEGIN LOGGING AT Mon Aug 17 02:59:56 2009
Aug 17 08:51:29 <Strid> +Does anyone know if the HTC Hero has same hardware as the G1?
Aug 17 08:52:26 <XorA> Strid: there is #htc-linux
Aug 17 08:52:46 <Strid> thanks!
Aug 17 08:56:11 <inz> Strid, also there's wikipedia =)
Aug 17 08:57:11 <Strid> what I ment was it would be possible to run the ofono on a Hero as well as the G1.
Aug 17 08:58:41 <inz> Strid, oops, sry, I though I was on another channel =)
Aug 17 08:59:25 <Strid> :)
Aug 17 17:52:52 <dilinger> denkenz: is the new driver api committed, or is that still being worked on?
Aug 17 17:53:09 <denkenz> dilinger: 30% done or so
Aug 17 17:53:19 <dilinger> okay
Aug 17 17:53:37 * dilinger won't bother looking yet, then
Aug 17 17:54:14 <denkenz> The change won't be drastic anyway, just make it easier to pick & choose components
Aug 17 17:54:30 * dilinger nods
Aug 17 17:54:33 <denkenz> If you wanna make a proper SMS driver for G1, the code will be 90% same
Aug 17 17:56:23 <dilinger> is the new api a requirement for 0.4/
Aug 17 17:56:23 <dilinger> ?
Aug 17 17:56:57 <denkenz> depends on how far I get this week, most likely it'll be in 0.4
Aug 17 17:57:03 <dilinger> cool
Aug 17 17:58:12 <dilinger> i've got other stuff to work on, but i'll be trying to get the g1 stuff in for 0.4
Aug 17 17:58:31 <denkenz> cool :)
Aug 17 17:59:37 <dilinger> and just in case you folks care about bsd - https://buildd.debian.org/pkg.cgi?pkg=ofono
Aug 17 17:59:46 <dilinger> i don't actually care :)
Aug 17 18:06:46 <denkenz> Theoretically oFono can work on BSD, but we need to disable all linuxisms at configure time
Aug 17 18:06:51 <denkenz> holtmann can comment more
Aug 17 18:14:40 <holtmann> I don't care about BSD at all, but if the changes are not to intrusive, then yes.
Aug 17 18:14:56 <holtmann> However at some point we will be using udev for device detection and then it becomes tricky.
Aug 17 18:15:16 <denkenz> holtmann: Yah, that is the issue, netlink/udev
Aug 17 19:43:41 <courmisch> well, I assume it will also screw up when we add PPP over AT commands ...
Aug 17 19:49:12 <denkenz> ?
**** ENDING LOGGING AT Tue Aug 18 02:59:56 2009

**** BEGIN LOGGING AT Tue Aug 18 02:59:56 2009
Aug 18 13:26:06 <Strid_> does the latest release code support HTC G1?
Aug 18 14:34:24 <dilinger> Strid: no
Aug 18 14:34:47 <dilinger> Strid: for that, you'd need to use my git repo.  hopefully the next release will support the G1
Aug 18 15:02:49 <denkenz> Btw, have you been having the sorts of issues Marko has been posting?
Aug 18 15:03:47 <denkenz> E.g. can't abort dialing call or reject behaving weird?
Aug 18 15:04:03 <denkenz> Or is the G1 more sane?
Aug 18 15:04:36 <dilinger> i haven't seen those issues
Aug 18 15:05:26 <dilinger> oh, that's for outgoing
Aug 18 15:05:42 <dilinger> well, i haven't seen it with incoming calls; i haven't tried canceling outgoing calls
Aug 18 15:08:38 * dilinger tries
Aug 18 15:14:15 <dilinger> denkenz: works fine on the g1
Aug 18 15:18:56 <inz> dilinger, what changes are needed for the G1?
Aug 18 15:20:31 <dilinger> inz: http://git.collabora.co.uk/?p=user/dilinger/ofono-g1;a=summary
Aug 18 15:20:49 <dilinger> those 4 commits near the top
Aug 18 15:21:04 <inz> dilinger, ok, thanks
Aug 18 16:14:19 <Strid> thanks!
Aug 18 17:22:20 <denkenz> dilinger: Good to know
**** ENDING LOGGING AT Wed Aug 19 02:59:56 2009

**** BEGIN LOGGING AT Wed Aug 19 02:59:56 2009
Aug 19 03:01:14 <denkenz> holtmann: Have you given thought whether we will aim to support various GPRS-only devices in oFono?
Aug 19 03:01:23 <denkenz> holtmann: Or is that realm of connman?
Aug 19 04:11:41 <holtmann> No. oFono should do that part. ConnMan is just responsible for setting IP address, routing and resolver.
Aug 19 04:37:54 <denkenz> holtmann: nod
Aug 19 18:22:15 <dilinger> hrm.  i see that org.ofono.SimManager.GetProperties returns an array of strings for SubscriberNumbers.  i'm assuming that means a sim could potentially have multiple phone numbers; how often does that happen in practice?
Aug 19 18:26:21 <denkenz> never :)
Aug 19 18:26:33 <denkenz> Well actually it can even on basic feature phones
Aug 19 18:26:44 <denkenz> Usually because they have the option to set it in the SIM
Aug 19 18:26:57 <denkenz> But this means you have a different number for Voice, Fax, Data
Aug 19 18:27:19 <denkenz> which rarely happens
Aug 19 18:34:24 <dilinger> ah, thanks
Aug 19 23:38:12 <denkenz> Grr
Aug 19 23:38:24 <denkenz> pep.c: In function ?g_isi_pep_create?:
Aug 19 23:38:25 <denkenz> pep.c:80: error: ?SOCK_NONBLOCK? undeclared (first use in this function)
Aug 19 23:38:27 <denkenz> pep.c:80: error: (Each undeclared identifier is reported only once
Aug 19 23:38:28 <denkenz> pep.c:80: error: for each function it appears in.)
Aug 19 23:38:30 <denkenz> pep.c:80: error: ?SOCK_CLOEXEC? undeclared (first use in this function)
Aug 19 23:38:33 <denkenz> holtmann: Any idea wtf those defines are located?
**** ENDING LOGGING AT Thu Aug 20 02:59:56 2009

**** BEGIN LOGGING AT Thu Aug 20 02:59:57 2009
Aug 20 03:23:47 <holtmann> denkenz: Might be an old Glibc.
Aug 20 03:25:07 <denkenz> holtmann: its both, but I wouldn't consider 2.8 'old'
Aug 20 03:25:42 <holtmann> These are really brand new defines.
Aug 20 03:26:36 <denkenz> Nod, so I know Nokia is never going to use anything besides fairly bleeding edge
Aug 20 03:26:58 <denkenz> But that doesn't mean we should not compile on systems with slighly older glibc
Aug 20 03:27:41 <holtmann> We just need to add ifndef clauses around them.
Aug 20 03:28:21 <holtmann> Fedora 11 is fine btw.
Aug 20 03:28:22 <denkenz> Not really that simple, since NONBLOCK must still be set
Aug 20 03:28:28 <holtmann> And I am off again.
Aug 20 08:39:46 <akiniemi> False alarm, nwasn't anything that autoreconf cann't fix :)
Aug 20 08:41:51 <akiniemi> Ok, now all of you running a bit dated kernel, just say ./configure --disable-isi
Aug 20 16:55:07 <denkenz> akiniemi: ping
Aug 20 17:04:16 <dilinger> hrm
Aug 20 17:04:19 <dilinger> localhost:~# apt-get clean
Aug 20 17:04:20 <dilinger> Bus error
Aug 20 17:04:44 <dilinger> maybe i should've stayed at lenny
Aug 20 17:05:01 <denkenz> heh
Aug 20 17:39:59 <dilinger> ah, it's libstdc++.  god, i hate that language.
Aug 20 18:05:24 <denkenz> akiniemi: I've pushed out another set of driver changes and had to mess with the isi modem stuff.  It compiles, but can't vouch that I haven't broken something
Aug 20 22:27:59 <denkenz> balrog-kun: here?
Aug 20 23:24:00 <balrog-kun> denkenz: got your mail, thanks
Aug 20 23:24:28 <balrog-kun> denkenz: i'd rather not delete the read messages without sending them to d-bus clients :)
Aug 20 23:24:43 <balrog-kun> although i think some windows mobiles do this
Aug 20 23:25:05 <denkenz> balrog-kun: I'm confused
Aug 20 23:25:09 <denkenz> how will that happen?
Aug 20 23:26:09 <balrog-kun> if on startup we find read messages on the sim, you suggested to remove them in case our +CMGD failed
Aug 20 23:27:20 <denkenz> yep
Aug 20 23:27:51 <denkenz> but if CMGR succeeded, then it was already sent out
Aug 20 23:28:20 <balrog-kun> yeah
Aug 20 23:28:24 <balrog-kun> it might be we were shut down between +CMGR and +CMGD but more likely +CMGD fails because SIM was worn out or something
Aug 20 23:28:31 <balrog-kun> and would fail again
Aug 20 23:29:10 <denkenz> In which case we shouldn't signal that SMS again
Aug 20 23:29:17 <balrog-kun> and people might keep useful information on their SIMs so I'd leave it there or read and signal over D-Bus, then delete
Aug 20 23:30:04 <denkenz> Yeah, I really don't want to go down that path
Aug 20 23:30:20 <denkenz> If we don't CMGD the SIM, we have to start dealing with SIM full conditions
Aug 20 23:30:26 <denkenz> And that is a pain
Aug 20 23:32:31 <denkenz> And we have to do something, since over a device's lifetime we might get to the point where power failures filled up the SIM
Aug 20 23:32:45 <denkenz> Which means no SMS :)
Aug 20 23:33:01 <balrog-kun> right
Aug 20 23:33:19 <balrog-kun> then let's read all messages and deliver them to clients.. if we were shut down between +CMGR and +CMGD then most likely the SMS was lost and not delivered the first time
Aug 20 23:34:21 <balrog-kun> either way a duplicate is rather harmless
Aug 20 23:34:38 <denkenz> So the question is, what if a SIM is taken out of an old mobile and put into oFono enabled one
Aug 20 23:34:47 <denkenz> Do we signal N smses from x years ago?
Aug 20 23:35:20 <balrog-kun> that's much better than just scrapping them I think
Aug 20 23:35:32 <balrog-kun> the user can use whatever UI is runing to save them
Aug 20 23:35:37 <balrog-kun> running*
Aug 20 23:36:15 <denkenz> Ok, so lets try that approach first
Aug 20 23:36:38 <denkenz> If it doesn't work, we can always change the policy, we know the read/unread status in the callback anyway
Aug 20 23:37:02 <balrog-kun> yup
Aug 20 23:37:05 <denkenz> Still, that might be a bad idea for SIMs with like 30+ smses ;)
Aug 20 23:37:43 <balrog-kun> well
Aug 20 23:37:55 <balrog-kun> having 30+ smses from x years ago i wouldn't want to lose them
Aug 20 23:38:02 <balrog-kun> perhaps
Aug 20 23:38:15 <denkenz> Yeah but then we should treat them that way
Aug 20 23:38:52 <denkenz> Perhaps if a new SIM is inserted which we've never seen before we deliver them as 'archives'
Aug 20 23:39:48 <denkenz> But again, none of this should really be a big deal in the real world
Aug 20 23:40:00 <denkenz> Since most real modems support +CMT notifications
Aug 20 23:40:32 <balrog-kun> true
Aug 20 23:41:03 <balrog-kun> still many (non "smart-") phones use the sim store
Aug 20 23:41:53 <denkenz> Yes, and perhaps we should avoid CMGR CMGDing anything unless we absolutely must
Aug 20 23:42:05 <denkenz> e.g. modem is not +CMT capable
Aug 20 23:42:05 <balrog-kun> ah, so we should check if the modme supports +CMT and if i does then could ignore the SIM store altogether
Aug 20 23:42:12 <balrog-kun> on startup
Aug 20 23:42:27 <denkenz> exactly, though class 2 SMSes might still bite us
Aug 20 23:44:04 <denkenz> btw, no matter what we do we won't get it right
Aug 20 23:44:26 <denkenz> since for instance +CMT arrives & we don't acknowledge, it comes back as a +CMTI
Aug 20 23:45:48 <balrog-kun> how would this happen? the modem would have to remember we had received the message already, because the network can't decide on whether the modem should use +CMT or +CMTI
Aug 20 23:46:19 <denkenz> No, the spec actually stipulates that the modem default back to the SIM/ME store if a +CMT is not acknowledged
Aug 20 23:46:34 <denkenz> within a certain period, which is manufacturer dependent
Aug 20 23:47:51 <balrog-kun> that could only be a problem if ofonod is shut down but the modem isn't, though
Aug 20 23:48:04 <denkenz> so e.g. a modem barfs some random garbage which makes us miss the +CMT
Aug 20 23:48:12 <balrog-kun> normally the only time we don't ack a message is if ofono is being shut down
Aug 20 23:48:32 <denkenz> You're not being paranoid enough :)
Aug 20 23:48:40 <denkenz> But yes, none of this is an issue during normal operation
Aug 20 23:49:48 <balrog-kun> btw. for class 2 SMSes we could read those which have "READ" status and see if they're class 2, although this sounds complex
Aug 20 23:50:20 <denkenz> Well, it isn't really
Aug 20 23:50:40 <denkenz> you can simply access the same smsutil functions
Aug 20 23:52:39 <balrog-kun> no, i mean going through all messages on every startup and deciding whether they're class 2, and if not, leaving them in place, if the modem supports +CMT, in drivers/atmodem/sms.c, sounds complex
Aug 20 23:52:45 <balrog-kun> it could add an overhead, too
Aug 20 23:53:25 <denkenz> It would be, and also power is a consideration
Aug 20 23:54:51 <denkenz> which is why I'm still sort of in favor of just shooting everything at startup
Aug 20 23:55:20 <denkenz> always assume we have a clean SIM
Aug 20 23:55:37 <denkenz> If we don't, then re-submit the pdus
Aug 20 23:56:49 <balrog-kun> yeah, if we re-submit them then it's fine
Aug 20 23:57:00 <balrog-kun> i.e. we don't consciously throw them away
Aug 20 23:57:37 <denkenz> nod, for now worst case we deliver x year old smses :)
Aug 20 23:58:37 <balrog-kun> we ony need to make sure the default SMS arrived ringtone is not one of the annoying ones
Aug 20 23:59:07 <denkenz> hehe
Aug 20 23:59:20 <denkenz> Which is re-started rapidly :P
Aug 20 23:59:36 <denkenz> And mixed in by virtue of PulseAudio :)
Aug 21 00:00:44 <balrog-kun> ewww
**** ENDING LOGGING AT Fri Aug 21 02:59:56 2009

**** BEGIN LOGGING AT Fri Aug 21 02:59:56 2009
Aug 21 14:03:52 <akiniemi> denkenz: got it. I like this new driver API, btw. :)
Aug 21 14:13:56 <denkenz> akiniemi: Nod, there's one more change coming which you'll like too
Aug 21 14:14:14 <denkenz> akiniemi: Modem will have 'Powered' property and a proper driver as well
Aug 21 15:14:16 <akiniemi> denkenz: cool!
Aug 21 16:08:22 <denkenz> holtmann: Btw, akiniemi brought it up and I meant to ask you a while ago, how do we plan on handling NITZ notifications?
Aug 21 16:11:19 <holtmann> That is the network time update, right?
Aug 21 16:11:25 <denkenz> yeah
Aug 21 16:12:31 <holtmann> We have the same problem with time details from GPS. I think we have to come up with something flexible. Since for the desktop, you wanna give the user a choice. For the embedded ones, you wanna do it automatically.
Aug 21 16:13:37 <denkenz> Nod, Aki had an idea that there should be a daemon that handles all of this
Aug 21 16:14:01 <denkenz> And oFono, GPS, etc integrate with that daemon, then UI integrates with it
Aug 21 16:14:15 <denkenz> Dunno if yet another daemon is in order though
Aug 21 16:14:25 <denkenz> Does HAL have any support for time?
Aug 21 16:16:20 <holtmann> HAL is dead.
Aug 21 16:18:26 <denkenz> Hmm nod
Aug 21 16:18:33 <denkenz> How about we put this into a plugin? ;)
Aug 21 16:21:19 <Robot101> colour me an idiot, but could you just write a plugin for ntpd which used ofono as a time source?
Aug 21 16:22:03 <denkenz> embedded devices won't have ntpd I'm pretty sure
Aug 21 16:22:42 <Robot101> embedded devices also not keen on ya daemon... :D
Aug 21 16:23:10 <denkenz> my daemon? Aki's daemon ;)
Aug 21 16:24:37 <denkenz> we need something configurable, not sure if a full blown plugin for NITZ is the way though
Aug 21 16:26:01 <denkenz> or simply signal NITZ over NetworkRegistration to anyone who cares
Aug 21 16:29:34 <holtmann> We have the same problem with ConnMan. We need to update the time. Another detail to discuss. I am not a big fan of another daemon approach.
Aug 21 16:31:55 <denkenz> Ok, I ignore this for now
Aug 21 16:32:16 <holtmann> However I think that ntpd is the right approach and just make everything else a time source. Maybe we just need ntpd-light or so.
Aug 21 16:34:32 <dilinger> there is openntpd.  certainly lighter than ISC ntpd, but i can't vouch for its stability or usefulness.
Aug 21 16:36:14 <courmisch> works for me
Aug 21 16:39:34 <Robot101> denkenz: y a = yet another
Aug 21 16:40:00 <denkenz> Robot101: Ah ok, mis-interpreted ;)
Aug 21 16:40:34 <denkenz> Anyway, at the end of the day its as simple as filling out a struct tm and handing it off to someone
Aug 21 16:40:43 <denkenz> Whether its dbus signal or a plugin
Aug 21 16:40:50 <denkenz> So from my perspective I simply don't care
Aug 21 16:58:05 <balrog-kun> denkenz: is it intentional sms.c never calls ofono_sms_status_notify? (i know it doesn't do anything)
Aug 21 16:58:22 <denkenz> balrog-kun: yeah, we don't support status reports
Aug 21 16:58:34 <balrog-kun> ok
Aug 21 16:59:27 <denkenz> eventually we might, but until then its safe to leave it out
Aug 21 18:10:34 <dilinger> hm.  okay, i'm clearly doing something wrong here..
Aug 21 18:11:09 <dilinger>     val = g_hash_table_lookup (hash, "SubscriberNumbers");
Aug 21 18:11:23 <dilinger> that returns a gvalue that's of type GStrv
Aug 21 18:11:27 <dilinger>     numbers = g_value_get_boxed (val);
Aug 21 18:11:41 <dilinger> (oh, this is org.ofono.SimManager.GetProperties)
Aug 21 18:12:14 <dilinger> numbers is a char** that's supposed to point to a list, but the first entry is ""
Aug 21 18:14:31 <dilinger> by the time /modem1 is set up, should SubscriberNumbers be set up already?
Aug 21 18:14:44 <denkenz> No, it is read from the SIM
Aug 21 18:14:47 <dilinger> or do i have the types wrong?
Aug 21 18:16:01 <denkenz> Basically if there's nothing there, an empty array is returned
Aug 21 18:16:13 <dilinger> oh, i bet i should be listening for org.ofono.SimManager PropertyChanged, for string "SubscriberNumbers"
Aug 21 18:16:54 <denkenz> yes, that too
Aug 21 18:17:11 <dilinger> ok, that makes sense.  thanks
Aug 21 18:17:48 <denkenz> Note that if the entry is unset on the SIM you'll just get an empty string
Aug 21 18:17:53 <dilinger> *nod*
Aug 21 18:18:14 <dilinger> that's fine, but i was confused because i know for a fact that it's set, and yet i wasn't seeing anything
Aug 21 22:05:07 <dilinger> denkenz: i think i may be seeing some kind of race or something :/
Aug 21 22:05:52 <dilinger> denkenz: dbus-monitor shows the PropertyChanged signal firing, but the callback i registered w/ it (which was registered directly after at.Manager.Create) only seems to fire sometimes
Aug 21 22:05:53 <denkenz> dilinger: where and what?
Aug 21 22:06:31 <denkenz> That one is about to go away btw
Aug 21 22:06:42 <dilinger> and after i register the signal callbacks, i also do a GetProperties to ensure that there's no SubscriberNumbers yet (there's not)
Aug 21 22:06:58 <dilinger> what's about to go away?
Aug 21 22:07:03 <denkenz> at.Manager
Aug 21 22:07:14 <dilinger> oh. what'll it be replaced with?
Aug 21 22:07:24 <denkenz> Real device drivers
Aug 21 22:07:39 <dilinger> ok, but it'll still be basically the same interface?
Aug 21 22:07:49 <dilinger> just g1.Manager.Create or somesuch?
Aug 21 22:07:50 <denkenz> no, at.Manager is gone
Aug 21 22:08:03 <denkenz> The device driver can register devices with ofono
Aug 21 22:08:23 <denkenz> so e.g. there would be plugins/g1.c
Aug 21 22:08:51 <dilinger> with the new interface, will i be able to do something like
Aug 21 22:09:05 <dilinger> 1) register PropertyChanged signal w/ SimManager
Aug 21 22:09:26 <dilinger> sorry, register a callback *for* PropertyChanged signal w/ SimManager
Aug 21 22:09:36 <denkenz> The DBus api hasn't changed
Aug 21 22:09:40 <dilinger> 2) pass /dev/smd0 to g1.c (or whatever)
Aug 21 22:09:54 <denkenz> Just the at.Manager API has been removed
Aug 21 22:10:10 <dilinger> 3) have that create /modem1, with the signal already being listened for
Aug 21 22:10:22 <denkenz> No, it'll be different
Aug 21 22:10:42 <denkenz> E.g. your g1.c would do:
Aug 21 22:10:53 <denkenz> ofono_modem_create("g1", g1_driver)
Aug 21 22:11:13 <denkenz> ofono_modem_set_data(g1, foo)
Aug 21 22:11:17 <denkenz> ofono_modem_register(g1)
Aug 21 22:11:35 <denkenz> at which point org.ofono.Manager will fire a signal PropertyChanged with Modems ["g1"]
Aug 21 22:12:10 <denkenz> After that you must watch Interfaces property on the modem you're interested in
Aug 21 22:12:19 <denkenz> Once it becomes available you can use e.g. SimManager as usual
Aug 21 22:12:21 <dilinger> how is the modem device specified?
Aug 21 22:12:37 <denkenz> up to the plugin
Aug 21 22:12:58 <dilinger> hm.
Aug 21 22:13:05 <denkenz> It'll make sense when you see it
Aug 21 22:13:30 <denkenz> Basically instead of at.Manager creating the device, the device driver will
Aug 21 22:15:02 <denkenz> For your SubscriberNumbers situation
Aug 21 22:15:07 <denkenz> The typical flow should be:
Aug 21 22:15:22 <denkenz> PropertyChanged("Interfaces", [..., "SimManager", ...]
Aug 21 22:15:36 <denkenz> listen_for_signal("SimManager", PropertyChanged)
Aug 21 22:15:42 <denkenz> GetProperties("SimManager")
Aug 21 22:16:26 <denkenz> PropertyChanged("SubscriberNumbers", ["foo", "foo2"])
Aug 21 22:17:14 <denkenz> there are currently no guarantees within ofono that a signal will arrive after the method returns
Aug 21 22:17:24 <denkenz> and signal registration is async in DBus anyway
Aug 21 22:17:55 * dilinger nods
Aug 21 22:18:21 <dilinger> so i guess it depends on how i forsee the g1 driver being used
Aug 21 22:18:44 <dilinger> there are currently 2 ways to use it; over bluetooth (dev:/dev/rfcomm0) or directly on the device (dev:/dev/smd0)
Aug 21 22:19:08 <dilinger> the former is the easist, quickest method to set up; the latter allows access to SMS commands
Aug 21 22:19:27 <denkenz> There's no reason you can't support both actually
Aug 21 22:19:57 <dilinger> would i be telling ofono to load g1?
Aug 21 22:20:10 <dilinger> or would it automatically be loaded when ofonod starts?
Aug 21 22:20:19 <denkenz> Shrug, plugins/g1_over_rfcomm.c plugins/g1_over_smd.c
Aug 21 22:20:29 <denkenz> Completely up to the plugin :)
Aug 21 22:20:42 <dilinger> heh
Aug 21 22:20:48 <dilinger> okay, when's this stuff landing?
Aug 21 22:21:08 <denkenz> maybe tonight if I get enough testing in
Aug 21 22:21:11 <denkenz> Otherwise sometime next week
Aug 21 22:21:14 <dilinger> cool
Aug 21 23:30:38 <denkenz> Anyone know if there's a way to use an equal character inside a g_key_file string?
Aug 21 23:43:57 <denkenz> Nevermind, being an idiot
Aug 22 00:30:27 <denkenz> Anyway, new driver framework is in, have a poke
Aug 22 00:30:35 <denkenz> Still needs some cleanup
Aug 22 00:42:42 <dilinger> hm
Aug 22 00:42:43 <dilinger> -       snprintf(path, sizeof(path), "/modem%d", modem->id);
Aug 22 00:42:43 <dilinger> +       snprintf(path, sizeof(path), "/%s", node);
Aug 22 00:43:02 <dilinger> so it'll be called, ie, /at1 rather than /modem1?
Aug 22 00:43:13 <denkenz> anything the plugin wishes
Aug 22 00:43:41 <denkenz> node is limited to 16 chars though
Aug 22 00:46:18 <dilinger> ooh, a conf file!
Aug 22 00:47:46 <dilinger> any chance of making that global?
Aug 22 00:49:19 <denkenz> We see how it goes
Aug 22 00:49:25 <denkenz> This stuff is still preliminary :)
Aug 22 00:49:42 <denkenz> generic_at is a toy mainly anyway
Aug 22 00:49:48 <dilinger> from a support perspective, it would make life easier (documentation could just mention editing a driver-specific section of /etc/ofono.conf, for example..0
Aug 22 00:49:57 <denkenz> Since all the modems in the world have some form of non-compliance
Aug 22 00:50:02 * dilinger nods
Aug 22 00:50:26 <denkenz> Again, play with it, I will take all suggestions ;)
Aug 22 00:50:55 <denkenz> Real drivers should use netlink / udev / etc
Aug 22 00:55:36 <denkenz> balrog-kun: I will try to get to your patches next week, if they need a rebase, can you do that when you've some time?
Aug 22 01:03:58 <balrog-kun> denkenz: okay, should i also try and convert sim.c to use the new api?
Aug 22 01:05:14 <denkenz> sim.c is already converted
Aug 22 01:05:20 <balrog-kun> denkenz: if you apply the patch to read old messages from modem on startup, you may see gatchat get stuck on startup, with the simulator
Aug 22 01:05:35 <balrog-kun> it seems it's emitting an unecessary newline when responding to AT+CMGL
Aug 22 01:05:44 <balrog-kun> but i'm not yet sure it's simlator's fault
Aug 22 01:06:07 <denkenz> It could be
Aug 22 01:06:22 <denkenz> since at that time we weren't using CMGL I might not have made sure it worked
Aug 22 01:06:45 <balrog-kun> changing \\nOK to OK in the handling of CMGL makes it work
Aug 22 01:08:10 <balrog-kun> (..ah yes, i meant sms.c, not sim.c)
Aug 22 01:08:31 <balrog-kun> but it's also converted it seems
Aug 22 01:08:39 <denkenz> yep :)
Aug 22 01:08:45 <denkenz> everything should be converted
Aug 22 01:09:01 <denkenz> Btw, CMGL is freaking nasty because it is both a listing and a PDU
Aug 22 01:09:16 <denkenz> So you have to check the parser is actually handling it properly
Aug 22 01:11:25 <balrog-kun> maybe I should change it to be treated as a notification similarly to +CMGR
Aug 22 01:12:36 <denkenz> won't help, because notification implies a <cr><lf> terminator
Aug 22 01:12:40 <balrog-kun> denkenz: btw. is there a reason we drivers/atmodem/sms.c requires one of the three memories to be available even if the modem supports +CMT?
Aug 22 01:12:55 <denkenz> Yeah, for Class 2 SMS
Aug 22 01:13:30 <balrog-kun> there's a nokia phone that can emulate AT when you connect it with USB to PC and it has no memory but can send and receive messages
Aug 22 01:14:10 <denkenz> Special driver :)
Aug 22 01:14:45 <denkenz> You can take so many shortcuts once you know your hardware
Aug 22 01:14:57 <balrog-kun> right
Aug 22 01:15:30 <denkenz> For CMGL it sounds like you need to extend send_listing in gatchat
Aug 22 01:15:48 <denkenz> so it also takes a gboolean for whether it is a PDU or not
Aug 22 01:15:59 <denkenz> Then set the right parser hint :(
Aug 22 01:17:33 <denkenz> standard is so braindead, sigh
Aug 22 01:22:31 <balrog-kun> i was thinking that the daemon should have a parser that would treat any number of whitespace (space, <cr> or <lf>) equally and it wouldn't really create more ambiguity
Aug 22 01:23:28 <balrog-kun> and the parser would be used by default for any modems that haven't been validated to work with the correct AT parser
Aug 22 01:24:05 <balrog-kun> because there are probably less modems that are not 100% compliant than not
Aug 22 01:24:13 <balrog-kun> s/not//
Aug 22 01:26:22 <denkenz> yes I'm already considering a more permissive parser
Aug 22 01:26:32 <denkenz> But it still won't help on certain devices
Aug 22 01:45:48 <denkenz> Btw, CMGL is pretty 'special' in text mode too
Aug 22 01:46:02 <denkenz> So a specific listing command for it might not be a bad idea in general
**** ENDING LOGGING AT Sat Aug 22 02:59:57 2009

**** BEGIN LOGGING AT Sat Aug 22 02:59:57 2009
**** ENDING LOGGING AT Sun Aug 23 02:59:56 2009

**** BEGIN LOGGING AT Sun Aug 23 02:59:56 2009
**** ENDING LOGGING AT Mon Aug 24 02:59:57 2009

**** BEGIN LOGGING AT Mon Aug 24 02:59:57 2009
Aug 24 06:58:47 <Sage> Latest git does not compile because of this: http://pastebin.com/m459f6975
Aug 24 07:50:11 <dilinger> glad the compiler flags that; that class of bug is used for format string exploits
Aug 24 10:40:18 <akiniemi> Sage: just pushed a patch to fix that build issue
Aug 24 10:40:44 <akiniemi> Weren't plugins supposed to use DBG() and not ofono_debug()?
Aug 24 10:43:14 <holtmann> Yes.
Aug 24 10:44:00 <holtmann> However this gets triggered by __attribute__((format(printf, 1, 2))
Aug 24 10:45:05 <holtmann> akiniemi: Btw. I am going to change the whole build system to be non-recursive. Just waiting for Denis to confirm that he has no pending patches that would interfere.
Aug 24 10:46:05 <holtmann> if COND_ISI
Aug 24 10:46:06 <holtmann> MAYBE_ISI = gisi
Aug 24 10:46:06 <holtmann> endif
Aug 24 10:46:23 <holtmann> Especially these nasty hacks the go away. I hate this crap :(
Aug 24 11:12:31 <akiniemi> holtmann: that was the cleanest I could come up with ;)
Aug 24 11:13:19 <akiniemi> holtmann: any ETA on that new build system?
Aug 24 11:13:23 <holtmann> Don't worry. I fix them all and have proper linking and dependencies.
Aug 24 11:13:45 <holtmann> I have it done for BlueZ, obexd and ConnMan. oFono is next once I know that Denis has no pending patches.
Aug 24 11:14:12 <akiniemi> holtmann: cool
Aug 24 11:14:27 <holtmann> Hope you guys are using automake-1.11 to get the nice silent built.
Aug 24 11:17:57 <akiniemi> holtmann: uh. :)
Aug 24 22:37:28 <denkenz> holtmann: There's nothing pending from me
Aug 24 22:37:45 <denkenz> holtmann: There are some patches from Andrew I need to review, but I doubt I get to them this week
Aug 24 22:40:35 <denkenz> akiniemi: I hope I didn't break isi driver too much :)
**** ENDING LOGGING AT Tue Aug 25 02:59:56 2009

**** BEGIN LOGGING AT Tue Aug 25 02:59:56 2009
Aug 25 06:52:34 <holtmann> So I am done with the conversion to full non-recursive build system
Aug 25 06:52:53 <holtmann> If you guys use automake-1.11 you are in for a real treat :)
Aug 25 06:56:35 <holtmann> oFono was the simplest of all the ones I had so far. The BlueZ one was a pain in the ass and took me three days :(
Aug 25 08:17:40 <akiniemi> holtmann: looking good
Aug 25 08:18:26 <akiniemi> holtmann: Does builtin allow me to name files under isimodem/ the same as in atmodem?
Aug 25 09:00:16 <akiniemi> Ah, it indeed now does. That's good.
Aug 25 14:07:44 <holtmann> akiniemi: Yes. With these fixes we don't have to use a prefix anymore. All *.o are put in their own directories.
Aug 25 14:37:22 <akiniemi>  /n
Aug 25 14:39:45 * akiniemi is having problems with his terminal and non-ascii chars
Aug 25 14:40:42 <akiniemi> It seems RAT selection mode is missing
Aug 25 14:40:53 <akiniemi> Should that be in NetworkRegistration iface?
Aug 25 16:39:52 <denkenz> akiniemi: What is RAT?
Aug 25 16:52:46 <kpel> radio access technology, maybe?
Aug 25 16:57:25 <denkenz> Ah, nod.  I thought we decided not to use the stupid thing
Aug 25 16:57:33 <denkenz> And make proper Band Selection interface
Aug 25 17:01:30 <kpel> dunno, i'm new here.
Aug 25 17:05:10 <denkenz> heh, sorry should have been directed at akiniemi
Aug 25 17:05:47 <denkenz> akiniemi: AFAIK we decided to filter duplicate MCC/MNC combos, as RAT is useless anyway
Aug 25 17:06:01 <denkenz> akiniemi: Then introduce proper BandSelection interface
Aug 25 18:44:01 <akiniemi> denkenz: I mean the selection mode setting
Aug 25 18:44:17 <akiniemi> denkenz: typically phones are GSM only, UMTS only or dual mode
Aug 25 18:49:36 <denkenz> akiniemi: Yes, so thats BandSelection territory I think
Aug 25 18:52:01 <akiniemi> denkenz: that's good. You working on that, or should I take a stab at it?
Aug 25 20:49:18 <denkenz> akiniemi: Take a stab
Aug 25 20:52:55 <denkenz> akiniemi: Just keep in mind, we want something very high level / generic.  There are no 27.007 commands for this
Aug 26 00:48:28 <dilinger> denkenz: i haven't tested this yet, but...
Aug 26 00:48:31 <dilinger> denkenz: http://git.collabora.co.uk/?p=user/dilinger/ofono-g1-new;a=summary
Aug 26 00:49:12 <dilinger> denkenz: any comments?  i'm not overly happy w/ the amount of duplicate code
Aug 26 00:49:50 <dilinger> denkenz: oh, and the autotools stuff needs to be redone to depend upon atmodem instead of simple gatchat
Aug 26 00:50:08 <dilinger> i'm not clear on the differences between "plugin" and "driver"
Aug 26 00:50:20 <denkenz> plugin has 1..n drivers
Aug 26 00:52:52 <denkenz> Basically a plugin is something that can be dlopened by oFono
Aug 26 00:52:57 <denkenz> driver actually defines the interface
Aug 26 00:54:01 <denkenz> btw, why do you even need a config file for the G1 driver?
Aug 26 00:56:36 <dilinger> denkenz: specifying devices
Aug 26 00:56:53 <dilinger> denkenz: i don't *really*, but i based it on generic_at
Aug 26 00:56:56 <denkenz> Isn't it always on /dev/smd0 ?
Aug 26 00:57:08 <dilinger> denkenz: it could be rfcomm0
Aug 26 00:57:32 <dilinger> (i sometimes test it over bluetooth when i'm feeling lazy)
Aug 26 00:57:51 <denkenz> Nod, but I doubt you want that in production driver
Aug 26 00:58:11 <denkenz> Also, you can drop most of CPMS selection logic 
Aug 26 00:58:24 <dilinger> android hardcodes /dev/smd0 in some proprietary blob, so we're pretty safe hardcoding it
Aug 26 00:59:35 <denkenz> Nod, looking like you're on the right path really
Aug 26 00:59:45 <denkenz> I'd remove the g1syntax file and just put it into g1.c
Aug 26 01:00:29 <dilinger> denkenz: as far as location and such, it's in the right place?
Aug 26 01:00:46 <denkenz> For now I think so
Aug 26 01:00:53 <denkenz> Some of this might change anyway
Aug 26 01:01:32 <denkenz> The idea is everything specific to the modem: foo.c
Aug 26 01:01:53 <denkenz> Everything specific to a family of modems drivers/foo/sms.c drivers/foo/voicecall.c
Aug 26 01:02:24 <denkenz> So e.g. if you know that all HTC devices do SMS like this, you can actually submit that into drivers/htc/sms.c, etc
Aug 26 01:02:38 <dilinger> yeah, i have no idea
Aug 26 01:02:49 <denkenz> For now its OK
Aug 26 01:02:55 <denkenz> We can always move it :)
Aug 26 01:04:34 <denkenz> Also, it seems that if you're not tracking leading crlf, you can drop the multiline response states
Aug 26 01:05:07 <denkenz> But be careful of extraneous crlfs in the PDU state
Aug 26 01:07:25 <denkenz> Cut some more code out, simplify it, but otherwise its looking good
**** ENDING LOGGING AT Wed Aug 26 02:59:57 2009

**** BEGIN LOGGING AT Wed Aug 26 02:59:57 2009
Aug 26 18:11:54 <dilinger> denkenz: the only thing using the MULTILINE_RESPONSE stuff is the hint function.  i'm not really sure how the hint stuff is supposed to work
Aug 26 18:12:03 <dilinger> d'oh, no denkenz
Aug 27 00:11:54 * dilinger hrms
Aug 27 00:12:19 <dilinger> depending upon the generic_at driver seems problematic when it's loaded after my g1 driver :/
Aug 27 00:25:21 <denkenz> dilinger: Drivers are not probed until the modem is A)registered, B) powered on
Aug 27 00:27:12 <dilinger> denkenz: what actually causes the enable callback to be called?
Aug 27 00:27:35 <denkenz> couple of things: SetEnabled is one
Aug 27 00:27:45 <dilinger> that's a dbus method/
Aug 27 00:27:45 <dilinger> ?
Aug 27 00:27:46 <denkenz> s/SetEnabled/SetProperty(Powered, True)
Aug 27 00:28:08 <denkenz> the other one is automatic bringup
Aug 27 00:28:19 <denkenz> E.g. if the user set the option that a modem should be powered automagically
Aug 27 00:28:23 <denkenz> That doesn't work yet though
Aug 27 00:29:06 <dilinger> ok
Aug 27 00:29:12 <dilinger> i was introspecting / and not seeing anything useful
Aug 27 00:29:21 <dilinger> but i see that i should be introspecting /G1
Aug 27 00:32:21 <balrog-kun> denkenz: for that +CMGL parsing would it make sense to make g_at_chat_send_listing take another parameter to indicate expecting PDUs?
Aug 27 00:32:30 <balrog-kun> then +CMGR could be converted to use it too
Aug 27 00:32:45 <dilinger> ah, there we go
Aug 27 00:32:53 <denkenz> balrog-kun: That's one idea I had as well
Aug 27 00:33:07 <denkenz> balrog-kun: The best one I had so far anyway  ;)
Aug 27 00:33:36 <balrog-kun> let's try it then
Aug 27 00:34:11 <denkenz> balrog-kun: I won't be able to get to it until next week, I'm in transit tomorrow
Aug 27 00:34:39 <balrog-kun> denkenz: okay
Aug 27 00:35:30 <balrog-kun> denkenz: btw. should the simulator return an error on +CMGL when there are no messages rather than a <cr><lf> alone?
Aug 27 00:35:33 <denkenz> balrog-kun: The changes should be easy I think, just an extra hint for multiline_pdu & few extra states in the parser
Aug 27 00:35:49 <denkenz> It should just return OK, no +CMGL
Aug 27 00:36:33 <balrog-kun> the spec doesn't really say what it should do, currently it returns a <cr><lf> alone and TI Calypso returns an error
Aug 27 00:36:49 <denkenz> Really? heh
Aug 27 00:37:18 <denkenz> Its not really an error, that's bizarre
Aug 27 00:37:27 <denkenz> IMO it should return an OK
Aug 27 00:39:16 <balrog-kun> i'm not really sure, the syntax listed in 07.05 implies if the command was succesfull then at least one +CMGL line needs to appear
Aug 27 00:40:49 <balrog-kun> and the error number from TI Calypso kind of makes sense (it's something like Index out of Range or something).. once you know what it means
Aug 27 00:41:27 <dilinger> hrmph
Aug 27 00:41:27 <dilinger> ofonod[21628]: plugins/g1.c:g1_debug() > AT+CSMS=1\r
Aug 27 00:41:27 <dilinger> ofonod[21628]: plugins/g1.c:g1_debug() < \r\nERROR\r\n
Aug 27 01:30:02 <denkenz> balrog-kun: So strictly speaking I think your interpretation is more correct
Aug 27 01:30:21 <denkenz> balrog-kun: So feel free to return an error, even though its completely not consistent with the way CPBR behaves
Aug 27 01:30:42 <denkenz> dilinger: I already told you that the G1 is freaking weird :P
Aug 27 01:31:27 <denkenz> dilinger: I think what this means is that you can actually skip submitting the ackpdu to the CNMA
Aug 27 01:32:04 <dilinger> denkenz: actually, what's weird is that the reference-ril sets that
Aug 27 01:32:18 <dilinger>     at_send_command_singleline("AT+CSMS=1", "+CSMS:", NULL);
Aug 27 01:32:27 <dilinger> which is where i took it from
Aug 27 01:33:24 <dilinger> but apparently i can't get away w/ using that.  it also doesn't set preferred message store at all
Aug 27 01:35:07 <denkenz> Yeah, it takes a few shortcuts
Aug 27 01:35:32 <denkenz> Does it behave any different when you use smd0 vs rfcomm?
Aug 27 01:35:34 <dilinger> i'm going to hardcode "ME","ME", "ME", since that works w/ the old ofono code
Aug 27 01:35:39 <dilinger> i haven't tried rfcomm
Aug 27 01:36:36 * dilinger is trying to figure out whether the errors i got on sms reception are a problem or not. it didn't like the ack
Aug 27 01:37:16 <denkenz> Yeah, the ack is only sent if CSMS <service> 1 is supported, assuming I'm remembering 27.005 correctly
Aug 27 01:38:24 <dilinger> it looks like w/ larger strings it fails to decode the PDU, too
Aug 27 01:38:26 <dilinger> ofonod[24550]: Got PDU: 07912160130300F4040B916171052144F50003908062127343699E4432994C2693C96432994C2693C96432994C2693C96432994C2693C96432994C2693C96432997C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E9FCFE7F3F97C3E03, with len: 158
Aug 27 01:38:31 <dilinger> ofonod[24550]: Unable to decode PDU
Aug 27 01:38:44 <dilinger> versus
Aug 27 01:38:45 <dilinger> ofonod[24550]: Got PDU: 07912160130300F4040B916171052144F50003908062128300694050381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E1, with len: 75
Aug 27 01:38:49 <dilinger> ofonod[24550]: > AT+CMGD=1\r
Aug 27 01:40:35 <dilinger> whoops, that's the wrong binary :)
Aug 27 01:41:24 <denkenz> Eh, you sent something like dddddgggg?
Aug 27 01:41:58 <dilinger> yeah
Aug 27 01:42:32 <dilinger> but yeah, same sort of thing w/ the new binary
Aug 27 01:45:34 <denkenz> dilinger: If I plug the SMS into my unit tests it works
Aug 27 01:45:46 <denkenz> So something else is wrong
Aug 27 01:49:36 <denkenz> goes back to his hotel room
Aug 27 01:50:03 <dilinger> denkenz: ok
Aug 27 01:53:38 <dilinger> well, it's working now at least
Aug 27 02:29:49 <denkenz> dilinger: Check that you're hex decoding first, since the SMS code is tested to hell and back
Aug 27 02:30:01 <denkenz> dilinger: Of course there still might be an issue
Aug 27 02:35:16 <dilinger> denkenz: i just pushed some more patches; do you want a history of everything, or do you want just feature patches?
Aug 27 02:35:51 <denkenz> dilinger: I'd like cleaned up patches please :)
**** ENDING LOGGING AT Thu Aug 27 02:59:57 2009

**** BEGIN LOGGING AT Thu Aug 27 02:59:57 2009
Aug 27 04:59:06 <denkenz> holtmann: ping
Aug 27 04:59:11 <denkenz> holtmann: util.o src/ssn.o src/call-barring.o src/sim.o src/phonebook.o src/history.o src/message-waiting.o src/simutil.o | gawk '{ print $3 }' | sort -u | \
Aug 27 04:59:11 <denkenz> 				/bin/grep -E -e '^ofono_' -e '^g_dbus_' > src/ofono.exp
Aug 27 04:59:11 <denkenz> /bin/sh: gdbus/mainloop.o: Permission denied
Aug 27 04:59:30 <denkenz> holtmann: wtf is that about?
Aug 27 05:13:34 <dilinger> presumably there's no point in sending this at all, eh?
Aug 27 05:13:35 <dilinger> ofonod[10518]: plugins/g1.c:g1_debug() > AT+CNMA=0\r
Aug 27 05:13:36 <dilinger> ofonod[10518]: plugins/g1.c:g1_debug() < \r\n+CMS ERROR: 500\r
Aug 27 05:15:48 <denkenz> Ok, CNMA can only be used if CSMS is set to 1
Aug 27 05:16:12 <denkenz> But didn't you have this issue already?
Aug 27 05:17:03 <dilinger> right, but in the atmodem driver, the various callbacks use AT+CNMA=0 if !cnma_enabled
Aug 27 05:17:09 <dilinger> what's the point of doing that?
Aug 27 05:17:52 <denkenz>    	 	 	 	 	 	   Execution command confirms correct reception of a new message (SMS-DELIVER or SMS-STATUS-REPORT) which is routed directly to the TE (refer command +CNMI tables 2 and 4). This acknowledgement command (causing ME to send RP-ACK to the network) shall be used when +CSMS parameter <service> equals 1. TA shall not send another +CMT or +CDS result code to TE before previous one is acknowledged.  
Aug 27 05:18:04 <dilinger> yes
Aug 27 05:18:06 <dilinger> i read that as well
Aug 27 05:18:23 <dilinger> note the code i'm looking at, though
Aug 27 05:18:31 <dilinger> it's not attempting to send a proper CNMA
Aug 27 05:18:53 <denkenz> 'proper' cnma?
Aug 27 05:19:27 <dilinger>                 sprintf(buf, "AT+CNMA=0"); /* Should be a safe fallback */
Aug 27 05:19:38 <dilinger> basically, i'm wondering why that line's there at all
Aug 27 05:19:58 <dilinger> in drivers/atmodem/sms.c  (i've already removed it from g1sms.c)
Aug 27 05:20:20 <denkenz> Because you can send an rp-ack or rp-error with a cnma
Aug 27 05:20:24 <denkenz> if the modem supports it
Aug 27 05:20:33 <dilinger> i see; so that's a NACK
Aug 27 05:20:51 <denkenz> Right now we always send an rp-ack
Aug 27 05:21:39 <denkenz> Point is, if your CSMS is failing, you shouldn't be able to use CNMA
Aug 27 05:21:52 <denkenz> CSMS=0 implies delivery via CMTI
Aug 27 05:23:44 <denkenz> E.g. I'm all confused what you're trying to do :)
Aug 27 05:26:23 <dilinger> sorry, it's late here.  i was just wondering what the CNMA=0 bit was for (and noting to myself that i should've deleted it along w/ the rest).
Aug 27 05:27:13 <denkenz> Its a safe fallback in case the modem doesn't support the optional n, PDU parameters to CNMA
Aug 27 05:33:56 <dilinger> hm
Aug 27 05:34:21 <dilinger> should this be using CBMI rather than CBM as well?
Aug 27 05:34:40 <dilinger> currently the CNMI string is 1,1,2,1,1
Aug 27 05:34:57 <denkenz> I've never seen a modem that doesn't support CBM, half of them don't have a dedicated store for cell broadcasts anyway
Aug 27 05:35:20 <denkenz> Something you have to try
Aug 27 06:01:42 <denkenz> holtmann: For some reason NM variable is not set in the generated Makefile
Aug 27 06:01:49 <denkenz> holtmann: Any idea why that is?
Aug 27 07:20:18 <akiniemi> How is the netreg driver bootstrapping supposed to work? Does core assume that driver calls _notify() soon after a probe?
Aug 27 07:20:39 <akiniemi> I'm getting only random success with my ISI driver...
Aug 27 15:00:53 <denkenz> akiniemi: netreg bootstrapping?
Aug 27 15:09:23 <denkenz> akiniemi: So the core waits until the sim_ready status is set to probe the netreg status
Aug 27 15:11:33 <denkenz> akiniemi: That still needs a bit more tweaking, it isn't really clear to me yet whether we can query creg when sim is locked / not inserted
Aug 27 15:12:19 <denkenz> akiniemi: For now you can set the ready status manually if you don't have a sim manager implemented yet, or just implement imsi reading.  That is what triggers sim_ready
Aug 27 21:31:24 <denkenz> holtmann: ping
**** ENDING LOGGING AT Fri Aug 28 02:59:56 2009

**** BEGIN LOGGING AT Fri Aug 28 02:59:56 2009
Aug 28 07:04:22 <akiniemi> denkenz: ah, right. That's of course obvious reading the code, too. ;)
Aug 28 13:08:44 <inz> Hmh, ** (ofonod:16192): DEBUG: Drained: +CMGS: 202
Aug 28 13:09:10 <inz> (I changed ringbuffer_drain to one that uses _read and dumps what was dropped)
Aug 28 20:11:02 <dos000> wow !
Aug 28 20:11:11 <dos000> just found out about ofono now 
Aug 28 20:45:43 * dilinger wonders how important SMS-STATUS-REPORT is.  since CDSI isn't supported, and CDS requires CNMA.., i'm thinking about just turning 'em off
Aug 28 21:07:18 <Robot101> dilinger: is that a delivery report?
Aug 28 21:07:38 <Robot101> Telepathy has API for them in the Messages interface
Aug 28 21:13:56 <dilinger> Robot101: "Sometimes you may want to know whether an SMS message has reached the recipient mobile phone successfully. To get this information, you need to set a flag in the SMS message to notify the SMS center that you want a status report about the delivery of this SMS message."
Aug 28 21:56:08 <dilinger> or i could add CDSI support, i support
Aug 28 21:56:12 <dilinger> er, suppose
**** ENDING LOGGING AT Sat Aug 29 02:59:56 2009

**** BEGIN LOGGING AT Sat Aug 29 02:59:56 2009
Aug 29 14:58:45 <denkenz> inz: You'll have to give me more details on what you're trying to accomplish
Aug 29 15:03:15 <denkenz> dilinger: Status reports are currently not requested by oFono
Aug 29 15:03:39 <denkenz> dilinger: So you can drop CDS(I) until then
Aug 29 15:07:47 <inz> denkenz, I used ATE0 as InitString and the problem was gone
Aug 29 15:08:16 <denkenz> inz: Nod, the default parser throws out echo as garbage
Aug 29 15:08:33 <inz> Yeah, but usually it works with echo, now it didn't
Aug 29 15:08:47 <inz> And it started spamming sms' at 5 ssecond intervals ;)
Aug 29 15:09:19 <inz> For other commands it works just fine, it just missed the +CMGS (and thus tough sending failed)
Aug 29 15:09:23 <denkenz> inz: can you export OFONO_AT_DEBUG=1 and show me the output when it started going wrong?
Aug 29 15:09:34 <inz> It got the OK though
Aug 29 15:10:07 <denkenz> Since the default parser should still work with echo just fine
Aug 29 15:12:51 <denkenz> inz: Btw, it sound like your device isn't formatting the CMGS properly, I think someone on the ML already had this problem
Aug 29 15:16:24 <denkenz> inz: Or there's a bug, so the output will be helpful :)
Aug 29 15:17:21 <inz> The parser works just fine if the echo is off, so I think it's a bug somewhere.
Aug 29 15:17:31 <inz> And it used to work with 0.1
Aug 29 15:18:03 <denkenz> The parser changed in 0.3
Aug 29 15:18:08 <denkenz> So it could be
Aug 29 15:20:57 <inz> I'll try with the OFONO_AT_DEBUG and see if it gives out anything useful.
Aug 29 15:29:44 <inz> http://ofono.pastebin.com/d3f7b18ff
Aug 29 15:30:29 <inz> ** prints are what I added
Aug 29 15:32:18 <denkenz> wonder why CtrlZ is being sent by itself
Aug 29 15:32:54 <denkenz> Can you give me a few extra lines before as well?
Aug 29 15:33:16 <inz> ofonod[21669]: plugins/generic_at.c:at_debug() < 8
Aug 29 15:33:36 <inz> And others just like it, from the end of the PDU
Aug 29 15:34:18 <denkenz> Ah I think I know what it is
Aug 29 15:34:36 <denkenz> Is the PDU line + CtrlZ being echoed?
Aug 29 15:34:53 <inz> yeah
Aug 29 15:35:37 <denkenz> then parser is not exiting out the garbage state on the CtrlZ, instead it is exiting on the leading \r of the CMGS
Aug 29 15:35:44 <denkenz> its a bug :)
Aug 29 15:38:40 <inz> I don't really know if the CtrlZ should be echoed, but it shouldn't hurt ignoring it ;)
Aug 29 15:39:11 <denkenz> exactly :)
Aug 29 15:41:20 <denkenz> inz: Can you try http://pastebin.ca/1547238
Aug 29 15:43:02 <inz> just a sec
Aug 29 15:43:10 <inz> (or about the time +COPS? takes)
Aug 29 15:43:23 <inz> =? that is
Aug 29 15:43:43 <denkenz> ?
Aug 29 15:43:54 <inz> Yup, works
Aug 29 15:44:10 <inz> AT+COPS=? is the slow one, not +COPS?, that's what I meant
Aug 29 15:44:21 <inz> ut with your patch it works nicely
Aug 29 15:44:25 <inz> No more spam =)
Aug 29 15:44:34 <denkenz> good, thanks for checking ;)
Aug 29 16:51:47 <dilinger> denkenz: http://git.collabora.co.uk/?p=user/dilinger/ofono-g1-new;a=summary
Aug 29 16:51:52 <dilinger> denkenz: ignore that last commit
Aug 29 16:52:56 <dilinger> denkenz: comments appreciated :)
Aug 29 17:02:32 <denkenz> dilinger: Squash the turn off sms-status-report commit into sms support commit
Aug 29 17:02:35 <denkenz> Then send those to the ML
Aug 29 17:03:25 <denkenz> Lets have others comment
Aug 29 17:10:38 <dilinger> cool, will do
Aug 29 17:12:56 <holtmann> dilinger, denkenz: I think we have to talk about some renaming here with the plugin names and details.
Aug 29 17:13:25 <denkenz> lets :)
Aug 29 17:13:43 <holtmann> Not right now. I am still officially on vacation and will be offline for the next 4 hours.
Aug 29 17:14:24 <holtmann> The new build system at least lets us easy build everything without massive hacking around :)
Aug 29 17:15:01 <denkenz> Bah vacation, there's no such thing ;)
Aug 29 17:16:31 <denkenz> Btw, I still would like to hear ideas on how we can reuse some aspects of generic at implementations
Aug 29 17:16:53 <denkenz> example being the proposed g1 sms driver, it still cut-pastes code for csca handling
Aug 29 17:25:57 <denkenz> Anyway, send it to the ML still, we can have the discussion about plugins / naming in this context anyway
Aug 29 17:26:49 <holtmann> Don't wait for me with the naming. If the patches are fine, apply them. Renaming can be done later.
Aug 29 17:28:09 <denkenz> Naming isn't necessarily the issue, this is the first real test of the new driver framework
Aug 29 17:28:17 <denkenz> so I wouldn't mind proper feedback
Aug 29 19:28:13 <dilinger> grr
Aug 29 19:28:19 <dilinger> ofonod[1276]: plugins/g1.c:g1_debug() < \r\n+CMTI: "ME",8\r\n
Aug 29 19:28:30 <dilinger> ofonod[1276]: plugins/g1.c:g1_debug() > AT+CMGR=8\r
Aug 29 19:28:30 <dilinger> ofonod[1276]: plugins/g1.c:g1_debug() < \r\n+CMS ERROR: 321\r
Aug 29 19:28:30 <dilinger> ofonod[1276]: Received a CMTI indication but CMGR failed!
Aug 29 19:28:41 <dilinger> g1 fail
Aug 29 19:28:44 <denkenz> lol
Aug 29 19:29:08 <denkenz> Try to reboot it, I betcha it supports CNMA even though it doesn't say it does
Aug 29 19:29:28 <denkenz> But yes, go shoot Ericsson or TI or whoever made that modem
Aug 29 19:29:41 <dilinger> i'm pretty sure it supports CNMA, as that's what ril uses
Aug 29 19:29:52 <dilinger> but i can't figure out how to turn it on
Aug 29 19:30:50 <denkenz> Try sending the same init commands as what RIL sends
Aug 29 19:31:10 <denkenz> Also, didn't CNMA actually work before?
Aug 29 19:31:43 <dilinger> > AT+CSMS=0\r
Aug 29 19:31:51 <dilinger> that's what the old code sends
Aug 29 19:32:13 <dilinger> so presumably it wasn't using CNMA (though i haven't verified)
Aug 29 19:33:22 <denkenz> is your CPMS setup correctly?
Aug 29 19:34:07 <dilinger> possibly not.  will investigate after i track down a segv
Aug 29 19:34:11 <denkenz> try sending a CPMS query when you receive a CMTI
Aug 29 19:34:18 <denkenz> see if its being reset somehow
Aug 29 21:24:46 <dilinger> denkenz: the exit path for plugins could use some clarity
Aug 29 21:25:02 <dilinger> as long as you're looking for api comments
Aug 29 21:27:54 <dilinger> when i ctrl-c the daemon, it looks like g1_exit is called; the first thing this does is free up g1_data.  after that (and ofono_modem_remove), it calls ofono_modem_driver_unregister..  this calls g1_disable, which expects g1_data to still exist
Aug 29 21:28:38 <dilinger> it's not clear how the ofono_modem->driver_data should be handled, and where it does and doesn't exist
Aug 29 21:30:36 <dilinger> er, s/ofono_modem_driver_unregister/ofono_modem_remove/
Aug 29 21:32:19 <denkenz> dilinger: Ctrl C should cleanup the modems first, so I need to fix that
Aug 29 21:32:27 <denkenz> However, when modem is removed, all atoms are removed first
Aug 29 21:32:34 <denkenz> Then modem remove is called
Aug 29 21:34:06 <denkenz> Simply modem_remove in g1_exit should fix it for now
Aug 29 21:34:44 <dilinger> i was just going to move the g_free(d) to the end of g1_exit
Aug 29 21:35:20 <dilinger> but it should be made clear at which point driver methods may be called
Aug 29 21:36:17 <denkenz> Actually you should free the data in the remove method of the modem driver
Aug 29 21:36:26 <denkenz> And new it in probe
Aug 29 21:36:36 <denkenz> Then your problem disappears
Aug 29 21:37:36 <dilinger> g1_disable requires access to d->io and d->chat, though
Aug 29 21:37:48 <dilinger> and disable is called after remove, right?
Aug 29 21:37:54 <dilinger> or is that not the case?
Aug 29 21:38:09 <denkenz> no
Aug 29 21:38:13 <denkenz> disable is power up / down
Aug 29 21:38:22 <denkenz> probe / remove is device exist / not
Aug 29 21:38:31 <denkenz> probe is called before enable
Aug 29 21:38:35 <denkenz> remove is called after disable
Aug 29 21:38:35 <dilinger> oh
Aug 29 21:39:47 <dilinger> well, that explains a lot
Aug 29 21:40:10 <denkenz> hehe, yeah that should fix your segv issues
Aug 29 21:40:14 <dilinger> uh, so my recommendation is now for clearer names :)
Aug 29 21:40:54 <denkenz> that might be problematic, since that is kernel/connman/bluez conventions
Aug 29 21:41:10 <dilinger> kernel convention is probe/remove
Aug 29 21:41:51 <denkenz> Well suggest something ;)
Aug 29 21:41:52 <dilinger> enable/disable is usually called from probe/remove in the case of (eg) pci devices
Aug 29 21:42:32 <dilinger> powerup/powerdown would be okay
Aug 29 21:43:06 * dilinger thinks
Aug 29 21:43:26 <denkenz> Suggest it to the ML, I've no issue with names, but holtmann might
Aug 29 21:43:43 <denkenz> anyway, I'm off for a few hours
Aug 29 21:57:59 <Tino> hi
Aug 29 21:59:03 <Tino> help
Aug 29 22:01:53 <dilinger> ok, sent
Aug 29 23:46:00 * dilinger mutters
Aug 29 23:46:37 <dilinger> ofonod[5358]: plugins/g1.c:g1_debug() > 0011000A8116571042540000A70AD7F7BB850EA35D2E17<CtrlZ>
Aug 29 23:46:40 <dilinger> ofonod[5358]: plugins/g1.c:g1_debug() < \r\n\r\n+CMS ERROR: 330\r
Aug 29 23:54:57 <dilinger> i think i forgot to set CSCA
Aug 29 23:57:31 <dilinger> hm.  or something.
Aug 30 00:03:45 <dilinger> bizarre.  it's happening w/ the old code as well.  maybe the network's screwy again?
**** ENDING LOGGING AT Sun Aug 30 02:59:57 2009

**** BEGIN LOGGING AT Sun Aug 30 02:59:57 2009
Aug 30 04:04:44 <dilinger> and rebooting the phone fixed it.  whee.
**** ENDING LOGGING AT Mon Aug 31 02:59:57 2009

**** BEGIN LOGGING AT Mon Aug 31 02:59:57 2009
Aug 31 07:27:40 <PaulFertser> Hi, everybody. I (and others) suspect that ofono will be used in the upcoming "n900" device. What driver will be used for that, ISI? Is it some userspace library communicating with usb devices via kernel "phonet" driver? I tried googling before asking ;)
Aug 31 07:32:22 <akiniemi> PaulFertser: oFono isn't part of Maemo 5 yet. The ISI modem plugin needs a lot of work before that can happen. :)
Aug 31 07:32:56 <PaulFertser> akiniemi: we all assumed that one of the reasons for bootsting oFono work is the upcoming device from Nokia...
Aug 31 07:33:24 <PaulFertser> akiniemi: what will it use for telephony then?
Aug 31 07:36:37 <akiniemi> PaulFertser: proprietary stack, built on top of PhoNet 
Aug 31 07:37:04 <akiniemi> But oFono is what we're expecting to use in the future. We just haven't been able to say it aloud. ;)
Aug 31 07:37:42 <PaulFertser> BTW, while googling to understand wtf ISI and phonet are i found a mailing list thread that made me sad and disillusioned in nokia enough, quote from there: "I talked with Remi about it and he told me that currently there is no public example on how to do it. ... At some point we will have an example inside oFono on how to do it, but not right now."
Aug 31 07:38:21 <PaulFertser> akiniemi: i personally was disgusted to read that, it's like a spit in my and my friends direction :(
Aug 31 07:38:27 <akiniemi> PaulFertser: I miss the context on that quote...
Aug 31 07:38:41 <PaulFertser> akiniemi: http://kerneltrap.org/mailarchive/search/%40subject%20%22Re%3A%20%5BPATCH%5D%20USB%20host%20CDC%20Phonet%20network%20interface%20driver%22/linux-usb
Aug 31 07:39:02 <akiniemi> Ah, that's cdc_phonet
Aug 31 07:39:16 <akiniemi> Remi pÃushed a patch for that some weeks ago
Aug 31 07:39:43 <akiniemi> Everything you need to use a Nokia modem via USB should be open now
Aug 31 07:40:22 <PaulFertser> akiniemi: is modem usage meant use it for data transfer or all the fancy features, including voice?
Aug 31 07:40:40 <akiniemi> I've been meaning to make a short howto for that stuff and oFono, but we've been a bit busy, for obvious reasons :)
Aug 31 07:41:38 <akiniemi> PaulFertser: the works (though Symbian phones block some parts of the ISI protocol, unfortunately...)
Aug 31 07:41:56 <PaulFertser> akiniemi: but do you understand that it's a major turn off to hear something like "we know how to do something but we won't tell (yet)"?.. BTW, great thanks for sharing the info about n900, really appreciate it! :D
Aug 31 07:42:25 <courmisch> how to do what?
Aug 31 07:42:46 <akiniemi> courmisch: cdc_phonet
Aug 31 07:42:50 <PaulFertser> courmisch: anything useful to the general public, it doesn't matter.
Aug 31 07:44:20 <PaulFertser> akiniemi: one last question: can you possibly tell what will be the hardest obstacles with replacing Maemo5 (except the video driver) with fully free software OS?
Aug 31 07:45:02 <courmisch> cdc_phonet is published, what is the problem now?
Aug 31 07:45:20 <PaulFertser> courmisch: the attitude?
Aug 31 07:45:55 <courmisch> well ofono is not quite ready for N900 just now
Aug 31 07:46:30 <courmisch> and then you need a UI for all that phone stuff
Aug 31 07:46:34 <PaulFertser> courmisch: Remi, i understand that. What i can't understand is hiding specs... :(
Aug 31 07:47:32 <PaulFertser> courmisch: you know hackers can be happy even using a mock-up python script written in spare weekend for all their cell telephony needs.
Aug 31 07:48:03 <akiniemi> PaulFertser: attitude? You're actually complaining because we're pushing Nokia modem API out under GPL? 
Aug 31 07:48:18 <akiniemi> PaulFertser: I find that odd
Aug 31 07:48:30 <PaulFertser> akiniemi: heh, not exactly, sorry :)
Aug 31 07:49:45 <akiniemi> PaulFertser: ok. But sorry to say, there will probably always be specs we are hiding...
Aug 31 07:49:51 <PaulFertser> akiniemi: i meant if you say "i know how to do that but won't tell" it sounds extremely rude. And if you say something "i know how to do that and though i'm prohibited to publish that (yet) i'm looking forward to an opportunity" that'd sound like you a nice guy.
Aug 31 07:50:32 <akiniemi> but we are honestly aiming to make Nokia modems fully usable through oFono
Aug 31 07:51:17 <PaulFertser> akiniemi: probably you might want to stress it more to make sure everybody sees that you're with "hackers" and not with "stupid vendors".
Aug 31 07:51:18 <akiniemi> PaulFertser: ah, ok. Sorry it came across like that.
Aug 31 07:52:56 <PaulFertser> courmisch: do i understand it right that "phonet" is transport protocol but to make real use of it one needs to implement ISI on top? And that it's that ISI knowledge that would be required for implementing alternative telephony stack for n900?
Aug 31 07:56:39 <courmisch> well the plan is to publish that as part of Ofono, but it takes time
Aug 31 08:00:09 <PaulFertser> courmisch: but is plan to have it fully open-source and not obfuscated?
Aug 31 08:01:24 <PaulFertser> courmisch: also can you possibly tell me why isn't it possible to just opensource the proprietary stack that will be used on those devices? Are there any real reasons behind that? I just can't see how that can harm nokia's business even a little bit.
Aug 31 08:07:05 <courmisch> reviewing this large chunk of code for open-source would take a lot of time
Aug 31 08:07:13 <courmisch> which would be diverted from writing ofono
Aug 31 08:07:48 <akiniemi> PaulFertser: you can already see some ISI codepoints and protocol implementation in drivers/isimodem
Aug 31 08:07:49 <PaulFertser> courmisch: what do you mean by reviewing? To make sure it doesn't contain other's "imaginary property"?
Aug 31 08:08:05 <PaulFertser> akiniemi: i know, luckily your git tree is public and sane :D
Aug 31 08:09:01 <courmisch> no, that the code quality is good, that the license boilerplate is in place, that we have a source code hosting
Aug 31 08:10:49 <PaulFertser> courmisch: who cares about code quality if it's used for reference? Licensing... Well, adding an appropriate header to every file containing code can be automated. Hosting? I can't understand it, i thought Nokia has zero problems with hosting anything, esp. if it's one moderately sized tarball.
Aug 31 08:11:43 <PaulFertser> courmisch: and btw, it's supposed that Nokia cares about code quality before releasing an end-users targeted device to general public so it's not an issue too.
Aug 31 08:11:48 <courmisch> it would be impolite to authors to publish code they did not know would be open-sourced
Aug 31 08:11:56 <courmisch> generally speaking
Aug 31 08:12:12 <akiniemi> PaulFertser: I don't see the point in us having two open code bases to look after
Aug 31 08:12:37 <PaulFertser> courmisch: i thought Nokia employees who write proprietary code transfer copyright to Nokia, so it's legally correct. As to impolite... Well, strip authors names.
Aug 31 08:13:22 <akiniemi> PaulFertser: once the ISI plugin is functional, we'Ãll upload to memo-extras so it's available for protoyping on Maemo5
Aug 31 08:13:24 <PaulFertser> akiniemi: i'm not talking about maintaining two codebases. You say oFono support will take time, that's perfectly understandable and ok. But publishing already existing code shouldn't take time (in my perverted reality of course).
Aug 31 08:13:50 <courmisch> PaulFertser: yes it would be legal, but impolite
Aug 31 08:15:23 <akiniemi> PaulFertser: we're now concentrating on oFono, but of course opening up the Maemo5 telephony stack is an option
Aug 31 08:15:28 <PaulFertser> courmisch: do you mean that's the main obstacle to publish that proprietary telephony stack? TBH, it just doesn't look like true. Nokia pushes for software patents and that is considered "ok" and yet they're afraid to hurt feelings of their coders? Sorry, i really doubt that.
Aug 31 08:15:58 <akiniemi> Not something I think makes sense, but sure we could release not just binaries but src packages as well
Aug 31 08:16:05 <courmisch> my point is that it would divert time that could be more usefully spent on Ofono (from my perspective) and would be impolite to the other authors
Aug 31 08:17:15 <PaulFertser> courmisch: how much man-hours would be needed to do that? I just can't understand what's the issue if it's a matter of, say, one working day all in all.
Aug 31 08:17:25 <courmisch> besides, by the time we would sort it out, the Ofono ISI driver would probably be at a more acceptable functional level
Aug 31 08:17:42 <akiniemi> I don't think we're talking about more than a few months (say, 4-6) before the ISI plugin is feature complete
Aug 31 08:18:02 <PaulFertser> Sorry guys, believe me i'm not trolling, i honestly can't understand it's like we're talking different languages :(
Aug 31 08:20:03 <PaulFertser> akiniemi: imagine some hacker buys N900 and founds a minor inconvenience or comes up with a creative idea. If the sources to the stack it runs are published, it'd take him e.g. several days to solve that bug. Now you say him: wait 4-6 months and also wait for oFono-compatible UI apps. Probably he'll spend more time on reverse-engineering stuff to run FSO on the device instead, you see?
Aug 31 08:20:54 <tmzt> the API ofono provides to application's is well specified/documented?
Aug 31 08:21:13 <PaulFertser> tmzt: it's supposed to be very high-level and yes, docs are available
Aug 31 08:22:07 <akiniemi> PaulFertser: he's free to do whatever he wants, of course
Aug 31 08:22:17 <PaulFertser> tmzt: it's supposed to be like bluez's: maps 1-1 to GUI elements.
Aug 31 08:22:24 <tmzt> misunderstood the last point, can't see how ui would be an issue
Aug 31 08:22:39 <tmzt> if that is the case
Aug 31 08:23:01 <PaulFertser> akiniemi: yes, of course. But is it polite to force people to spend days of reverse-engineering when you can spend hours to publish the code?
Aug 31 08:23:10 <PaulFertser> polite/ethical
Aug 31 08:26:27 <akiniemi> PaulFertser: there are roughly four choices for him: 1) file a bug, 2) hack with the existing D-Bus API to the telephony stack, 3) use experimental oFono, 4) run any stack he wants, incl. FSO
Aug 31 08:26:52 <akiniemi> PaulFertser: my point is, any patches should be against oFono, not the old code base
Aug 31 08:27:05 <PaulFertser> akiniemi: (patches) absolutely no doubt!
Aug 31 08:27:55 <tmzt> how much does this differ from the binary protocols used by gnokii, etc.
Aug 31 08:28:01 <PaulFertser> akiniemi: but to run any stack he wants he needs enough open information about ISI, that's my point, that it'd be nice to publish sources of everything that can help him.
Aug 31 08:28:53 <PaulFertser> tmzt: well, who says that the way FBUS/MBUS is used is "ok"? To me it's definetely not, no official docs whatsoever is a shame.
Aug 31 08:29:01 <akiniemi> PaulFertser: like I said, drivers/isimodem will have all the goods
Aug 31 08:29:52 <akiniemi> PaulFertser: also remember, with N900, we never had to support anything but a single version of the modem API
Aug 31 08:29:57 <PaulFertser> akiniemi: will have it 4 months later after the devices are on the shelves... And one can have all the code right now with the release. I just can't understand the reasoning, sorry.
Aug 31 08:30:12 <PaulFertser> akiniemi: i'm not talking about support at all, can't you see? :(
Aug 31 08:30:39 <PaulFertser> akiniemi: just about publishing code/manuals/datasheets whatever without any kind of support or obligations. 
Aug 31 08:31:31 <akiniemi> PaulFertser: datasheets aren't something we can disclose, sorry
Aug 31 08:32:28 <PaulFertser> akiniemi: it's like we're playing hide-and-seek :(
Aug 31 08:33:15 <tmzt> PaulFertser: I'm not sure I understand what you're asking either
Aug 31 08:34:30 <PaulFertser> tmzt: you came late to the "party". I'm asking Nokia :) to disclose all the sources they can along with the release of the hardware (N900). They say: wait 4-5 months and ofono will support it. I say why not publish the proprietary telephony stack right now... 
Aug 31 08:34:45 <tmzt> n900 is an interesting device, open cpu except sgx, usb interface (not shared memory) to the modem, ethernet based hspa
Aug 31 08:35:32 <tmzt> so I can certainly see the interest in having a choice of phone stacks
Aug 31 08:35:39 <akiniemi> tmzt: actually, it's a serial interface (SSI) to the modem
Aug 31 08:35:51 <tmzt> oh?
Aug 31 08:36:12 <akiniemi> tmzt: cdc_phonet allows you to run oFono on the desktop using a phone as the modem HW
Aug 31 08:36:25 <tmzt> ah, I see
Aug 31 08:36:40 <tmzt> I thought that was only for development
Aug 31 08:38:14 <akiniemi> tmzt: yes, but a necessary prerequisite to developing on oFono ;)
Aug 31 08:38:18 <tmzt> I can't see why it would make sense to release a codebase that others expect to be maintained
Aug 31 08:38:45 <tmzt> even if it were possible
Aug 31 08:39:27 <tmzt> okay, so the protocol used over phonenet must be similar to the one used on ssi?
Aug 31 08:39:43 <tmzt> otherwise I can't see how that helps
Aug 31 08:43:24 <akiniemi> tmzt: it's identical: ISI over PhoNet over SSI or USB
Aug 31 08:43:57 <PaulFertser> tmzt: (releasing unmaintained codebase) for reference, to get ISI specs from the code right now, not in several months.
Aug 31 08:44:20 <tmzt> yeah, I understood that
Aug 31 08:46:13 <tmzt> just that releasing the code is releasing the code
Aug 31 08:46:27 <tmzt> same effort, whatever the reason
Aug 31 08:47:15 <tmzt> ssi is used for 3g data also?
Aug 31 08:49:44 <akiniemi> tmzt: yes, take a look at gisi/pipe.{h,c} for the control part
Aug 31 08:50:03 <tmzt> where is that?
Aug 31 08:50:22 <akiniemi> in oFono source tree ;)
Aug 31 08:50:57 <akiniemi> not hidden very well... :)
Aug 31 08:52:08 <tmzt> ah, so there is source, just not for some drivers yet?
Aug 31 08:52:24 <tmzt> I haven't been paying much attention yet
Aug 31 08:59:44 <courmisch> some old version of the SSI driver source code was published on linux-omap mailing list rougly 11 months ago
Aug 31 09:00:00 <courmisch> you can find more recent version in the Fremantle SDK kernel sources
Aug 31 09:00:20 <courmisch> and of course, the release N900 version will be included in the released kernel sources
Aug 31 11:13:37 <akiniemi> Is convert_utf8_to_gsm() intentionally translit'ing? I.e., y with accent -> plain y?
Aug 31 11:14:18 <akiniemi> IMO, if a character isn't representable in GSM 7bit, we need to switch to UCS-2
Aug 31 14:26:04 <denkenz> akiniemi: Do you know the character codes?
Aug 31 14:28:09 <akiniemi> denkenz: in unicode_256_table, 0xFD and 0xFF are marked as 0x79
Aug 31 14:28:12 <akiniemi> should be GUND
Aug 31 14:28:46 <akiniemi> (BTW, I'm working on a patch I promised some time ago to enable national language variants...)
Aug 31 14:28:56 <akiniemi> (that's how I noticed ;)
Aug 31 14:29:14 <denkenz> akiniemi: It probably is transliterating then
Aug 31 14:29:33 <denkenz> akiniemi: Should be as simple as fixing the table
Aug 31 14:29:46 <akiniemi> denkenz: sure
Aug 31 14:30:30 <akiniemi> denkenz: I'll have a set of patches ready shortly, should probably send to the ML?
Aug 31 14:31:21 <denkenz> akiniemi: what to they do?
Aug 31 14:32:27 <akiniemi> Add tables for Turkish, Spanish, Portuguese; and additional API to do convert with lang
Aug 31 14:32:50 <denkenz> ah, the tables just simply push
Aug 31 14:33:09 <denkenz> the logic might be fun to review
Aug 31 14:33:14 <akiniemi> Also a new enum in smsutil.h for sms_language, and of course the smsutil.c needs to detect the lang variants from UDH...
Aug 31 14:33:21 * akiniemi nods
Aug 31 14:33:51 <akiniemi> So perhaps I'll just push the tables, but send the patches to smsutil.{c,h} to list
Aug 31 14:34:05 <denkenz> sounds like a plan
Aug 31 15:11:49 <inz> Grr, my hasty system doesn't get NM in Makefile (configure says it finds suitable nm) and build fails...
Aug 31 15:14:39 <denkenz> Yes, see the thread from a few days ago about NM
Aug 31 15:14:50 <denkenz> the easiest quickest fix is to upgrade libtool
Aug 31 15:15:57 <inz> Ah indee, I kinda just skipped it cause it was of no interest xD
Aug 31 15:45:16 <inz> Any idea how new of a libtool do I need?
Aug 31 15:47:01 <denkenz> I'm using 2.2.6 with no issues
Aug 31 15:47:38 <inz> hasty has 1.5.26
Aug 31 15:48:03 <denkenz> I used that one before and had issues
Aug 31 15:49:03 <denkenz> you can work around by using AC_SUBST like Yang suggested
Aug 31 15:50:09 <inz> Yeah, it's likely faster, qemu-arm is friggin slow ;)
Aug 31 16:18:42 <denkenz> quick poll, do we want to export the length of MNC information (2 or 3) of the IMSI as an attribute
Aug 31 16:19:11 <denkenz> or support IMSI MNC & MCC attributes directly?
Aug 31 21:40:38 <denkenz> akiniemi: Do your modem APIs support writing of EFplmnwact or do you need to go through a silly CPOL equivalent?
Aug 31 21:51:12 <denkenz> akiniemi: I'm asking since we can do some interesting things by automagically updating the preferred operator list based on manual network registrations
Aug 31 21:51:28 <denkenz> akiniemi: Similar to how your Wifi devices work
Aug 31 21:56:05 <denkenz> s/your Wifi/Wifi/
Aug 31 22:35:33 <dilinger> denkenz: any idea what the timeline is for 0.4?
Aug 31 22:35:56 <denkenz> It'll be before end of next week
Aug 31 22:36:08 <denkenz> Since I'm traveling for two weeks after that
Aug 31 22:36:18 * dilinger nods
Aug 31 22:36:26 <dilinger> denkenz: will G1 support be in there? :)
Aug 31 22:36:57 <denkenz> Thats up to you :)
Aug 31 22:37:23 <denkenz> Btw, what did SMS driver boil down to
Aug 31 22:37:29 <denkenz> is it just the CNMI string and thats it?
Aug 31 22:37:31 <dilinger> denkenz: what else are you waiting for from me?
Aug 31 22:37:57 <dilinger> yeah, the CNMI hack is really the only thing the G1 needs
Aug 31 22:38:27 <denkenz> Then me and holtmann need to discuss some sort of driver parameters API
Aug 31 22:38:49 <denkenz> So e.g. you can do something like ofono_sms_set_parameter(sms, "CNMIString", "AT+CNMI=")
Aug 31 22:38:55 <denkenz> and avoid huge duplication
Aug 31 22:38:59 * dilinger nods
Aug 31 22:39:23 <dilinger> surely that won't happen prior to 0.4 though, will it?
Aug 31 22:39:38 <dilinger> i mean, if you're shooting for end of week..
Aug 31 22:40:25 <denkenz> Shrug, adding parameters is easy, that can be done in an hour
Aug 31 22:40:31 <denkenz> Matter of how to do it
Aug 31 22:41:21 <denkenz> The only other thing I want you to do is to make the g1.c a bit more sane
Aug 31 22:41:30 <dilinger> hrm.  okay.  it would be nice to have it merged, though.  i'd like to not have to keep using custom builds of ofono
Aug 31 22:41:36 <dilinger> how so?
Aug 31 22:41:42 <denkenz> E.g. disable/enable should not close / open the tty
Aug 31 22:41:49 <denkenz> You should use something like AT+CFUN
Aug 31 22:42:19 <denkenz> Also, see if you can use the g_at_chat tty open function
Aug 31 22:42:32 <dilinger> i.. wait, what?
Aug 31 22:42:33 <denkenz> instead of duplicating tty_connect from generic driver
Aug 31 22:42:37 <dilinger> generic_at does the same thing
Aug 31 22:42:45 <denkenz> I know, but generic_at is a toy ;)
Aug 31 22:42:51 <holtmann> dilinger, denkenz: With the new build system we can even share source code files between drivers/plugins. That is no problem anymore.
Aug 31 22:42:55 <dilinger> ok.  i thought it was an example.
Aug 31 22:43:15 <holtmann> So if you are worried about code duplication, just make sure we have it in separate files and then we link it together.
Aug 31 22:43:29 <holtmann> dilinger: I am waiting for a good to go from Denis before 0.4.
Aug 31 22:43:58 <denkenz> holtmann: The problem is for G1 dilinger had to cp the sms.c driver and just change 1 line
Aug 31 22:44:04 <dilinger> denkenz: ok, well, the sooner people can provide me w/ comments like this, the better
Aug 31 22:44:30 <denkenz> dilinger: nod, you're next on my todo, I just had to process my backlog of patches
Aug 31 22:44:40 <holtmann> denkenz: The we should just extract that whole thing into one function and give it a parameter. Then call it from both drivers.
Aug 31 22:45:14 <denkenz> holtmann: Hence why I'm thinking of having proper module params, kinda like kernel modules
Aug 31 22:45:30 <holtmann> That is way to tricky. I prefer just doing this at compile time.
Aug 31 22:45:51 <denkenz> holtmann: Problem is, breaking up generic_at into something that is a generic library isn't easy
Aug 31 22:46:43 <denkenz> holtmann: Its easier to expose simple string parameters
Aug 31 22:48:59 <holtmann> denkenz: I am not thinking about a library. Just break it up into source files. So just link them together as you like.
Aug 31 22:50:07 <denkenz> holtmann: Problem is, the current code assumes certain structure
Aug 31 22:51:16 <denkenz> holtmann: so unless we break up every single function into a source file... :)
Aug 31 22:51:34 <holtmann> We need to talk about this then. I prefer not to do the plugin parameters. Also we only should break up functions that are useful for sharing.
Aug 31 22:52:02 <holtmann> And again, we can have multiple in the same file. Even if they are not used. The linker will sort these out and remove them from the final build.
Aug 31 22:52:29 <denkenz> holtmann: I think you need to look at the sms driver in detail
Aug 31 22:52:32 <holtmann> Especially with builtin plugins, they will be nicely stripped.
Aug 31 22:52:50 <denkenz> holtmann: Its hard to describe, easier to look at it
Aug 31 22:53:47 <holtmann> Point me at it.
Aug 31 22:54:45 <denkenz> holtmann: drivers/atmodem/sms.c
Aug 31 22:55:01 <holtmann> I am there. And then.
Aug 31 22:55:07 <holtmann> Which function needs to be shared.
Aug 31 22:56:22 <denkenz> holtmann: So basically grep for build_cnmi_string
Aug 31 22:56:44 <denkenz> The default driver queries what is supported, selects the most sensical options and tries to apply them
Aug 31 22:57:11 <denkenz> G1 reports things, but it actually lies about what it supports
Aug 31 22:57:23 <denkenz> so we must override the cnmi string
Aug 31 22:57:53 <denkenz> i.e. there's no function to really share
Aug 31 22:58:18 <holtmann> Can we not just have quirks in the original generic AT driver. Saying something like ignore CNMI or so.
Aug 31 22:58:41 <denkenz> holtmann: So quirks is where I'm going with the driver parameters idea
Aug 31 22:58:46 <dilinger> i would love quirks.  that would've allowed me to bypass this whole adventure :/
Aug 31 22:59:27 <denkenz> How to express quirks though?  
Aug 31 22:59:58 <denkenz> In the case of the G1, we actually need the CNMI string
Aug 31 23:00:07 <denkenz> As only a particular one works AFAIK
Aug 31 23:01:27 <dilinger> i'm personally a fan of the mmc/sd stack quirks system.  it's limited to 32 quirks, but that could be worked around.  it's also tied to manufacturer info, which i'm not able to query afaict from the G1  (it responds w/ just "HTC", nothing about G1)
Aug 31 23:03:19 <denkenz> The driver actually has that info to some extent
Aug 31 23:03:29 <denkenz> modem driver that is
Aug 31 23:03:37 <denkenz> so it could control the quirk settings
Aug 31 23:05:24 <dilinger> what kind of info?  CGMI, CGMM, and CGMR all return "HTC"
Aug 31 23:08:55 <denkenz> Maybe stuff from /proc?
Aug 31 23:09:01 <denkenz> Or even config files?
Aug 31 23:11:20 <tmzt> you should be looking for DREA100/300
Aug 31 23:11:41 <dilinger> i'd be nervous about using stuff from /sys or /proc, simply because ofono's dealing w/ embedded systems
Aug 31 23:11:48 <tmzt> although there's nothing specific about the g1's radio I think, it should be enough to see if it's gsm and HTC, or check the radio firmware version
Aug 31 23:11:49 <dilinger> who knows what kind of crack they've got in their kernels
Aug 31 23:11:54 <tmzt> which should be in ATI I think
Aug 31 23:12:10 <denkenz> shrug, then simply fail
Aug 31 23:12:21 <dilinger> ..like /sys/android_camera and /sys/android_gsensor.  ugh.
Aug 31 23:12:23 <denkenz> Someone will come to the mailing list and complain and then we can resolve it
Aug 31 23:12:26 <tmzt> hal/device kit might be better
Aug 31 23:12:43 <holtmann> When selecting the driver we should be able to handover the quirk/driver_info/id and then give that to probe().
Aug 31 23:13:18 <denkenz> holtmann: So it really belongs in e.g. ofono_sim_create()
Aug 31 23:13:39 <dilinger> tmzt: yeah, that's the question; are these bugs applicable to all HTC modems, or just a subset?  and if only a subset, a quirks system should be able to distinguish between them
Aug 31 23:13:57 <tmzt> I would say all current gsm htc modems, if you mean the format stuff
Aug 31 23:15:01 <tmzt> if nothing else, ask in #android, some google people should be there now and the root people have been pushed to #android-root, so it's much quieter
Aug 31 23:15:09 <dilinger> tmzt: i'm talking about specific bugs; they're essentially listed by commit: http://git.collabora.co.uk/?p=user/dilinger/ofono-g1;a=summary
Aug 31 23:15:42 <tmzt> can you paste ATI output?
Aug 31 23:15:53 <tmzt> it's been a while since trying this on hardware
Aug 31 23:16:37 <denkenz> holtmann: worst case we can do quirk flags in a bitfield, but there's limitation of 32 or 64 flags or so
Aug 31 23:16:42 <holtmann> HAL is dead. And so is DeviceKit.
Aug 31 23:16:56 <tmzt> holtmann: so what is there now? particularly for embedded
Aug 31 23:17:04 <holtmann> libudev.
Aug 31 23:17:19 <tmzt> custom properties will be handled through udev then?
Aug 31 23:17:30 <holtmann> Yes.
Aug 31 23:17:39 <tmzt> and callouts?
Aug 31 23:17:40 <dilinger> tmzt: http://pastebin.com/m2c5e0bf2
Aug 31 23:18:03 <tmzt> oh, that's not very useful
Aug 31 23:18:06 <tmzt> I see what you mean
Aug 31 23:18:32 <tmzt> no firmware version in reponse to any of the queries?
Aug 31 23:18:35 <denkenz> lol, someone shoot these Chiense manufacturers ;)
Aug 31 23:18:45 <dilinger> tmzt: what's interesting is that if i used rfcomm0 instead of smd0 (ie, if rild is between me and the modem), it will actually give me G1 model info
Aug 31 23:19:02 <dilinger> tmzt: but it won't support SMS commands, so that's out of the question
Aug 31 23:19:52 <denkenz> dilinger: its not really an option, especially once we get GPRS support
Aug 31 23:19:59 <tmzt> it's getting it from somewhere, that code is open by the way
Aug 31 23:20:05 <tmzt> only the ril itself isn't
Aug 31 23:20:14 <tmzt> #android is a better place for this though
Aug 31 23:31:26 <dilinger> AT+RADIOVER
Aug 31 23:31:27 <dilinger> +RADIOVER: 62.33.20.08H
Aug 31 23:36:02 <dilinger> anyways, getting back on topic.. i could envision a quirks system that allows you to select a parser and set some flags based upon some kind of modem identification
Aug 31 23:36:30 <dilinger> and throughout the generic code, you've got things like
Aug 31 23:38:06 <dilinger> supported_modes = modem->flags & QUIRK_NO_CNMI_MODE_2 ? "1" : "21";
Aug 31 23:38:59 <dilinger> append_cnmi_element(buf, &len, cnmi_opts[0], supported_modes, FALSE)
Aug 31 23:40:20 <dilinger> not ideal once you find other hardware with broken CNMI modes, though
Sep 01 00:12:12 <denkenz> yah, but the flag based quirks are a little limiting
Sep 01 00:12:54 <denkenz> I'd prefer strings, but either way we need something
**** ENDING LOGGING AT Tue Sep 01 02:59:57 2009

**** BEGIN LOGGING AT Tue Sep 01 02:59:57 2009
Sep 01 04:16:22 <denkenz> balrog-kun: Check latest additions to gatchat, see if they work you
Sep 01 10:22:50 <akiniemi> denkenz: the modem updates the preferred list automagically
Sep 01 10:23:12 <akiniemi> denkenz: and I'd actually be surprised if most modems didn't do that...
Sep 01 14:05:40 <denkenz> akiniemi: Actually most Windows Mobile devices let you control the user-controlled preferred list
Sep 01 14:46:57 <denkenz> akiniemi: Couple of my oldie SE devices also have this option
Sep 01 17:25:54 <denkenz> holtmann: when you're around lets discuss some things
Sep 01 18:02:17 <holtmann> denkenz: Okay. I am here now.
Sep 01 18:18:09 <denkenz> holtmann: Lets discuss quirks
Sep 01 18:18:38 <denkenz> holtmann: Do we want to use a single 32 bit flag per driver?
Sep 01 18:19:06 <denkenz> something like ofono_foo_create(modem, "foo", flags)?
Sep 01 18:19:32 <holtmann> So we wanna use a generic quirks things or just some random pointer that can be used for whatever?
Sep 01 18:19:45 <holtmann> Even just hand over a struct of some sort.
Sep 01 18:20:05 <denkenz> Handing structs around is a bit tricky, since it needs common declarations
Sep 01 18:20:27 <denkenz> We hand around GAtChat as userdata today
Sep 01 18:20:30 <holtmann> No it doesn't. Just void * and it could depend on the driver name.
Sep 01 18:20:50 <denkenz> Yeah, but declaration still needs to be accessible
Sep 01 18:20:59 <holtmann> The GAtChat as userdata is also wrong btw.
Sep 01 18:21:34 <denkenz> What do you feel it should be?
Sep 01 18:22:20 <holtmann> I think the modem function should just provide a function to get a reference of the GAtChat that is in use.
Sep 01 18:22:50 <denkenz> Actually, the reason I pass GAtChat is that once we have multiplexer
Sep 01 18:22:57 <holtmann> Instead of overloading userdata. Also then probe() callback can create is own userdata and use it.
Sep 01 18:23:08 <denkenz> We can have the modem driver control the multiplexer channels, and hand the proper chat instance to the atom driver
Sep 01 18:23:34 <denkenz> Besides, probe() is still free to change userdata to its own struct
Sep 01 18:24:16 <denkenz> e.g. sms driver does this
Sep 01 18:24:41 <holtmann> This will cause issues. So probe() assumption should be that it gets called with an empty userdata and on remove it only has to free it.
Sep 01 18:26:09 <denkenz> the assumption is that whatever gets passed in userdata prior to probe is not owned by the atom driver
Sep 01 18:26:34 <holtmann> So what I am thinking right now is that we should add another parameter to _create() and just do void *. And depending on which modem driver is used, it is either GAtChat or some GISI stuff.
Sep 01 18:27:02 <denkenz> How is this different from what it is today?
Sep 01 18:27:17 <holtmann> You can not make that assumption. It breaks the assumption everybody has about such a driver model.
Sep 01 18:27:55 <denkenz> struct ofono_sms *ofono_sms_create(struct ofono_modem *modem,
Sep 01 18:27:56 <denkenz>                                         const char *driver, void *data);
Sep 01 18:28:00 <holtmann> I prefer to do this via an extra parameter via probe() and of course then create(). This makes it more cleaner than overloading the userdata of a driver.
Sep 01 18:28:24 <denkenz> Ok, so that is a valid argument
Sep 01 18:28:55 <denkenz> And I'm willing to do that, but that still isn't handling quirks
Sep 01 18:29:41 <holtmann> And since the void *data is specific to one driver or group of drivers, we could even include quirks in there.
Sep 01 18:30:09 <holtmann> So struct atmodem_data { GAtChat *chat; unsigned long flags; };
Sep 01 18:30:32 <holtmann> And of course ISI would do something they need.
Sep 01 18:30:35 <denkenz> Then we need to keep that struct definition around, and even potentially install it
Sep 01 18:30:43 <denkenz> E.g. a separate header
Sep 01 18:30:50 <denkenz> Are you sure that is a good idea?
Sep 01 18:31:06 <holtmann> No. We just have to have it available for the drivers itself. And just link them correctly together.
Sep 01 18:31:26 <denkenz> What about external drivers using generic_at drivers?
Sep 01 18:31:43 <holtmann> While in theory possible, I don't wanna encourage them :)
Sep 01 18:31:54 <holtmann> Get it merged into ofono.git :)
Sep 01 18:32:24 <denkenz> While I sorta agree, I think thats not a good idea
Sep 01 18:32:36 <denkenz> Sometimes its useful to do development out-of-tree
Sep 01 18:33:16 <denkenz> It also means we potentially have a header for every driver
Sep 01 18:34:58 <holtmann> Actually the development inside the tree is way simpler than out of tree.
Sep 01 18:35:37 <denkenz> for me & you sure, for others...
Sep 01 18:35:47 <holtmann> I would just go without exporting the header. And then see how far we get. If it gets too complicated, then we fix it. The API is still not stable.
Sep 01 18:37:15 <holtmann> Using void *data as an extra input for create() gives us the flexibility. And since we then also hand that one to probe() then we have something really flexible.
Sep 01 18:37:53 <denkenz> Sure, but I don't like the requirement for struct definitions
Sep 01 18:38:02 <denkenz> Wouldn't it be better to pass an argument string?
Sep 01 18:38:41 <holtmann> Actually if you wanna add an extra char *quirks, I would't object to that.
Sep 01 18:39:35 <holtmann> However for the compiler sake and detecting of wrong quirks via gcc warnings. I would prefer an unsigned long.
Sep 01 18:40:18 <denkenz> ?
Sep 01 18:40:20 <holtmann> And to avoid the 32 limit on 32-bit systems, just have separate list of quirks for each group/atom.
Sep 01 18:40:53 <holtmann> Hunting bugs with unknown or wrong quirks is easier with the compiler telling us instead of human string comparision :)
Sep 01 18:43:03 <denkenz> so ofono_foo_create(modem, "driver", data, flags)?
Sep 01 18:43:57 <holtmann> Yep. The other possibility would be just an enum or int with a global vendor quirk id. So say SMS_ANDROID_HTC_FUCKUP. And then the driver translates that to "subquirks".
Sep 01 18:45:09 <holtmann> And since it is not a bitmask, you are free to quite a lot of different vendor fuckups.
Sep 01 18:46:44 <denkenz> yeah, i was thinking splitting the flags into 16 bit vendor id and 16 bit bitmap
Sep 01 18:57:06 <holtmann> Just using the vendor might be enough.
Sep 01 18:57:26 <holtmann> Having something like _ANDROID_1 and _ANDROID_2 should be not a problem either.
Sep 01 18:57:34 <denkenz> might be, but I'm worried about firmware revisions
Sep 01 18:57:54 <denkenz> Do we really want a device ID for each one?
Sep 01 18:58:00 <holtmann> _ANDROID_1_FW1 and _ANDROID_1_FW2
Sep 01 18:58:11 <holtmann> Yep. I think so.
Sep 01 18:58:42 <denkenz> hmm, ok, sounds fine
Sep 01 18:58:51 <holtmann> We can still do more quirk handling inside the driver itself. As far as I understand, we need basic handling of telling the driver what's the hardware.
Sep 01 18:59:13 <holtmann> And again, if it totally fails, then we change the API.
Sep 01 18:59:29 <denkenz> So you're saying we should have a modem vendor flag and a bitmap quirk?
Sep 01 18:59:37 <denkenz> Or am I not understanding
Sep 01 18:59:52 <holtmann> No. Only the vendor id (not a flag.
Sep 01 19:00:18 <denkenz> ok, so ofono_foo_create(modem, "driver name", data, vendor_id)
Sep 01 19:00:29 <holtmann> So we just define the vendor ids. And then have the driver to translate it internally to quirks that might need to be used.
Sep 01 19:00:31 <denkenz> and each probe gets changed to -> .probe(foo, data)
Sep 01 19:01:07 <holtmann> Yep. For consistency, I would do create(modem, vendor, driver name, data).
Sep 01 19:01:31 <holtmann> These user_data parameters should be always last (except for some destory notifier). Just some style issue.
Sep 01 19:01:44 <denkenz> sure thing
Sep 01 19:01:55 <denkenz> Ok, then the only thing we need is a global vendor enum
Sep 01 19:01:56 <holtmann> And since they are driver specific they should follow the driver name.
Sep 01 19:02:03 <holtmann> Yep.
Sep 01 19:02:12 <holtmann> Just make sure GENERIC = 0 :)
Sep 01 19:02:34 <denkenz> where do we wanna stick the vendor enum definition?
Sep 01 19:02:48 <denkenz> drivers/atmodem/vendors.h?
Sep 01 19:02:49 <holtmann> include/vendor.h :)
Sep 01 19:03:07 <denkenz> So would these be global across isi & at ?
Sep 01 19:03:39 <holtmann> In theory they could be specific to each driver. Would it help us not making them global?
Sep 01 19:04:21 <holtmann> Either way is fine actually. Maybe starting with drivers/atmodem/vendor.h would be better. Moving them to global later would be simple.
Sep 01 19:04:25 <denkenz> arguable, I'm mostly not wanting to maintain multiple enums
Sep 01 19:05:07 <denkenz> ok, then lets put it in drivers/atmodem/vendor.h first
Sep 01 19:05:13 <holtmann> Toss a coin :)
Sep 01 19:05:31 <denkenz> OFONO_VENDOR_GENERIC = 0
Sep 01 19:05:36 <denkenz> OFONO_VENDOR_FOO = foo
Sep 01 19:05:40 <denkenz> etc, ?
Sep 01 19:06:12 <holtmann> Yep.
Sep 01 19:06:28 <denkenz> ok, sounds good
Sep 01 19:06:49 <denkenz> you wanna discuss gprs now?
Sep 01 19:10:27 <holtmann> Sure.
Sep 01 19:11:05 <denkenz> have you looked at the overly complex api I sent and what was proposed on the ML?
Sep 01 19:11:14 <denkenz> (Btw, mine is overly complex on purpose ;)
Sep 01 19:14:10 <holtmann> I just looked at the one on the ML. I saw the other one from our french guys. Which is the one from you?
Sep 01 19:14:56 <denkenz> I sent it to your private email
Sep 01 19:15:11 <denkenz> btw, I didn't look at the french one yet
Sep 01 19:19:29 <holtmann> Okay. Now I remember.
Sep 01 19:20:12 <holtmann> So question is do we wanna combine data calls and GPRS/PDP context into one API? Can we have incoming PDP context establishments from the network as initiator.
Sep 01 19:20:45 <holtmann> I know we need the data calls for video conference stuff, but that is total different story. And a VideoCall API might be better suited anyway.
Sep 01 19:21:16 <denkenz> Ok, so imo we should have a separate DataCallManager or whatever
Sep 01 19:21:22 <denkenz> lets make GPRS only do GPRS
Sep 01 19:22:03 <denkenz> The standard defines a way for the network to establish an incoming PDP context
Sep 01 19:22:18 <denkenz> So even if we don't handle this initially, lets bake it into our assumptions
Sep 01 19:24:31 <holtmann> So I like to have a PDP context setup and an D-Bus object per context.
Sep 01 19:25:11 <holtmann> We also need a type for each context. So things like ConnMan can tell what they are for. For example internet, mms or whatever.
Sep 01 19:25:42 <denkenz> Agreed, but is there a way to tell?
Sep 01 19:25:53 <holtmann> It is setup detail.
Sep 01 19:26:05 <denkenz> not for incoming
Sep 01 19:26:17 <holtmann> It needs human or provisioning information.
Sep 01 19:26:32 <denkenz> IMS does weird things where it can request incoming PDP contexts for voip calls AFAIK
Sep 01 19:26:52 <denkenz> Not that we're that far yet
Sep 01 19:26:55 <holtmann> For the incoming we might be in serious trouble. However do we get the APN via the incoming setup request?
Sep 01 19:27:09 <denkenz> its tricky actually
Sep 01 19:27:14 <denkenz> it can be an existing context
Sep 01 19:27:17 <denkenz> or a brand new one
Sep 01 19:27:21 <denkenz> we don't know until it is established
Sep 01 19:27:38 <holtmann> In an existing one, we could just match it to what is setup. In case of the new one reject it :)
Sep 01 19:28:02 <denkenz> problem is, we don't know which one it is :)
Sep 01 19:28:06 <denkenz> Until we answer
Sep 01 19:28:10 <holtmann> Or just assume that all incoming ones are special and type=incoming :)
Sep 01 19:28:21 <ipuustin> Hi, I wrote the GPRS patch that was today on the mailing list. Do you mean SIM ATK support for network-initiated connections?
Sep 01 19:29:06 <denkenz> I mean things like +CGANS and +CGAUTO
Sep 01 19:29:11 <holtmann> So my problem is that ConnMan needs a way of telling which one gives you an Internet connection (meaning default gateway can be chosen) and which ones are just "service" contexts for MMS etc.
Sep 01 19:29:15 <denkenz> where a PDP context can be incoming from the network side
Sep 01 19:29:41 <denkenz> So I think for ones we setup locally
Sep 01 19:29:48 <holtmann> Lets just assume type=incoming for these and move on.
Sep 01 19:29:49 <denkenz> That isn't the issue, we should be able to accomodate you
Sep 01 19:29:55 <denkenz> nod
Sep 01 19:30:50 <denkenz> ipuustin: Join the discussion btw ;)
Sep 01 19:31:13 <denkenz> Ok, so in my proposed API we have object CreateContext()
Sep 01 19:31:31 <ipuustin> denkenz: Happy to. :-) The provisioning issue will be tricky though, but at least for the user-generated connection requests it can be kept separate from the connection logic.
Sep 01 19:32:08 <holtmann> denkenz: And I don't wanna have different interfaces for primary and secondary. That should just be a property.
Sep 01 19:32:27 <denkenz> holtmann: Actually they're different enough
Sep 01 19:32:38 <denkenz> ipuustin: Nod, some of this can be read from the SIM though 
Sep 01 19:33:01 <denkenz> holtmann: For instance, secondary doesn't have an APN, it reuses one from primary
Sep 01 19:33:30 <holtmann> How is that suppose to be working and who uses that? And what it is good for?
Sep 01 19:34:29 <denkenz> holtmann: Its freaking stupid, but from what I understand secondary contexts have different QoS parameters
Sep 01 19:34:52 <ipuustin> denkenz: That's what I remember also.
Sep 01 19:34:54 <denkenz> holtmann: And you can define a traffic filter to say, these packets go to the secondary context
Sep 01 19:35:18 <denkenz> holtmann: As far as use, I've no idea, probably different type of Voice channels
Sep 01 19:35:25 <denkenz> holtmann: or even MMS vs internet
Sep 01 19:35:58 <holtmann> Without the APN, how do you tell which one is which?
Sep 01 19:36:12 <denkenz> different multiplexer channels
Sep 01 19:36:13 <holtmann> Do we have Third, Forth etc. contexts?
Sep 01 19:36:26 <denkenz> nope, you can have N primary contexts
Sep 01 19:36:32 <denkenz> each primary context can have M secondary contexts
Sep 01 19:36:53 <denkenz> standard defines that 11 contexts can be active at once
Sep 01 19:36:56 <holtmann> I see. So it is sub-context.
Sep 01 19:37:00 <denkenz> yep
Sep 01 19:37:39 <denkenz> for right now, I say we don't worry about them, other than to see how they fit in
Sep 01 19:37:48 <denkenz> to allow future extension
Sep 01 19:37:50 <holtmann> Then we should represent it like this. We need setup method for (primary) contexts. And then just define the (secondary/sub) contexts within it.
Sep 01 19:38:14 <holtmann> I still don't understand how you tell to establish a secondary context.
Sep 01 19:38:35 <denkenz> You run it on a different multiplexer channel and enter into data state
Sep 01 19:38:44 <denkenz> You setup the traffic filter + QoS parameters first
Sep 01 19:39:55 <holtmann> And how would that work with an ISI modem for example.
Sep 01 19:40:07 <denkenz> good question :)
Sep 01 19:41:12 <denkenz> holtmann, ipuustin: http://pastebin.ca/1550681 is my proposal btw
Sep 01 19:41:15 <holtmann> And then the obvious question. Is anybody actually using this. Or do they really mean 1st primary context, 2nd primary context, when they talk about primary/secondary context. Since that is what I was assuming.
Sep 01 19:41:30 <denkenz> nope, the standard is quite clear on this
Sep 01 19:41:36 <denkenz> you can have multiple primary contexts
Sep 01 19:42:28 <denkenz> it all boils down to probably an internet and an mms primary contexts
Sep 01 19:42:42 <denkenz> no secondary or any of this crap
Sep 01 19:43:03 <ipuustin> holtmann: ISI modems do have support for secondary contexts and separate QoS settings. However, I did not look into that when I was thinking about the API and the ISI driver. I kind of assumed that those are not the key GPRS features. :-)
Sep 01 19:43:18 <holtmann> So then lets go with this assumption. We try to accommodate a list of primary contexts.
Sep 01 19:43:36 <holtmann> If real secondary context needs come our way, we revisit this.
Sep 01 19:44:04 <ipuustin> denkenz: The three APNs that operators usually appear to have are internet, MMS and WAP. I don't know if anyone uses the WAP services anymore, though.
Sep 01 19:44:55 <denkenz> holtmann: So the aim is to at least consider secondary contexts, so we don't have to redo the API later
Sep 01 19:44:58 <holtmann> I have talked to some vendor and they have some sort of push notification APN with special roaming agreements. Similar to what blackberry does.
Sep 01 19:45:48 <holtmann> I would just assume that a secondary/sub/child context hangs of the primary context. So it will be a child object.
Sep 01 19:46:23 <denkenz> yep
Sep 01 19:46:40 <ipuustin> The proposal in the pastebin looks remarkably the same that I had in mind. However, shouldn't the registration status be more of a general network services issue?
Sep 01 19:47:05 <denkenz> gprs registration is different from csd registration
Sep 01 19:47:39 <denkenz> It really belongs in its own interface
Sep 01 19:47:52 <ipuustin> The biggest differences appear to be the secondary PDP contexts and network-initiated connections, just as discussed here.
Sep 01 19:48:20 <holtmann> We do have roaming where we don't wanna keep the context attached.
Sep 01 19:49:00 <holtmann> If chosen to not have data roaming.
Sep 01 19:49:07 <courmisch> I guess IMS will be a forth primary, if and when it happens
Sep 01 19:49:18 <holtmann> IMS?
Sep 01 19:49:23 <ipuustin> denkenz: I see. So some values (Cell ID etc.) are duplicated on the different D-Bus interfaces?
Sep 01 19:49:30 <courmisch> I mean the context for your 3GPP SIP interface
Sep 01 19:49:41 <holtmann> If that happens :)
Sep 01 19:49:43 <courmisch> in 4G
Sep 01 19:49:56 <denkenz> ipuustin: Actually the GPRS registration cell can be different from CSD cell
Sep 01 19:50:05 <courmisch> it would be too simple and easy if it were the Internet APN
Sep 01 19:50:20 <denkenz> holtmann: IMS is basically VoIP calls over 3G/3.5G
Sep 01 19:50:53 <courmisch> IMS is basically a bastardized dialect of SIP over GPRS
Sep 01 19:51:04 <denkenz> holtmann: Its sort of evolution tech
Sep 01 19:51:29 <courmisch> roaming between 3G/CS and 4G/SIP during a phone call
Sep 01 19:51:33 <courmisch> that will be a lot of fun
Sep 01 19:51:35 <denkenz> ipuustin: Even GPRS tech can be different than CSD tech
Sep 01 19:51:58 <denkenz> courmisch: Yeah, oFono will probably do that in 2015 ;)
Sep 01 19:51:59 <holtmann> So real question is if we wanna do any automatic attach etc. in oFono or just leave this up to ConnMan.
Sep 01 19:52:35 <courmisch> leave it to ConnMan. More bugs for Patrick Flykt team and less for us ahaha
Sep 01 19:53:00 <denkenz> Does connman have any idea about GPRS Attach state?
Sep 01 19:53:02 <holtmann> Works from your point of view, but not from mine. I have to take care of both anyway.
Sep 01 19:53:10 <denkenz> since you can be attached but not active
Sep 01 19:53:24 <courmisch> you can be attached but not connected indeed
Sep 01 19:53:26 <holtmann> So GPRS attach would translate to enabled/powered on.
Sep 01 19:53:35 <courmisch> but what's the point in doing this automatically?
Sep 01 19:53:45 <denkenz> It isn't per APN though
Sep 01 19:53:52 <denkenz> Its a global attach / detach
Sep 01 19:53:54 <courmisch> yeah that sucks if you need to support MMS
Sep 01 19:54:00 <courmisch> ah?
Sep 01 19:54:29 <courmisch> well I dunno, does it add to power consumption or network operating cost?
Sep 01 19:54:32 <denkenz> +CGATT=1 or +CGATT=0 controls the global attach state AFAIK
Sep 01 19:54:36 <holtmann> So the general consent is that if roaming=true you wanna be always attached, if roaming=false then not even attach.
Sep 01 19:54:45 <denkenz> Which tells the network GPRS is enabled on this device
Sep 01 19:54:58 <holtmann> And yes, it costs power to keep it attached.
Sep 01 19:55:46 <holtmann> So currently I am thinking that we should auto-attach based on a global "data roaming allowed" property.
Sep 01 19:56:06 <holtmann> And not expose this via any D-Bus call.
Sep 01 19:56:28 <denkenz> How would connman know when we're attached?
Sep 01 19:56:44 <courmisch> we've seen issues in dual-SIM cases
Sep 01 19:56:45 <denkenz> since attach state is not instantenous
Sep 01 19:56:53 <holtmann> It is actually a speed concern on how quickly we can connect / re-connect.
Sep 01 19:57:11 <ipuustin> holtmann: why not have a way to attach manually if needed? connection creation attaches implicitly anyway.
Sep 01 19:57:17 <holtmann> And for ConnMan we have to export something like GPRSAvailable or os.
Sep 01 19:57:41 <denkenz> connman can simply use the Attached property
Sep 01 19:57:47 <courmisch> if it consumes power, it says "manual" IMHO
Sep 01 19:57:54 <holtmann> ipuustin: See above. We really wanna be attached to quickly connect/disconnect.
Sep 01 19:57:55 <ipuustin> holtmann: the auto-attach is a very likely operator requirement or a user setting.
Sep 01 19:58:03 <courmisch> e.g. there is no point in being attached if you have Wifi connectivity
Sep 01 19:58:36 <holtmann> There is actually. If we detach, then the re-connect takes longer if we loose WiFi or have to send a MMS.
Sep 01 19:59:14 <denkenz> I say have your "roaming" property map to "Attached" property on GPRS interface
Sep 01 19:59:27 <denkenz> then simply have GPRS interface refuse any connections if Attached is false
Sep 01 19:59:29 <holtmann> However there is another argument. ConnMan might not control all contexts. And since attach is global, we wanna attach for other reasons.
Sep 01 20:00:31 <denkenz> worst case it'll require two method calls for some application instead of one
Sep 01 20:00:33 <holtmann> We can add auto-attach and auto-detach with a timeout etc. So do this in the background the smart way without ever telling anyone.
Sep 01 20:01:00 <courmisch> I am not sure we want hard-coded policies in Ofono...
Sep 01 20:01:01 <holtmann> From a ConnMan point of view. I care about Connect/Disconnect. The attach details is unimportant for me.
Sep 01 20:01:29 <denkenz> I don't really see this as hard coding anything
Sep 01 20:01:38 <denkenz> Attached controls the global use of GPRS, on or off
Sep 01 20:01:43 <holtmann> If it is global anyway, there is nothing much we can do. Exposing attach state via D-Bus is stupid then.
Sep 01 20:02:20 <denkenz> Not really, lets say I don't ever want to use GPRS
Sep 01 20:02:34 <holtmann> And of course we can have attach on demand or always attach etc. via a config option. It is an integrator decision anyway.
Sep 01 20:03:01 <holtmann> Having something like GPRS=off is of course something we wanna have.
Sep 01 20:04:17 <holtmann> So per modem we have to expose GPRS=on/off RoamingAllowed=yes/no Ready=yes/no.
Sep 01 20:04:35 <denkenz> Ugh
Sep 01 20:04:43 <denkenz> Can't we just use Attached property? :)
Sep 01 20:05:12 <denkenz> At least for Ready/on off parts
Sep 01 20:05:30 <holtmann> Calling it Attached is fine too.
Sep 01 20:05:50 <holtmann> DataRoamingAllowed might be also a better name :)
Sep 01 20:06:20 <denkenz> Actually we probably should have Attached and RoamingAllowed
Sep 01 20:06:53 <holtmann> There is a difference between VoiceRoamingAllowed and DataRoamingAllowed.
Sep 01 20:07:08 <holtmann> And we are talking of having these part of the Modem interface.
Sep 01 20:07:11 <denkenz> Yes, so both of these will be on the main GPRS manager interface
Sep 01 20:07:20 <denkenz> you sure?
Sep 01 20:07:53 <holtmann> Not 100%. Open for suggestions.
Sep 01 20:08:13 <holtmann> Since GPRS attach state is a global per modem value, I would say so.
Sep 01 20:08:31 <denkenz> Problem is, I don't want this property on devices that don't support it
Sep 01 20:08:47 <denkenz> And I don't want the mess of communicating between modem and the gprs atom
Sep 01 20:08:54 <denkenz> for something like attached
Sep 01 20:09:00 <holtmann> Okay. Fair enough.
Sep 01 20:09:09 <denkenz> I can see Voice/Data roaming as being preferences on the Modem though
Sep 01 20:09:28 <holtmann> Then GPRSManager.Powered GPRSManager.RoamingAllowed GPRSManager.Attached is what you want.
Sep 01 20:09:46 <denkenz> Why bother with Powered?
Sep 01 20:09:56 <denkenz> There's no way to control this in 27.007 anyway
Sep 01 20:10:09 <holtmann> You wanna use Attached = Powered and make it read-write.
Sep 01 20:10:16 <ipuustin> Shouldn't Attach and Detach be preferably method calls, since those operations can possibly take a long time and also fail? (Of course setting the property can be also made to fail, but I think that is not a common pattern.)
Sep 01 20:10:37 <denkenz> ipuustin: Actually it is, Modem interface already does this
Sep 01 20:10:50 <denkenz> holtmann: I say we just use Attached and RoamingAllowed on GPRSManager
Sep 01 20:11:10 <holtmann> Problem is that Chaning RoamingAllowed=false and if roaming should trigger detach.
Sep 01 20:11:20 <holtmann> s/Chaning/changing/
Sep 01 20:11:27 <denkenz> holtmann: That isn't a problem
Sep 01 20:11:34 <denkenz> holtmann: the gprs manager has the registration state 
Sep 01 20:11:50 <holtmann> Don't expose details that are totally useless for any UI or ConnMan.
Sep 01 20:12:01 <denkenz> holtmann: Remember, gprs has a separate registration info
Sep 01 20:12:16 <holtmann> Which is fine, but why would we care?
Sep 01 20:12:28 <denkenz> holtmann: Because you want to know EDGE vs 3G
Sep 01 20:12:58 <holtmann> And besides that? We can just expose the current technology, but the rest is just pointless. Isn't it?
Sep 01 20:13:10 <denkenz> holtmann: Arguable
Sep 01 20:13:24 <holtmann> As I said, we should just auto-attach and report the current technology.
Sep 01 20:13:59 <denkenz> holtmann: Anyone know if you can obtain the gprs registration state without attaching?
Sep 01 20:14:19 <holtmann> If not attached, we don't care. Do we?
Sep 01 20:14:30 <denkenz> holtmann: How do we know if we're roaming or not?
Sep 01 20:15:17 <holtmann> Okay. So that should be possible.
Sep 01 20:15:33 <holtmann> We could steal the roaming state from the voice part :)
Sep 01 20:16:03 <holtmann> Even if voice could be roaming and data could not at this moment. Still unlikely :)
Sep 01 20:16:12 <denkenz> holtmann: 10.1.20	GPRS network registration status +CGREG
Sep 01 20:16:21 <denkenz> holtmann: You can't rely on the voice part
Sep 01 20:17:28 <holtmann> So we know about roaming state from CGREG.
Sep 01 20:18:48 <denkenz> yes, which is why I say handle RoamingAllowed inside GPRS manager
Sep 01 20:18:55 <denkenz> It knows when we're roaming or not
Sep 01 20:19:01 <denkenz> And CGREG also reports tech information
Sep 01 20:19:09 <denkenz> Whether we should expose CellID / LAC is arguable
Sep 01 20:19:18 <denkenz> But why not
Sep 01 20:19:21 <holtmann> Good. So we can auto-attach and everything based on RoamingAllowed.
Sep 01 20:19:31 <denkenz> yep
Sep 01 20:20:03 <denkenz> unless the user explicitly turned off Attached
Sep 01 20:20:07 <holtmann> So I would make Attached read-only and then Powered  read-write to give ConnMan the chance to disable GPRS while still keeping voice stuff enabled.
Sep 01 20:20:22 <holtmann> So Attached is just purely informational.
Sep 01 20:20:47 <denkenz> That sounds fine, lets make it Enabled and not Powered
Sep 01 20:20:52 <holtmann> Then we can make CGREG to Powered and CGATT to Attached.
Sep 01 20:21:16 <denkenz> no, CGREG doesn't allow you to control registration state
Sep 01 20:21:17 <holtmann> I prefer Powered since we use that everywhere else accross Bluetooth and ConnMan, but either way would be fine.
Sep 01 20:21:30 <denkenz> ok, fair enough
Sep 01 20:21:32 <ipuustin> There is a third connectivity state, which is "Suspended". The modem reports that the connection is temporarily not available. Happens to me in trains...
Sep 01 20:21:48 <denkenz> That's a context state, no?
Sep 01 20:22:16 <ipuustin> denkenz: Looks like that that is a global state.
Sep 01 20:23:00 <ipuustin> denkenz: Also happens during phone calls in 2G networks.
Sep 01 20:23:04 <holtmann> Do we have to expose that to the UI/ConnMan?
Sep 01 20:23:25 <holtmann> If something bad happens, we can just signal disconnect of the context and Attached=false.
Sep 01 20:23:39 <denkenz> Ok, so there are events that can signal that network has forced a detach
Sep 01 20:23:45 <ipuustin> holtmann: Might be a good idea, since the UI might want to indicate that data is not available for a moment, and ConnMan might want to take actions if it lasts too long.
Sep 01 20:23:48 <holtmann> Question is what is the UI/ConnMan suppose to be doing when suspended state is reached.
Sep 01 20:23:50 <denkenz> So we simply disconnect all contexts and signal attached false
Sep 01 20:24:11 <holtmann> And we can do that with a timeout internally.
Sep 01 20:24:42 <denkenz> no, once this is reported they're all off
Sep 01 20:24:43 <holtmann> ipuustin: We wanna have less complexity inside UI/ConnMan. If it is of no benefit for the UI or we can handle it internally, then we should not expose it.
Sep 01 20:25:04 <ipuustin> holtmann: To me it looks that this is hardcoding policy to Ofono 
Sep 01 20:25:21 <ipuustin> , but then again it might be a good idea...
Sep 01 20:26:11 <denkenz> ipuustin: oFono is not setting policy, it is just reporting what's happening
Sep 01 20:27:01 <holtmann> The GSM specs have so much details. We really need to question if some states need to be exposed. Just blindly exposing all GSM states etc. leads to the FreeSmartPhone mess. Too complex API that nobody can use and have to duplicate code in the UI.
Sep 01 20:27:02 <ipuustin> denkenz: Ok. Of course there are internal timeouts in ofono, but I was just thinking of the poor UI people who like to specify timeouts in spesification documents. :-)
Sep 01 20:28:03 <denkenz> holtmann: True, as a general comment 
Sep 01 20:28:12 <denkenz> ipuustin: There are very few internal timeouts actually
Sep 01 20:28:33 <denkenz> ipuustin: I can think of only one right now :P
Sep 01 20:29:51 <ipuustin> holtmann: I just kind of liked the Detached - Attached - Suspeded three-state variable in my GPRS API proposal. ;-)
Sep 01 20:31:10 <holtmann> I don't like it. Too complicated. Since there is no clear definitions on what to do on suspended. That is a problem. Attached=yes/no is clear what is going on.
Sep 01 20:31:31 <holtmann> These tri-states are always complicated for no good of the UI.
Sep 01 20:31:59 <denkenz> not to mention the fact that this doesn't exist in the standard
Sep 01 20:32:12 <denkenz> and 27.007 is what we use
Sep 01 20:38:33 <denkenz> http://pastebin.ca/1550763 updates with Powered, Attached, RoamingAllowed properties
Sep 01 20:38:58 <denkenz> holtmann: Another thing from connman perspective, should we expose DNS1/DNS2/IP as properties
Sep 01 20:39:06 <denkenz> holtmann: or simply set them on the interface?
Sep 01 20:39:16 <denkenz> holtmann: no one except connman will care anyway
Sep 01 20:39:42 <denkenz> holtmann: interface in this context being ppp0, etc
Sep 01 20:42:22 <ipuustin> denkenz: Does the pastebin proposal have a bit complicated connection procedure? Creating a connection, setting the properties, activating it...
Sep 01 20:42:55 <denkenz> ipuustin: Commens welcome, the idea here is that you simply create one, then you can change details later on
Sep 01 20:43:10 <denkenz> e.g. if you need to change the APN, instead of delete, create you simply setProperty
Sep 01 20:43:27 <denkenz> It also implies that your settings are stored by oFono and persist
Sep 01 20:43:38 <denkenz> so you can have many contexts defined
Sep 01 20:43:48 <ipuustin> denkenz: I'm not sure if you can connect a disconnected context again.
Sep 01 20:45:09 <denkenz> it should be able to, since the context id persists
Sep 01 20:45:20 <denkenz> I could be wrong though
Sep 01 20:45:31 <ipuustin> denkenz: Having the intermediate property setting phase let's you have a number of different rare use cases though, such as requesting a fixed IP address from the network.
Sep 01 20:46:13 <ipuustin> denkenz: I just vaguely remember reading that at least for the Nokia modems reusing a context was not possible. I don't claim that it is that way, though!
Sep 01 20:46:44 <denkenz> ipuustin: We can get around that by always sending all context details to the gprs driver
Sep 01 20:46:59 <denkenz> ipuustin: There's nothing preventing us from persisting the context details in the core though
Sep 01 20:47:45 <denkenz> Similar to how your Wifi profiles are persisted
Sep 01 20:47:52 <ipuustin> denkenz: Sure, but we just need to be careful to not let the driver get out of sync with the atom at that point.
Sep 01 20:49:03 <denkenz> ipuustin: The most important part is for the driver to tell oFono when it has been deactivated
Sep 01 20:49:13 <denkenz> ipuustin: I don't see any other gotchas
Sep 01 20:50:56 <denkenz> ipuustin: Btw, +CGDCONT has a query function, which means the standard intended for context definitions to be persistent
Sep 01 20:51:40 <holtmann> denkenz: About the IP. Setting IP address, netmask etc. is fine to do that via oFono. However DNS and default gateway are ConnMan's job.
Sep 01 20:52:28 <denkenz> holtmann: So you want to have Primary/Secondary domain name attributes?
Sep 01 20:52:44 <holtmann> So about the context itself. So in theory we need an option to create/modify one via either a UI or via ConnMan. Also the second is the pre-provisioned contexts.
Sep 01 20:53:05 <holtmann> No. Just a arrary{string} of DNS servers.
Sep 01 20:53:12 <holtmann> Some actually give more than two.
Sep 01 20:53:53 <denkenz> holtmann: So you lost me on the pre-provisioned contexts bit
Sep 01 20:54:23 <holtmann> On some phone a context would come from a config file instead of created via CreateContext.
Sep 01 20:54:55 <holtmann> Like T-Mobile/Vodafone etc. wanna ship their phones with proper contexts set up.
Sep 01 20:55:47 <denkenz> holtmann: Sure, we can accomodate that, since any context created by CreateContext will be serialized in/out by oFono
Sep 01 20:56:02 <denkenz> holtmann: So we'll take care of maintaining them over reboots
Sep 01 20:56:15 <denkenz> holtmann: And can even store them by IMSI
Sep 01 20:56:20 <holtmann> Yep. And some just come from vendor config files :)
Sep 01 20:56:26 <denkenz> holtmann: nod
Sep 01 20:57:00 <denkenz> holtmann: So DNS property added to PrimaryContext: 
Sep 01 20:57:01 <denkenz>                 array{string} DomainNameServers [readonly, optional]
Sep 01 20:57:03 <denkenz>                         Holds the list of domain name servers for this 
Sep 01 20:57:06 <denkenz>                         context.
Sep 01 20:57:39 <ipuustin> Hmm, having ofono actually have persistent access points is a good-sounding idea.
Sep 01 20:58:21 <ipuustin> (The IMSI would be required, though, since after changing a SIM card the old contexts would not be operational any more.)
Sep 01 20:58:40 <denkenz> yes, everything in oFono is stored by IMSI
Sep 01 20:58:57 <denkenz> we can simply add a quick script to bootstrap operator provided settings
Sep 01 20:59:05 <denkenz> or read them from the SIM if available
Sep 01 21:00:35 <denkenz> The only other things my proposal differs with the onefrom Ismo is the tx/rx/uptime statistics
Sep 01 21:00:46 <denkenz> Those really belong in the kernel I feel
Sep 01 21:01:10 <holtmann> Yep. We can read them from the network interface.
Sep 01 21:01:51 <holtmann> And that should be up to ConnMan :)
Sep 01 21:02:05 <denkenz> nod.  What about pap/chap authentication bs?
Sep 01 21:02:15 <denkenz> e.g. username / password
Sep 01 21:02:19 <ipuustin> But can you read them if the network terminates the connection, prompting kernel driver to destroy the interface?
Sep 01 21:03:35 <denkenz> valid point, but this reallyd doesn't belong in oFono 
Sep 01 21:04:01 <holtmann> We figure something out for that.
Sep 01 21:04:46 <ipuustin> denkenz: of course I'm bit biased, since I get from the modem connection statistics after a context is destroyed. :-)
Sep 01 21:05:09 <holtmann> So the username / password part is needed. Even for non-PPP hardware. I dislike it at, but that is how it is and one network in Germany actually requires it.
Sep 01 21:05:11 <denkenz> ipuustin: yah, buts others aren't so lucky
Sep 01 21:05:26 <denkenz> ipuustin: esp if ppp0, or foo0 is involved
Sep 01 21:05:56 <ipuustin> denkenz: Yes, you're right...
Sep 01 21:06:14 <denkenz> holtmann: Ok, so we add username/password to primary context
Sep 01 21:06:45 <denkenz> holtmann: Gah, this means we need actual security for our password files
Sep 01 21:07:30 <holtmann> No. We are not doing that non-sense. It is not worth protecting anyway. Most of these a public values with default details.
Sep 01 21:07:32 <ipuustin> denkenz: I think only CDMA uses real username/password pairs, since for GSM the operator always knows who you are.
Sep 01 21:07:55 <denkenz> holtmann: So simple plaintext attribute?
Sep 01 21:07:59 <holtmann> Networks that do it this way are just broken. They should do the authentication by IMSI and not some public username/password non-sense/.
Sep 01 21:08:12 <holtmann> Yep. See them similar to the APN value.
Sep 01 21:08:20 <denkenz> ok
Sep 01 21:09:13 <denkenz>                 string Username [readwrite]
Sep 01 21:09:15 <denkenz>                         Holds the username to be used for authentication 
Sep 01 21:09:17 <denkenz>                         purposes
Sep 01 21:09:18 <denkenz>                 string Password [readwrite]
Sep 01 21:09:19 <denkenz>                         Holds the password to be used for authentication 
Sep 01 21:09:21 <denkenz>                         purposes.
Sep 01 21:09:25 <holtmann> Yep.
Sep 01 21:09:26 <denkenz> Do we want auth type attribute of some sort?
Sep 01 21:09:43 <holtmann> Don't think we need it. If we do, then we add it later.
Sep 01 21:10:41 <denkenz> ok, anything else we didn't discuss?
Sep 01 21:12:36 <denkenz> we eventually need to discuss secondary contexts & traffic filter crap in detail
Sep 01 21:12:43 <denkenz> but I remove it from my API proposal for now
Sep 01 21:12:52 <denkenz> Until some product groups scream that is
Sep 01 21:13:37 <ipuustin> This has been a really interesting discussion. However, I need to go soon (it's past midnight here).
Sep 01 21:14:18 <ipuustin> So I hope to see the Pastebin proposal in the ML under scrutiny with reference material. :-)
Sep 01 21:14:30 <denkenz> yep, I'll send it out today
Sep 01 22:31:45 <dilinger> denkenz: hm.  so should the ofono_modem_create/ofono_modem_register code remain in the driver _init function, or should it also be in the enable callback?
Sep 01 22:32:17 <dilinger> my assumption is that it should be in the enable callback, but i'd like to verify that doing an ofono_modem_remove(modem) from the disable callback isn't going to cause explosions :)
Sep 01 22:32:45 <dilinger> sorry, i misspoke
Sep 01 22:32:46 <denkenz> dilinger: So modem_create just creates the object
Sep 01 22:32:59 <dilinger> from the probe and remove callbacks
Sep 01 22:32:59 <denkenz> dilinger: modem_register probes the driver and registers the interface
Sep 01 22:33:03 <dilinger> not disable and enable
Sep 01 22:33:57 <denkenz> dilinger: What you probably should do is open /dev/smd0, then call ofono_modem_create, & register
Sep 01 22:34:22 <denkenz> Simply keep /dev/smd0 open for the duration of the driver being loaded
Sep 01 22:34:31 <dilinger> okay
Sep 01 22:35:03 <denkenz> For you power up / down is done using CFUN, or maybe some htc specific command
Sep 01 22:35:09 <dilinger> yep
Sep 01 22:35:27 <denkenz> I assume the serial port can always be active
Sep 01 22:35:40 <denkenz> However, some devices can actually send ioctl that shuts off the serial port too (e.g. Neo)
Sep 01 22:38:28 <dilinger> actually, there's no need to open it; i can just stat
Sep 01 22:40:57 <denkenz> and open in probe
Sep 01 22:41:05 <denkenz> yes, you've infinite flexibility :)
Sep 01 22:58:29 <denkenz> holtmann: Do you want me to simply commit the api once we decide on the interface name?
Sep 01 23:03:23 <holtmann> Sure. Go ahead. Then we can easier fix it.
Sep 01 23:04:20 <denkenz> holtmann: ok, you still particular about GPRSManager?
Sep 01 23:04:46 <denkenz> holtmann: I'm open to suggestions, I just don't like GPRS in the name
Sep 01 23:05:43 <holtmann> Not really. Just asking here. Anyway I am off now.
Sep 01 23:06:02 <holtmann> Feel free to commit the API and then we go from there.
Sep 01 23:23:47 <denkenz> dilinger: The vendor quirk system has been pushed
Sep 01 23:24:21 <denkenz> dilinger: So lets get the g1 driver upstream in the next few days
Sep 01 23:26:23 <dilinger> denkenz: i just pushed an update to the first patch
Sep 01 23:26:48 <dilinger> http://git.collabora.co.uk/?p=user/dilinger/ofono-g1-new;a=commitdiff;h=f4bdd7292776edfc5aa81a45333fe197069e349f
Sep 01 23:27:13 <dilinger> i'll rebase and resubmit patches after i integrate the quirk stuff.  additional comments welcome, of course
Sep 01 23:28:03 <dilinger> or maybe http://git.collabora.co.uk/?p=user/dilinger/ofono-g1-new;a=blob;f=plugins/g1.c;h=ef86e17d7f46e61a0780e2e9aa6f4224ffc44293;hb=f4bdd7292776edfc5aa81a45333fe197069e349f  is easier to look at ;)
Sep 01 23:28:32 <denkenz> Ok, so I suggest you make a callback for cfun=1/0 and call set_powered from the callback
Sep 01 23:29:21 <denkenz> since cfun can actually fail
Sep 01 23:29:33 <denkenz> rest looks fine
Sep 01 23:30:21 <dilinger> okay
Sep 01 23:30:41 <dilinger> is the debug variable name okay?
Sep 01 23:30:45 <dilinger> OFONO_AT_DEBUG?
Sep 01 23:30:50 <dilinger> or should it be G1-specific?
Sep 01 23:31:17 <denkenz> dunno, doubt it really matters
Sep 01 23:31:49 <denkenz> leave it as OFONO_AT_DEBUG for now
Sep 01 23:36:13 <dilinger> k
Sep 01 23:36:17 <denkenz> and test if btw ;)
Sep 01 23:36:22 <denkenz> s/if/it/
Sep 01 23:36:22 * dilinger handwaves
Sep 01 23:36:36 <dilinger> i'm suuuuure it'll work.  it compiled, right? ;)
Sep 01 23:37:05 <denkenz> I'm sure it will, but test anyway ;)
Sep 02 00:22:15 <holtmann> denkenz: Can you use "unsigned long vendor" please. No point in having a signed int.
Sep 02 00:22:46 <holtmann> Or if you don't like the long, at least unsigned int.
Sep 02 00:33:28 <denkenz> holtmann: is there a difference for enums?
Sep 02 00:33:37 <denkenz> holtmann: But sure, I can do that
Sep 02 00:34:00 <holtmann> Not really, but I do wanna have the compiler warn me if something weird inside the code is used.
Sep 02 00:34:18 <holtmann> You could also use the enum type directly if we make vendor.h available globally.
Sep 02 00:35:09 <denkenz> holtmann: We can forward declare it
Sep 02 00:35:37 <holtmann> Sure. That should work. So either unsigned int, unsigned long or enum ofono_vendor :)
Sep 02 00:35:43 <holtmann> Your choice.
Sep 02 00:36:05 <denkenz> holtmann: ok, I'll try if forward declaration works and fix it
Sep 02 00:50:17 <dilinger> hm
Sep 02 00:50:17 <dilinger> g1.c:(.text+0x3f4): undefined reference to `ofono_modem_get_powered'
Sep 02 00:50:42 <dilinger> that function doesn't appear to be defined
Sep 02 00:58:17 <holtmann> Hah. Denis only included the prototype :)
Sep 02 01:16:06 <denkenz> why are we using that one?
Sep 02 01:18:09 <holtmann> Why is the prototype there and no implementation?
Sep 02 01:18:56 <denkenz> Cus I forgot :)
Sep 02 01:19:22 <denkenz> I still wonder why use it :)
Sep 02 01:19:49 <denkenz> fixed btw
Sep 02 01:35:29 <dilinger> denkenz: because i'm toggling power in the callback rather than having two separate callbacks
Sep 02 01:35:47 <denkenz> gah
Sep 02 01:36:21 <denkenz> saving 4 lines or something
Sep 02 01:36:27 <dilinger> http://git.collabora.co.uk/?p=user/dilinger/ofono-g1-new;a=commitdiff;h=acc0b6221b17afc0b2a06275c61f2e77cedf2bba
Sep 02 01:37:03 <dilinger> i was going to make that just a single callback function.  doesn't make sense to have multiple ones, and i see nothing wrong w/ toggling.  but i can also just leave it as is.
Sep 02 01:38:01 <denkenz> looks ok, does it work?
Sep 02 01:38:07 <dilinger> yep
Sep 02 01:40:43 <denkenz> cool, squash all your commits into g1.c and a change to the sms driver
Sep 02 01:42:48 <dilinger> yep.  i haven't looked at the quirk stuff yet, that's up next
Sep 02 01:44:58 <holtmann> denkenz: Btw. can you please not prefix variables with g_. Like in generic_at.c with g_modems thing. I prefer modem_list as variable in this case.
Sep 02 01:45:06 <holtmann> Makes it more clear what it is for.
Sep 02 01:46:05 <denkenz> heh, I like to know when a variable is global
Sep 02 01:56:46 <holtmann> The g_ is suppose to be global?
Sep 02 01:57:02 <holtmann> Then please use global_ or something and not a GLib prefix.
Sep 02 01:58:14 <denkenz> holtmann: yes, g_ prefix is used to signify a global
Sep 02 01:58:50 <holtmann> Then please global_ :)
Sep 02 01:59:20 <denkenz> holtmann: btw, even glib uses g_ for global variables
Sep 02 01:59:52 <holtmann> They also have the g_ prefix to begin with :)
Sep 02 02:00:09 <holtmann> So for the GPRS stuff, I am looking into hooking up MBM hardware as GPRS and SMS only modem with oFono.
Sep 02 02:00:48 <denkenz> we don't have GPRS interface yet ;)
Sep 02 02:01:18 <holtmann> I know, but I wanna have the ConnMan part ready once we have :)
Sep 02 02:01:41 <holtmann> So I pushed initial udev skeleton for dynamic device detection.
Sep 02 02:02:53 <denkenz> nice
Sep 02 02:03:04 <holtmann> It is doing nothing except the autoconf magic.
Sep 02 02:03:35 <denkenz> We do have sms interface
Sep 02 02:03:49 <denkenz> It might be fun to do detection + init an sms interface only
Sep 02 02:03:55 <holtmann> So I am thinking to at least the get network registration and SMS working for the MBM hardware.
Sep 02 02:04:41 <holtmann> So that I can add basic modem detection to ConnMan.
Sep 02 02:05:06 <denkenz> sounds like a plan
Sep 02 02:09:28 <denkenz> I actually wouldn't mind if someone did a proper Freerunner driver too
Sep 02 02:22:58 <holtmann> ofono_modem_create() doesn't take vendor and user data?
Sep 02 02:24:27 <holtmann> You still have ofono_modem_set_data() call that is outside a probe() callback.
Sep 02 02:26:42 <denkenz> ofono_modem_create doesn't need the vendor
Sep 02 02:26:55 <denkenz> its actually different from the atoms, which I don't like
Sep 02 02:27:17 <holtmann> While the vendor might be not needed, the void *data would be useful.
Sep 02 02:27:18 <denkenz> in fact I still question calling it vendor
Sep 02 02:28:01 <holtmann> You can also call it "denis" it you want ;)
Sep 02 02:28:20 <denkenz> holtmann: So the way to use modem is to ofono_modem_create, ofono_modem_set_data, ofono_modem_register
Sep 02 02:28:44 <denkenz> holtmann: Unless you want register to take the data, since probe is called from register
Sep 02 02:28:47 <holtmann> And the ofono_modem_set_data is wrong here. I prefer if we give this to ofono_modem_create().
Sep 02 02:29:18 <denkenz> bah, this is what you do in connman_device :)
Sep 02 02:29:35 <holtmann> Then that is wrong and I am doing something bad.
Sep 02 02:29:43 <denkenz> now you tell me :)
Sep 02 02:29:54 <holtmann> Where do I do that. If I do so, then I have to fix that.
Sep 02 02:31:05 <denkenz> e.g. hso_probe
Sep 02 02:31:29 <holtmann> I see. That one is a bad example and a hack. Sorry.
Sep 02 02:31:56 <denkenz> or the iwmx_sdk stuff
Sep 02 02:32:18 <denkenz> I think few others as well
Sep 02 02:32:30 <holtmann> Actually it is called from probe() and sets the data, while the probe is triggered by device_create and device_register.
Sep 02 02:32:44 <holtmann> You do modem_create(), modem_set_data() and then modem_register().
Sep 02 02:33:14 <holtmann> Using set_data() outside the probe function is bad idea. And it should also only be used for that specific probe(data).
Sep 02 02:34:07 <denkenz> So how do you want it to look like?
Sep 02 02:34:15 <denkenz> modem_create bootstraps driver_data?
Sep 02 02:34:23 <holtmann> So if you would call modem_set_data() from generic_at_probe() then that would be fine.
Sep 02 02:34:53 <holtmann> Let me actually look into it. If we can move the modem setup into probe() callback.
Sep 02 02:36:05 <denkenz> holtmann: I'm renaming int vendor into unsigned long quirk
Sep 02 02:36:26 <holtmann> I prefer if you wouldn't.
Sep 02 02:36:46 <denkenz> holtmann: Problem is, it sounds like vendor should be a per-modem setting
Sep 02 02:36:46 <holtmann> What is wrong with vendor?
Sep 02 02:36:55 <denkenz> holtmann: not a per atom one
Sep 02 02:37:49 <holtmann> What about calling it ofono_atom_variant :)
Sep 02 02:38:05 <denkenz> heh
Sep 02 02:38:18 <denkenz> This is why I wanted a properties infrastructure in the atoms
Sep 02 02:38:30 <denkenz> So you could set anything 
Sep 02 02:38:35 <holtmann> Or something similar. I just dislike the quirk word. Mainly because the general usage is a bitmap of quirks.
Sep 02 02:39:36 <denkenz> ok, I keep it as vendor for now, lets see how it works out
Sep 02 02:39:49 <denkenz> I just cringe a little when I look at it
Sep 02 02:40:56 <denkenz> btw, is there a way to force enum to be 'long' sized?
Sep 02 02:41:31 <holtmann> Don't think so.
Sep 02 02:41:41 <holtmann> So just use unsigned int.
Sep 02 02:42:36 <denkenz> btw, I doubt there's a difference between using int vs unsigned int here
Sep 02 02:42:41 <denkenz> are you sure its worth the trouble?
Sep 02 02:42:50 <holtmann> Just from a compiler warning perspective.
Sep 02 02:43:03 <denkenz> are you sure compiler will warn?
Sep 02 02:43:07 <holtmann> If anybody does something stupid, the compiler will complain.
Sep 02 02:43:22 <denkenz> can you think of an example?
Sep 02 02:43:22 <holtmann> Only if something stupid.
Sep 02 02:43:45 <holtmann> Like range checking of the value, using negative values and some other crap.
Sep 02 02:44:57 <denkenz> that has no chance of getting accepted into vendor.h
Sep 02 02:45:09 <denkenz> where else can this happen?
Sep 02 02:45:34 <holtmann> Not in vendor.h, I mean when using it and not giving it a constant and just using some values.
Sep 02 02:45:58 <holtmann> Some times it ends up weird and I prefer that gcc complains loudly :)
Sep 02 02:46:07 <denkenz> ok
Sep 02 02:46:09 <holtmann> Hence -Werror :)
Sep 02 02:47:00 <denkenz> I just know I've been using int instead of unsigned int for enums for ever, and never had issues
Sep 02 02:48:26 <denkenz> holtmann: ok int vendor->unsigned int vendor pushed out
Sep 02 02:49:22 <holtmann> Nice. I do like the new build system when using automake-1.11 :)
Sep 02 02:49:38 <denkenz> yeah, that is kinda cool
**** ENDING LOGGING AT Wed Sep 02 02:59:58 2009

**** BEGIN LOGGING AT Wed Sep 02 02:59:58 2009
Sep 02 03:14:52 <holtmann> denkenz: Why does modem_driver->remove() has a return value. It should be void.
Sep 02 03:19:53 <denkenz> holtmann: should all of them be void? or just modem?
Sep 02 03:20:12 <holtmann> All of them. There is nothing you can do if it fails anyway.
Sep 02 03:20:35 <denkenz> ok, what about populate
Sep 02 03:20:41 <denkenz> do you wanna make that one void as well?
Sep 02 03:20:58 <holtmann> Not there yet. Can it fail?
Sep 02 03:21:16 <holtmann> Are you doing something useful with a failure value?
Sep 02 03:22:06 <denkenz> not today
Sep 02 03:22:12 <holtmann> Also the ofono_modem_create(modem,...) need to be checked against valid D-Bus object paths. If you put in something like modem-0 it crashes since - is not a valid object path char.
Sep 02 03:23:46 <denkenz> yeah, I remember checking into what constitutes a valid path, but there's no utility in dbus for this
Sep 02 03:24:46 <holtmann> On other thing. So drivers/atmodem/*.c export "generic_at" as string. I would prefer if they would use "atmodem" since that is what the driver is called.
Sep 02 03:25:20 <denkenz> fair enough
Sep 02 03:25:39 <holtmann> I just working myself through the way on how to construct a MBM driver.
Sep 02 03:26:33 <holtmann> Do we have a ofono_modem_unregister()? And ofono_modem_remove() might be named ofono_modem_destroy().
Sep 02 03:26:52 <denkenz> no modem unregister
Sep 02 03:26:56 <denkenz> didn't see the point
Sep 02 03:27:13 <holtmann> You will once I am done with udev, but it is not important right now.
Sep 02 03:27:49 <denkenz> btw, do you want to rename "isi" to "isimodem" as well?
Sep 02 03:28:17 <denkenz> And should we take the isi netlink detection out of drivers/isimodem and into plugins?
Sep 02 03:30:03 <holtmann> Yes. I will be working on that too.
Sep 02 03:30:25 <holtmann> And to be consistent, isimodem would be better.
Sep 02 03:33:56 <denkenz> you want me to get rid of remove functions that are empty?
Sep 02 03:34:14 <denkenz> and set them to NULL in the driver struct?
Sep 02 03:35:17 <holtmann> No. I prefer to have them to be symetric.
Sep 02 03:35:45 <denkenz> ok
Sep 02 03:45:03 <denkenz> holtmann: ok remove now returns void
Sep 02 03:45:07 <denkenz> populate returns void
Sep 02 03:45:15 <denkenz> generic_at -> atmodem
Sep 02 03:45:17 <denkenz> isi -> isimodem
Sep 02 03:46:34 <holtmann> You ensure that disable() is called before remove(), do you?
Sep 02 03:47:04 <denkenz> yes
Sep 02 03:48:21 <denkenz> its done in modem.c:1035
Sep 02 03:49:08 <holtmann> Good. Just checking :)
Sep 02 03:49:10 <denkenz> note that disable isn't guaranteed to be instantenous
Sep 02 03:49:18 <denkenz> So that is a little bit of bad form
Sep 02 03:49:39 <holtmann> You should delay the remove until disable finished or timeout.
Sep 02 03:49:46 <holtmann> However that are details for later.
Sep 02 03:50:21 <denkenz> hard when we Ctrl-C
Sep 02 03:50:26 <denkenz> but yes, lets figure that out
Sep 02 04:35:26 <holtmann> denkenz: Still around?
Sep 02 04:36:04 <denkenz> just barely
Sep 02 04:41:14 <holtmann> Can wait until tomorrow. Working on some ofono_modem_create() changes.
Sep 02 04:44:32 <denkenz> sounds dangerous ;)
Sep 02 04:46:17 <holtmann> Yep. Will change a lot.
Sep 02 04:47:02 <denkenz> heh, for the better? :)
Sep 02 04:48:29 <denkenz> fill me in tomorrow, I'm not entirely happy with modem.c yet
Sep 02 12:28:41 <holtmann> dilinger: Around?
Sep 02 14:38:44 <denkenz> holtmann: Fill me in on modem_create
Sep 02 15:53:04 <akiniemi> denkenz: you didn't just tell me to fork did you? ;)
Sep 02 15:53:24 <denkenz> akiniemi: No, but remember that plugins can define any API they wish
Sep 02 15:53:33 <denkenz> akiniemi: Just like atmodem used to have at.Manager
Sep 02 15:53:52 <akiniemi> denkenz: ...and thank goodness that went away :)
Sep 02 15:53:52 <denkenz> akiniemi: If something isn't part of the official API doesn't mean it can't be in oFono
Sep 02 15:54:54 <denkenz> akiniemi: BandSelection, CellInfo and suspended GPRS state are not going to be the only things you guys would want to expose
Sep 02 15:55:37 <akiniemi> denkenz: no, I think that is about it
Sep 02 15:56:03 <akiniemi> denkenz: sure, the modem has lots to offer, but weÃ're not even thinking about providing those with oFono
Sep 02 15:56:33 <denkenz> akiniemi: My point is Nokia is not the only one who has bunch of "interesting" features to expose
Sep 02 15:56:52 <denkenz> akiniemi: And if we have to fight Ericsson, Qualcomm, Infineon on the mailing list every time
Sep 02 15:56:57 <denkenz> akiniemi: It just won't work
Sep 02 15:57:26 <akiniemi> denkenz: right, but I'm not too confident that we are sufficiently aware of the "what's out there"...
Sep 02 15:57:42 <akiniemi> ...to know that those three features are not a common for all of the modems
Sep 02 15:57:47 <denkenz> akiniemi: Hence why I'm religiously sticking to 27.007
Sep 02 15:58:05 <denkenz> If we find that we can make it work for everyone, _then_ we make it official
Sep 02 15:58:32 <akiniemi> but we know for sure not everything is going to work for everyone
Sep 02 15:58:51 <akiniemi> even the standard API will see only partial support, e.g., most Symbian phones
Sep 02 15:59:12 <denkenz> Sure, but there we're talking about support / not support
Sep 02 15:59:27 <denkenz> with something like BandSelection we're talking about NokiaBandSelection vs InfineonBandSelection
Sep 02 15:59:38 <akiniemi> denkenz: why?
Sep 02 15:59:39 <denkenz> And we're not going down that path
Sep 02 15:59:56 <akiniemi> All modems have three states: 3G only, 2G only, dual mode
Sep 02 15:59:56 <denkenz> Because everyone does this differently
Sep 02 16:00:15 <denkenz> Band Selection is a bad example, lets say Neighbor Cell Info
Sep 02 16:00:20 <denkenz> Or even your GPRS suspended state
Sep 02 16:00:37 <denkenz> I agree Band selection we can probably make work
Sep 02 16:00:43 <akiniemi> denkenz: so those that don't support suspend just never notify that state transition
Sep 02 16:01:56 <akiniemi> denkenz: with neighbor cell info, I'm quite sure that can be made to work, too
Sep 02 16:02:18 <akiniemi> denkenz: at least E-CID is a defined set of properties (some OMA standard, I can look it up)
Sep 02 16:02:26 <denkenz> I'm not saying it can't, I'm just saying I'm not going to commit to making it an official oFono api until we know
Sep 02 16:03:49 <denkenz> Btw, for Band Selection there are plenty of devices that do stuff like: "2G preferred", "3G preferred"
Sep 02 16:04:01 <denkenz> and then actual frequency selection
Sep 02 16:04:25 <denkenz> If you need fine grained control like that, you still must implement a vendor specific API
Sep 02 16:04:35 <denkenz> There's nothing scary / wrong about doing it this way
Sep 02 16:06:24 <denkenz> Trust me, I've seen plenty of APIs where you abstract something away, then need to reverse the abstraction to do something useful
Sep 02 16:07:15 <akiniemi> denkenz: ythat's pretty much my feeling about background scanning, btw :)
Sep 02 16:07:59 <denkenz> That one will change into OperatorScanInterval and ProposeOperatorScan method
Sep 02 16:08:12 <denkenz> So app / driver will have some control over this
Sep 02 16:08:45 <akiniemi> denkenz: there is another thing about operator scan that is bothering me
Sep 02 16:09:13 <akiniemi> when you call ProposeOperatorScan, you get a ProperiesChanged signal with an array of object paths, no?
Sep 02 16:09:34 <denkenz> probably
Sep 02 16:09:53 <akiniemi> then you need to recurse those objects with GetProperties() to know enough to populate some treeview model
Sep 02 16:10:05 <akiniemi> quite many round-trips...
Sep 02 16:10:46 <denkenz> actually you don't need to traverse all of them
Sep 02 16:10:51 <denkenz> Only the ones that changed
Sep 02 16:11:08 <denkenz> Which unless you stepped off a plane isn't going to change drastically
Sep 02 16:11:23 <akiniemi> There's always the infamous UMTS availability flag
Sep 02 16:11:54 <denkenz> ?
Sep 02 16:12:29 <akiniemi> UMTS availability changes by location; because 3G coverage is typically incomplete
Sep 02 16:12:55 <akiniemi> Or were we not showing that?
Sep 02 16:13:10 <denkenz> what is this flag reported, I only talk AT commands
Sep 02 16:13:16 <denkenz> s/what/where
Sep 02 16:14:05 <akiniemi> This is returned in the ISI protocol as a result to a network scan
Sep 02 16:14:16 <akiniemi> I guess AT has no such thing?
Sep 02 16:14:50 <denkenz> So this is the weird COPS returning multiple instances of a single operator but with tech being different
Sep 02 16:14:59 <denkenz> The topic of our previous flamewar
Sep 02 16:15:32 <denkenz> correct?
Sep 02 16:16:06 <akiniemi> I suppose; Nokia modems do weird things over the AT interface
Sep 02 16:16:16 <akiniemi> Any other modems do that?
Sep 02 16:16:47 <denkenz> I think every modem does this
Sep 02 16:16:53 <denkenz> Its a network feature
Sep 02 16:17:04 <denkenz> oFono simply ignores this information today
Sep 02 16:17:12 <akiniemi> Right, that was my feeling about this
Sep 02 16:17:29 <akiniemi> Of course, we display this information in the UI
Sep 02 16:17:45 <denkenz> The currently active tech is reported
Sep 02 16:18:13 <denkenz> However, the umts available stuff is not binding according to 27.007
Sep 02 16:18:25 <denkenz> So the usefulness of it is extremely questionable
Sep 02 16:18:45 <akiniemi> Well, I find it very useful every time when I'm roaming in the US
Sep 02 16:19:07 <akiniemi> My home operator has many roaming partners, but typically only one of them has proper 3G coverage
Sep 02 16:19:24 <akiniemi> And which one it is seems to change city by city
Sep 02 16:19:48 <denkenz> I've not seen the multiple identical operator except for tech thing in the U.S.
Sep 02 16:20:36 <akiniemi> That's odd.
Sep 02 16:21:20 <akiniemi> Is your modem still multi-band?
Sep 02 16:21:21 <denkenz> something for you to try in a couple of weeks :)
Sep 02 16:21:53 <akiniemi> denkenz: ah well, travel restrictions and all that, you know ;)
Sep 02 16:22:12 <denkenz> I'm not sure, I was playing with COPS a while ago
Sep 02 16:58:35 <denkenz> akiniemi: Funny, my SE device reports AT&T twice with different mcc/mncs
Sep 02 16:58:47 <denkenz> but no tech
Sep 02 16:59:27 <denkenz> akiniemi: We might have to revisit filtering, and if an operator is reported twice, always use the highest tech setting
Sep 02 17:03:42 <akiniemi> denkenz: that could be another quirk of GSMA
Sep 02 17:04:00 <akiniemi> the hard-coded names for MNC/MCC pairs is dictated by GSMA
Sep 02 17:04:11 <akiniemi> And an old phone probably has an equally old list
Sep 02 17:04:29 <denkenz> This was bought Dec last year
Sep 02 17:05:31 <akiniemi> ah, ok. There's been a couple of updates since then, but probably not to AT&T
Sep 02 17:06:20 <akiniemi> denkenz: but agree, let's come back to this later (with a bit more empirical data under our belts)
Sep 02 17:06:34 <denkenz> What's even more funny is that it reports AT&T for a T-mobile mcc/mnc :)
Sep 02 17:07:03 <akiniemi> That's be an interesting merger ;)
Sep 02 17:07:06 <denkenz> I think our approach is sound, just need to finish tweaking it properly
Sep 02 17:07:16 <akiniemi> s/'s/'d
Sep 02 18:23:50 <dilinger> hm, lotta GPRS traffic on the list..
Sep 02 18:27:50 <denkenz> understatement, but expected
Sep 02 18:29:14 <akiniemi> I think the disagreements were mostly on minor details
Sep 02 18:29:44 <denkenz> hardware specific details really
Sep 02 18:30:37 <akiniemi> True, the basic model and the API, I think everyone is fairly happy with
Sep 02 18:31:28 <denkenz> Good, are you guys up to implementing whats in git ?
Sep 02 18:31:57 <denkenz> there's still some questions whether we should expose Netmask, Address, Gateway, Broadcast as properties
Sep 02 18:32:14 <denkenz> But otherwise we should be good to go for a trial implementation
Sep 02 18:33:54 <akiniemi> I think consensus was to have oFono expose the IP information
Sep 02 18:34:38 <denkenz> I got that impression as well, but I wanna wait for holtmann to give final ack
Sep 02 18:34:52 <ipuustin> denkenz: There already is something of a trial implementation. ;-) Since the changes between the APIs are quite small, hacking the patches I sent to support some consensus API might not require too much work.
Sep 02 18:35:10 <denkenz> ipuustin: So get on it and send it to the ML :)
Sep 02 18:36:07 <akiniemi> denkenz: give the man at least some time to sleep, will you ;)
Sep 02 18:36:48 <denkenz> akiniemi: Hehe, actually I've so much backlog of stuff to do I don't necessarily want him to hurry
Sep 02 18:37:42 <denkenz> but having an interface + driver api can allow us to integrate some 3G data cards which don't need ppp
Sep 02 18:37:46 <ipuustin> denkenz: yes, getting the GPRS in shape is on my short-term TODO list... soon there will be a discussion about the internal core-modem GPRS API. ;-)
Sep 02 18:37:50 <denkenz> So we can do some additional usecase vectors
Sep 02 18:38:16 <akiniemi> hopefully the driver API is less controversial
Sep 02 18:38:37 <denkenz> ipuustin: Cool, looking forward to it :)
Sep 02 18:38:44 <akiniemi> of course there is that issue with enum vs. string as the status, type, etc
Sep 02 18:39:08 <denkenz> akiniemi: The driver api should be quite simple
Sep 02 18:39:13 <denkenz> enum vs string?
Sep 02 18:39:47 <akiniemi> I think Ismo's patches use const char* as status param in the notify() API
Sep 02 18:40:36 <akiniemi> I don't think that's a hbad idea, actually, the netreg driver could do the same for reg status, IMO
Sep 02 18:40:47 <akiniemi> s/hbad/half-bad
Sep 02 18:41:46 <denkenz> why, the status is well defined by the spec
Sep 02 18:41:57 <denkenz> do you guys have other statuses?
Sep 02 18:42:15 <akiniemi> Naturally!
Sep 02 18:42:34 <akiniemi> We have no service, and then a whole lot of explanation of exactly why :)
Sep 02 18:42:53 <denkenz> isn't no service same as unregistered?
Sep 02 18:43:09 <akiniemi> That's where I'm currentlly mapping it
Sep 02 18:43:26 <denkenz> ipuustin: btw, +typedef unsigned int ofono_gprs_context_id_t; -> make it a simple int
Sep 02 18:43:59 <denkenz> ipuustin: Also, condense all the notify funcs into as few as possible
Sep 02 18:44:40 <denkenz> ipuustin: Type & state should use values from 27.007, the rest are fine as strings
Sep 02 18:46:02 <ipuustin> denkenz: Ok, I'll make the id a simple int. In the beginning the notify functions were condensed into one, but I was told that it was not the Ofono way. :-) Is there a header file with the 27.007 definitions available?
Sep 02 18:46:27 <akiniemi> ipuustin: those would go into common.h
Sep 02 18:46:40 <denkenz> akiniemi: no, but the spec is available
Sep 02 18:46:54 <denkenz> sorry meant for ipuustin
Sep 02 18:47:02 <denkenz> akiniemi: Actually common.h is really small now
Sep 02 18:47:10 <denkenz> akiniemi: I prefer the enums in gprs.c or something
Sep 02 18:47:56 <denkenz> ipuustin: Simply use the definitions from 3GPP 27.007
Sep 02 18:49:02 <ipuustin> denkenz: ok, will do.
Sep 02 18:49:40 <akiniemi> denkenz: hmm... would it not make sense to have an enum that the drivers could use when mapping from modem-specific values?
Sep 02 18:50:02 <denkenz> akiniemi: We don't have modem-specific values :)
Sep 02 18:50:44 <denkenz> ipuustin: btw, you might want to look at 27.007 in general, since all the address/gateway/dns settings must be queried and not notified
Sep 02 18:50:56 <denkenz> ipuustin: So it might be a good idea for oFono to follow the same structure
Sep 02 18:51:50 <holtmann> denkenz: Just catching up. So the conses is that we have to not touch the interface settings at all. And just tell something like ConnMan what the remote side told us.
Sep 02 18:52:05 <denkenz> holtmann: Seems to be the case
Sep 02 18:52:54 <denkenz> holtmann: 27.007 does not allow one to query broadcast address
Sep 02 18:52:59 <denkenz> holtmann: How do we wanna handle this
Sep 02 18:53:19 <holtmann> The broadcast address can be calculated from IP and netmask.
Sep 02 18:54:02 <holtmann> Also in theory since everything is point-to-point we can set whatever IP we want and just have to route it properly. The local address is irrelevant. Only the remote one is important.
Sep 02 18:54:03 <denkenz> holtmann: ok, so should I add Address and Netmask properties
Sep 02 18:55:09 <holtmann> Sure.
Sep 02 18:55:20 <denkenz> Broadcast you will calculate yourself?
Sep 02 18:57:18 <denkenz> so netmask & address have been added & pushed
Sep 02 18:57:40 <denkenz> The only other sticky points are tri-state "attached" property
Sep 02 18:57:48 <denkenz> And rx/tx/uptime tracking
Sep 02 18:59:06 <holtmann> As I mentioned RX/TX etc. We will figure out to do that in a better way. With having ofonod sleep most of the time. So we need kernel assistance.
Sep 02 18:59:36 <holtmann> For the attach part, I still need to be convinced that we need something more.
Sep 02 18:59:56 <akiniemi> holtmann: You mean auto-attach?
Sep 02 19:00:09 <denkenz> "suspended"
Sep 02 19:00:11 <denkenz> thingy
Sep 02 19:00:36 <denkenz> auto-attach is another one, and I'm tending to agree we need an AutoAttach property
Sep 02 19:02:29 <akiniemi> holtmann: I don't necessarily see point in the "suspended" status, if netlink can provide something similar
Sep 02 19:04:11 <ipuustin> akiniemi: I was also thinking the same. If the no-carrier property works as I think it does, it could be a "linuxy" way of doing it. At least worth checking out.
Sep 02 19:05:24 <akiniemi> ipuustin: and if applications can't live withouth a D-Bus signal, then the connectivity daemon can surely synthesize one
Sep 02 19:17:58 <denkenz> this might be fun to check out some day http://git.gnome.org/cgit/mobile-broadband-provider-info/
Sep 02 19:26:22 <courmisch> wasn't aki libmoi supposed to do that?
Sep 02 19:27:08 <akiniemi> courmisch: no, that was for the hard-coded names list (maintained by GSMA)
Sep 02 19:28:55 <akiniemi> courmisch: this is comparable to /etc/operator_settings
Sep 02 19:29:59 <akiniemi> courmisch: anyway, I'd say both fit squarely into oFono's scope...
Sep 02 19:49:51 <denkenz> akiniemi: sounds like libmoi should get integrated into netreg.c
Sep 02 19:50:16 <denkenz> akiniemi: We already use cops & EFpnn/EFopl in there
Sep 02 20:02:25 <holtmann> akiniemi: So we have IFF_RUNNING and IFF_LOWER_UP to signal the interface state. If we use them properly, then they should allow us to nicely expose any kind of suspended state etc.
Sep 02 20:02:58 <holtmann> Also I have to do some testing how other hardware handles this. Especially the HSO and MBM ones. Since both come with a high-speed network device.
Sep 02 20:05:38 <denkenz> holtmann: Did you have any changes to modem.c to discuss?
Sep 02 20:06:26 <holtmann> Sure.
Sep 02 20:06:28 <akiniemi> denkenz: libmoi is basically just bsearch()'ing a table that I generate from a file
Sep 02 20:06:52 <denkenz> boggle
Sep 02 20:07:08 <denkenz> akiniemi: That's fine, we can still incorporate it into ofono
Sep 02 20:07:09 <akiniemi> denkenz: I need to check what license this file carries; whether it's something I can publish
Sep 02 20:07:24 <denkenz> nod
Sep 02 20:08:15 <akiniemi> holtmann: sounds good
Sep 02 20:08:49 <denkenz> holtmann: I'd like to get that part somewhat stable before we make 0.4 release
Sep 02 20:10:00 <holtmann> struct ofono_modem *ofono_modem_create(const char *node, const char *type);
Sep 02 20:10:31 <holtmann> So first the node parameter is non-sense since it is just used for the object path. Lets derive this from type and do things like atmodem0,atmodem1,mbm0 etc.
Sep 02 20:11:23 <denkenz> where to store the counter?
Sep 02 20:11:35 <holtmann> I also see why generic_at.c and the modem_set_data is so weird. You mix hardware detect and actual driver into the same plugin. This is not needed. See the MBM and udev plugin I put in.
Sep 02 20:11:47 <holtmann> One will detect and create the modem. The other will attach the driver and make it use.
Sep 02 20:11:58 <holtmann> udev.c is not finished btw.
Sep 02 20:12:27 <holtmann> akiniemi: We should do something similar for isimodem. So isimodem for the modem and isidetect for the phonet detection. Not that I have looked into any details here.
Sep 02 20:12:40 <holtmann> The counter can be just some random thing in modem_create().
Sep 02 20:12:58 <holtmann> It is an option path, so I don't care what it is.
Sep 02 20:13:05 <holtmann> s/option/object/
Sep 02 20:13:27 <denkenz> ok, so we might have mbm2, isi3, generic_at4
Sep 02 20:13:39 <denkenz> e.g. a global counter, not per-driver
Sep 02 20:13:56 <holtmann> Who cares? If you wanna make it look better, fine, but in the end nobody sees it :)
Sep 02 20:14:04 <holtmann> denkenz: The other thing is that the config file parsing from generic_at.c has to be moved to its own modemconf plugin.
Sep 02 20:14:07 <denkenz> just making sure
Sep 02 20:14:28 <holtmann> So we have modem_create() from udev plugin and another one for static ones from modemconf.c
Sep 02 20:14:48 <holtmann> Then we can even hard coded MBM via a config file. Since they are not related at all.
Sep 02 20:15:08 <denkenz> umm, how do you know what atom drivers a device uses?
Sep 02 20:15:19 <holtmann> akiniemi: I assume you guys don't care at all since you always get your hardware detection via phonet driver, right?
Sep 02 20:15:23 <denkenz> or you give the modem driver in modemconf
Sep 02 20:15:42 <holtmann> I wanna add a Driver=generic_at or Driver=mbm to /etc/ofono/modem.conf.
Sep 02 20:16:21 <denkenz> Yep, ok, that's a good idea
Sep 02 20:16:56 <denkenz> There's still the connection info to consider though
Sep 02 20:17:02 <denkenz> E.g. tcp/tty
Sep 02 20:17:24 <holtmann> Yes. And now it gets tricky :)
Sep 02 20:18:29 <denkenz> nod, that is the main reason generic_at is the way it is
Sep 02 20:18:34 <akiniemi> holtmann: hmm, I suppose, but we might need to preconfigure some stuff if it turns out impossible to detect and version on the fly
Sep 02 20:19:28 <holtmann> Do you have details on this. However we split isimodem and isidetect, then isidetect could read some /etc/ofono/phonet.conf. Since I am not sure we can fit this into modemconf.
Sep 02 20:20:19 <denkenz> Can't we have a generic netlink driver and a config file for device id -> driver mapping?
Sep 02 20:20:37 <denkenz> (I know nothing about netlink though)
Sep 02 20:21:05 <akiniemi> holtmann: that sounds fine. And I'm pretty confident that we won't need the config stuff at all
Sep 02 20:21:21 <akiniemi> holtmann: but you never know -- there's a lot of Nokia HW out there ;)
Sep 02 20:21:41 <holtmann> Okay. I then lets cross that bridge when we are at it. I still have to go through a lot of phonet you guys put in.
Sep 02 20:22:21 <holtmann> denkenz: So I am currently thinking that we do modem_create(const char *driver, GHastTable *settings).
Sep 02 20:22:41 <holtmann> And then give this hash table to the driver on probe. So it can do the right thing.
Sep 02 20:22:57 <holtmann> So we have TTY name, Ethernet name, TTY etc.
Sep 02 20:23:09 <holtmann> If the driver doesn't care (like for phonet), you can just give NULL.
Sep 02 20:23:51 <holtmann> So this hash table can be generated either from /etc/ofono/modem.conf via modemconf plugin or via udev plugin.
Sep 02 20:24:21 <holtmann> denkenz: Btw. I have used my builtin MBM card and ofonod with mbm plugin to send text message yesterday night :)
Sep 02 20:24:49 <denkenz> so I really don't like hashtable idea, so far we've not been exposing any glib details in the driver api
Sep 02 20:24:52 <holtmann> denkenz: If we get simple GPRS support in that I abandon whatever I working on inside ConnMan and just do everything inside oFono.
Sep 02 20:25:10 <holtmann> denkenz: I agree with you on this. That is the piece that I hate, too.
Sep 02 20:25:12 <dilinger> denkenz: what's wrong w/ exposing glib details?
Sep 02 20:25:43 <denkenz> holtmann: What about modem variant api?
Sep 02 20:25:49 <denkenz> ofono_modem_create
Sep 02 20:25:54 <denkenz> ofono_modem_set_variant
Sep 02 20:26:00 <holtmann> denkenz: What about creating ofono_settings or ofono_properties that we can use for this. Sounds duplication, but could keep the API clean.
Sep 02 20:26:34 <denkenz> just store the properties on the modem
Sep 02 20:26:35 <holtmann> denkenz: You mean property right? That would be another option to solve this.
Sep 02 20:26:52 <denkenz> in the beginning we might get away with simple string/int
Sep 02 20:27:26 <denkenz> dilinger: That has been the convention so far in multiple projects
Sep 02 20:27:26 <holtmann> I do that in ConnMan this way and it maps internally to a hash table. So ofono_modem_set_string and ofono_modem_set_integer.
Sep 02 20:27:31 <denkenz> dilinger: hence why I'm cautious
Sep 02 20:27:47 <holtmann> denkenz: I am on you with this. I prefer not to have GLib types in the API.
Sep 02 20:28:01 <holtmann> Hence I wanted to discuss this.
Sep 02 20:28:18 <denkenz> so I like set_string / set_integer idea
Sep 02 20:28:35 <dilinger> denkenz: okay.  just curious, because.. i can understand it if you're wanting people to be able to write things in other languages, or are afraid of API/ABI compat issues.. but i don't see that being an issue here
Sep 02 20:28:38 <holtmann> And have get_string and get_integer of course.
Sep 02 20:29:00 <denkenz> however, if we do this, why not do away with vendor stuff and also have properties on the atoms?
Sep 02 20:30:01 <holtmann> Because you have to write all of them :)
Sep 02 20:30:22 <denkenz> anyway, rhetorical question
Sep 02 20:30:26 <holtmann> I have done this with ConnMan. Massive work.
Sep 02 20:30:36 <denkenz> sounds like set_foo get_foo is the way
Sep 02 20:30:38 <holtmann> I abandon it in the end.
Sep 02 20:31:26 <holtmann> I would start small with set_string and get_string only. Only add the integer or boolean once we need them.
Sep 02 20:31:40 <denkenz> already need boolean for the tcp port
Sep 02 20:31:44 <denkenz> err integer
Sep 02 20:31:54 <holtmann> Okay. Fair enough.
Sep 02 20:32:27 <holtmann> Can you work on this, then I can start fixing the modemconf and udev part. And get MBM working with auto-detect.
Sep 02 20:32:47 <holtmann> I really prefer to just finish the oFono plugin for ConnMan and remove all the useless crap from ConnMan.
Sep 02 20:33:07 <holtmann> It is just overhead. Was good for a learning exercise, but now it is time to do it right way.
Sep 02 20:33:30 <denkenz> ok, so while we're at this
Sep 02 20:33:37 <denkenz> if we're using driver name for object path
Sep 02 20:33:41 <denkenz> do we assume driver name is valid?
Sep 02 20:35:20 <denkenz> Also, some parts of generic_at.conf don't map very well
Sep 02 20:35:28 <denkenz> In particular init string, timeout command
Sep 02 20:54:43 <denkenz> holtmann: Btw, the fact that you're sending / receiving SMS on mbm is pretty cool
Sep 02 20:56:38 <denkenz> This is the area where once we get proper GPRS support, we'll be light years ahead of modem manager 
Sep 02 21:02:44 <holtmann> denkenz: We have to check the driver name convert things for the object path.
Sep 02 21:02:54 <holtmann> Again the object path that we end up with is not important.
Sep 02 21:03:13 <denkenz> holtmann: So do you know of any easy way to check for validity?
Sep 02 21:03:22 <denkenz> or do I simply use isalphanum?
Sep 02 21:03:43 <holtmann> a-z, A-Z, 0-9 and _ are valid ones.
Sep 02 21:03:56 <holtmann> Everything else is invalid. Including - :(
Sep 02 21:04:07 <denkenz> silly that dbus doesn't have a utility for this
Sep 02 21:04:50 <holtmann> Yep agree. Feel free to send a patch for D-Bus :)
Sep 02 21:30:02 <holtmann> denkenz: Before I forget this. When terminating ofonod, we get a PropertyChanged signal for modems, but it still contains the just removed modem.
Sep 02 21:30:24 <holtmann> It needs to show an empty list. Check with monitor-ofono test scirpt.
Sep 02 21:30:34 <denkenz> interesting
Sep 02 21:30:46 <dilinger> http://bugs.freedesktop.org/show_bug.cgi?id=23616
Sep 02 21:31:31 <dilinger> regarding object path validity
Sep 02 21:31:44 <holtmann> But that is dbus-glib code :)
Sep 02 21:32:14 <holtmann> dilinger: Since you are here now. For the G1 stuff.
Sep 02 21:32:40 <holtmann> What are you running this on? Android or Debian on G1?
Sep 02 21:32:55 <holtmann> Meaning to we have udev or need some static config.
Sep 02 21:32:58 <dilinger> holtmann: a debian chroot
Sep 02 21:33:03 <dilinger> on android
Sep 02 21:33:14 <dilinger> so /dev is static
Sep 02 21:33:19 <holtmann> You see my comments about doing modemconf plugin.
Sep 02 21:34:23 <holtmann> So you need a config file entry that says /dev/sm*0 and the tells use driver g1.
Sep 02 21:35:34 <dilinger> okay
Sep 02 21:36:08 <holtmann> What is the status of the G1 patches?
Sep 02 21:36:28 <holtmann> Since I just pushed a tiny MBM driver, I like to get the G1 stuff also included.
Sep 02 21:37:04 <dilinger> holtmann: i can resubmit them later tonight
Sep 02 21:37:32 <holtmann> Do you have the current version in your repo? Then give me the link and I have a quick look.
Sep 02 21:38:15 <dilinger> i don't.  i'm literally right in the middle of a rebase
Sep 02 21:38:34 <dilinger> once i'm done dealing w/ conflicts i can push to my public repo
Sep 02 21:58:13 <holtmann> denkenz: So I pushed a really simple modemconf plugin. Just adding [modem] Driver=mbm would quickly make MBM testing possible.
Sep 02 21:58:32 <holtmann> Once we have the set_string stuff, we need to extend this with the stuff from generic_at.c
Sep 02 21:59:04 <holtmann> dilinger: So for you, just adding [G1] Driver=g1 should do the trick. Assuming you hardcode the device node like MBM does for now.
Sep 02 21:59:34 <denkenz> holtmann: almost ready
Sep 02 22:20:35 <dilinger> holtmann: pushed everything minus quirks
Sep 02 22:20:42 <dilinger> http://git.collabora.co.uk/?p=user/dilinger/ofono-g1-new;a=summary
Sep 02 22:20:55 <holtmann> dilinger: Pushed the modem.conf example btw.
Sep 02 22:21:26 <dilinger> (haven't tested w/ the new rebase yet, though; will do that after pushing quirks stuff)
Sep 02 22:21:49 <holtmann> So remove the --enable-g1 part. That is not needed. We can always compile this in.
Sep 02 22:22:00 <holtmann> And remove the modem_create part from init/exit.
Sep 02 22:22:13 <holtmann> That will be done by modemconf plugin and /etc/ofono/modem.conf now.
Sep 02 22:22:44 <holtmann> See what mbm.c does. Your init/exit should be just register/unregister modem driver.
Sep 02 22:23:19 <dilinger> okay
Sep 02 22:24:19 <dilinger> and as far as the vendor quirks, where should they be defined?
Sep 02 22:25:05 <holtmann> For the driver name of G1 SMS please use just g1.
Sep 02 22:25:23 <holtmann> It is easier if we have one common name for the g1 specialities.
Sep 02 22:25:43 <dilinger> eh?
Sep 02 22:25:55 <dilinger> the g1sms code is going away
Sep 02 22:26:04 <holtmann> Okay. My bad. Then never mind :)
Sep 02 22:26:32 <holtmann> The first patch with the modem driver looks good to me. After you did the modification I mentioned above.
Sep 02 22:26:54 <dilinger> it'll be something like   ofono_sms_create(modem, QUIRK_PREDEFINED_CNMI_STRING, "atmodem", chat);
Sep 02 22:27:59 <holtmann> Okay. So lets get the modem driver patch in. And since SMS is not functional. Leave the ofono_sms_create out of it. No need to show an interface that is not working.
Sep 02 22:28:46 <holtmann> Take the latest git and check with example in modem.conf :)
Sep 02 22:31:18 <dilinger> and you want me to change the ofono_modem_driver name to "g1"  (from "HTC G1"), as well as ofono_modem_create("G1", "HTC G1") to ofono_modem_create("G1", "g1")?
Sep 02 22:31:25 <dilinger> or did you just want that for the SMS stuff?
Sep 02 22:32:21 <holtmann> For the G1 in create I don't care. That will go away.
Sep 02 22:34:11 <dilinger> and for the other?
Sep 02 22:35:09 <holtmann> Yes. Just call everything "g1".
Sep 02 22:36:36 <holtmann> Actually ofono_modem_create will go away. That will done via modem.conf and modemconf.c
Sep 02 22:40:32 <dilinger> holtmann: how's this?
Sep 02 22:40:33 <dilinger> http://git.collabora.co.uk/?p=user/dilinger/ofono-g1-new;a=summary
Sep 02 22:40:40 <dilinger> (still untested, though)
Sep 02 22:40:57 <holtmann> +#if 0
Sep 02 22:40:57 <holtmann> +       /* disable SMS for now; it requires special handling */
Sep 02 22:40:57 <holtmann> +       ofono_sms_create(modem, 0, "atmodem", chat);
Sep 02 22:40:57 <holtmann> +#endif
Sep 02 22:41:15 <holtmann> Remove this. Not needed since GIT is good a history tracking.
Sep 02 22:41:34 <holtmann> static int g1_init(void) {
Sep 02 22:41:45 <holtmann> return ofono_modem_driver_unregister(&g1_driver);
Sep 02 22:41:46 <holtmann> }
Sep 02 22:41:50 <holtmann> That is all you need :)
Sep 02 22:42:07 <holtmann> And the copy plugins/modem.conf /etc/ofono/modem.conf and uncomment the line for G1.
Sep 02 22:44:41 <dilinger> holtmann: um.  so clarify, g1_init should *not* have ofono_modem_create nor ofono_modem_register.  should it have the g_file_test?
Sep 02 22:44:52 <holtmann> None of it.
Sep 02 22:45:05 <holtmann> Just register the driver. Look a plugins/mbm.c for an example.
Sep 02 22:45:17 <dilinger> holtmann: i'd also prefer to keep the sms comment in there.  git may be great at tracking history, but not when you're rebasing every 5 mins (as i'm doing)
Sep 02 22:45:36 <dilinger> ok
Sep 02 22:45:44 <holtmann> This is why I wanna get your patch in now. It looks fine. So remove that comment about SMS and we can merge it.
Sep 02 22:47:50 <denkenz> holtmann: pushed out property support and the ofono_modem_create change
Sep 02 22:47:59 <denkenz> Check the valid_object_path funtion just in case
Sep 02 22:49:34 <denkenz> dilinger: For quirks, simply modify drivers/vendor.h
Sep 02 22:49:50 <denkenz> dilinger: Then make the necessary mods to sms.c
Sep 02 22:52:09 <denkenz> holtmann: btw, your chat.c makes no sense
Sep 02 22:52:15 <holtmann> Why?
Sep 02 22:52:20 <denkenz> holtmann: why do you do any of this for a tty?
Sep 02 22:52:35 <dilinger> holtmann: ok, updated
Sep 02 22:53:02 <dilinger> 1 less global variable
Sep 02 22:53:24 <holtmann> +       g_at_chat_unref(chat);
Sep 02 22:53:24 <holtmann> +       ofono_modem_set_data(modem, NULL);
Sep 02 22:53:29 <holtmann> These should be the other way around.
Sep 02 22:53:57 <holtmann> +#include <glib/gstdio.h>
Sep 02 22:54:03 <holtmann> That include should not be needed.
Sep 02 22:54:36 <dilinger> right. that was for the g_access, which is gone now
Sep 02 22:54:39 <holtmann> Same for +#include <unistd.h>
Sep 02 22:54:39 <holtmann> +#include <stdlib.h>
Sep 02 22:55:26 <dilinger> plugins/g1.c:74: warning: implicit declaration of function ‘getenv’
Sep 02 22:55:26 <holtmann> Other than that. Nice. fix this up and send it to the mailing list.
Sep 02 22:55:31 <dilinger> unistd is required
Sep 02 22:55:35 <denkenz> holtmann: For tty I suggest to simply use g_at_chat_from_tty
Sep 02 22:55:38 <dilinger> er, stdlib
Sep 02 22:55:44 <holtmann> getenv is stdlib :)
Sep 02 22:56:24 <holtmann> denkenz: I do want the async connect for TTYs. The g_at_chat_from_tty has to die. And yes, I know you mentioned that before.
Sep 02 22:57:08 <denkenz> holtmann: In that case make chat.c handle sockets and non-blocking tty open
Sep 02 22:57:12 <holtmann> dilinger: One favor. +#define MODEM_DEVICE "/dev/smd0"
Sep 02 22:57:34 <holtmann> Use the /dev/smd0 directly inside the code and not a define for it. We will fix this via the set_string property stuff and modem.conf.
Sep 02 22:57:58 <dilinger> holtmann: is it still necessary at all?
Sep 02 22:57:59 <holtmann> And then this all goes away and now hardcoded device nodes are needed anymore.
Sep 02 22:58:14 <denkenz> We already have properties
Sep 02 22:58:17 <denkenz> fix it properly :P
Sep 02 22:58:35 <holtmann> dilinger: Right now, yes, will be fixed soon. I wanna get the patch in before fixing this.
Sep 02 22:58:44 <holtmann> denkenz: Patch in first, then fixing this :)
Sep 02 22:58:58 <denkenz> nod
Sep 02 22:59:04 <holtmann> All this re-basing is a waste of time for dilinger.
Sep 02 22:59:50 <holtmann> denkenz: And actually I hope that you port generic_at config file parsing over to modemconf.c ;)
Sep 02 23:00:53 <denkenz> lol, I was assuming all I'd need to do is git rm generic_at.*
Sep 02 23:01:28 <holtmann> I does need a little bit more work actually.
Sep 02 23:02:23 <holtmann> And about the chat.c. What is so wrong with it.
Sep 02 23:02:39 <denkenz> just that if you don't have anything to wait for
Sep 02 23:02:42 <denkenz> the open is blocking
Sep 02 23:02:50 <denkenz> So all the g_io_add_watch is pointless
Sep 02 23:03:10 <holtmann> Except if you point it at /dev/rfcomm0
Sep 02 23:03:21 <denkenz> the open is still blocking
Sep 02 23:03:31 <denkenz> so no difference
Sep 02 23:03:43 <holtmann> Hah. Didn't think it was.
Sep 02 23:03:50 <holtmann> Learned something new.
Sep 02 23:03:53 <dilinger> holtmann: ok, patches sent to the list
Sep 02 23:04:04 <denkenz> then rfcomm is wrong :P
Sep 02 23:06:24 <denkenz> btw, I actually think we should drop the whole tcp thing
Sep 02 23:06:30 <denkenz> I can make a proper phonesim driver
Sep 02 23:06:42 <denkenz> With a simple blocking connect to localhost
Sep 02 23:06:51 <denkenz> There's no other point for it
Sep 02 23:09:28 <denkenz> holtmann: btw, once we get multiplexers chat.c will be really really wrong ;)
Sep 02 23:10:12 <holtmann> dilinger: First patch applied. I leave the GAtSyntax to Denis since I am not familiar enough with it.
Sep 02 23:10:37 <denkenz> holtmann: its ok
Sep 02 23:10:57 <holtmann> So should I just go ahead and apply it?
Sep 02 23:11:04 <denkenz> yeah, worst case dilinger would have to fix it
Sep 02 23:11:10 <denkenz> its only used by the g1 driver anyway
Sep 02 23:14:26 <holtmann> dilinger: So patch patches are in. Feel free to work on the SMS stuff.
Sep 02 23:15:42 <dilinger> great, thanks
Sep 02 23:17:21 <holtmann> dilinger: Looks way simpler now, doesn't it ;)
Sep 02 23:18:58 <holtmann> denkenz: Can you start with some initial bits on the GPRS atom. So I can focus on ConnMan plugin.
Sep 02 23:33:37 <dilinger> holtmann: indeed
Sep 02 23:37:04 <dilinger> how about something like this?
Sep 02 23:37:04 <dilinger> http://git.collabora.co.uk/?p=user/dilinger/ofono-g1-new;a=commitdiff;h=452f7e49908642caaaba69a31fb5f40a9402511a
Sep 02 23:43:58 <holtmann> Looks good enough for me. Wait for Denis to ack it.
Sep 03 00:10:21 <denkenz> holtmann: Actually I need to do CellBroadcast first
Sep 03 00:15:29 <denkenz> dilinger: patch looks good
Sep 03 00:16:31 <denkenz> dilinger: Send to ML
Sep 03 00:53:00 <denkenz> holtmann: http://pastebin.ca/1552166
Sep 03 00:53:07 <denkenz> holtmann: I'm thinking I simply git rm generic_at.*
Sep 03 00:57:41 <denkenz> holtmann: Modems being emitted wrongly bug fixed
Sep 03 01:39:30 <holtmann> denkenz: What is since non-sense with modem_create in phonesim_init(). Let modemconf.c do that.
Sep 03 01:42:12 <denkenz> holtmann: phonesim is the only one that needs tcp
Sep 03 01:42:28 <denkenz> holtmann: So question is, do we want to bother making modemconf complicated
Sep 03 01:43:18 <holtmann> It is not complicated. It would actually work right now if you do [phonesim] Driver=phonesim.
Sep 03 01:43:55 <denkenz> holtmann: But then 'Device' key isn't used
Sep 03 01:43:56 <holtmann> Problem with you concept is that if you compile it in, it will always try to connect. Bad idea. I don't have have to disable a driver in configure to disable it.
Sep 03 01:44:10 <holtmann> We can start using if we want to and if someone cares :)
Sep 03 01:45:06 <denkenz> holtmann: So question is, do you even want to bother supporting Type=tcp, Type=unix?
Sep 03 01:45:33 <holtmann> I would just say. Right now we remove it. And if someone needs it for whatever reason, we add it later.
Sep 03 01:45:52 <denkenz> holtmann: Well the code is there
Sep 03 01:46:01 <denkenz> holtmann: So its easier to do it now anyhow
Sep 03 01:46:02 <holtmann> Let me take your phonesim.c and clean it up and.
Sep 03 01:47:01 <denkenz> holtmann: You only don't like this part right?
Sep 03 01:47:02 <denkenz>         phonesim = ofono_modem_create("phonesim");
Sep 03 01:47:04 <denkenz>         if (!phonesim)
Sep 03 01:47:05 <denkenz>                 return -ENOMEM;
Sep 03 01:47:07 <denkenz>         ofono_modem_register(phonesim);
Sep 03 01:47:09 <holtmann> I also will remove chat.c and use from_tty :)
Sep 03 01:47:21 <holtmann> And I need to update the config etc.
Sep 03 01:47:56 <denkenz> so what happened to nonblocking tty? :)
Sep 03 01:47:59 <dilinger> hm
Sep 03 01:48:10 <denkenz> my brain hurts, you change your mind faster than my 4 month old :P
Sep 03 01:49:01 <dilinger> so does the modem path change again with modemconf?
Sep 03 01:49:19 <denkenz> not because of modemconf
Sep 03 01:49:34 <denkenz> But because holtmann made me take out the node parameter to ofono_modem_create
Sep 03 01:49:47 <dilinger> so what's the path name now?
Sep 03 01:50:08 <denkenz> <drivertype><random number>
Sep 03 01:50:12 <denkenz> e.g. g15
Sep 03 01:50:29 <holtmann> denkenz: You said the non-blocking TTY is non-sense anyway. So why bother.
Sep 03 01:50:51 <denkenz> holtmann: But you said I was wrong
Sep 03 01:51:01 <dilinger> ah, i see
Sep 03 01:51:07 <dilinger> ok, thanks
Sep 03 01:51:18 <holtmann> Hey. I have now idea. If you say TTY open() is always blocking I believe you.
Sep 03 01:54:34 <denkenz> lol
Sep 03 01:57:21 <holtmann> Seriously.
Sep 03 01:57:43 <denkenz> ok, so what i'm saying was this:
Sep 03 01:58:00 <denkenz> chat.c the way it is was pointless, since it was using open with N_DELAY not set
Sep 03 01:58:19 <denkenz> which means open won't return until tty is truly open
Sep 03 01:58:45 <denkenz> If we want to do things simple, then use g_at_chat_from_tty
Sep 03 01:58:55 <denkenz> if we want to do things properly, use open + N_DELAY
Sep 03 01:59:26 <dilinger> great, verified that the SMS patch works
Sep 03 01:59:31 <dilinger> just sent to the list
Sep 03 02:02:01 <denkenz> whether this actually makes any difference on Linux, I've no idea :)
Sep 03 02:02:12 <denkenz> You know that better
Sep 03 02:06:22 <holtmann> Yeah. I have no clue either. I am just going with g_at_chat_from_tty now :)
Sep 03 02:06:37 <denkenz> holtmann: That's good enough for me
Sep 03 02:12:05 <denkenz> I wasn't fast enough 
Sep 03 02:12:13 <denkenz> dilinger: You should be happy now ;)
Sep 03 02:13:13 <dilinger> \o/
Sep 03 02:13:14 <dilinger> thanks :)
Sep 03 02:18:48 <denkenz> dilinger: And you were worried we wouldn't make end of the week ;)
Sep 03 02:19:39 <dilinger> hehe
Sep 03 02:19:59 <denkenz> holtmann: We still need to figure out how to handle auto power up
Sep 03 02:20:12 <denkenz> holtmann: And how to store the powered preferences for modems
Sep 03 02:21:10 <holtmann> denkenz: So are you okay with me removing generic_at.c ?
Sep 03 02:21:23 <denkenz> holtmann: yes
Sep 03 02:39:44 <holtmann> denkenz: Patch for parsing Device option pushed.
Sep 03 02:49:35 <holtmann> denkenz: So besides InitCommand etc. everything is ported over and ready to be used. generic_at.c is gone.
Sep 03 02:49:59 <denkenz> holtmann: Nod, init command is up to the individual driver anyway
Sep 03 02:50:24 <holtmann> And phonesim driver is not doing AT+CFUN=1 actually.
Sep 03 02:50:39 <denkenz> it doesn't need to
Sep 03 02:50:49 <holtmann> Good.
Sep 03 02:50:58 <denkenz> phonesim isn't smart enough to handle power up / down
Sep 03 02:52:01 <holtmann> Next step is then udev stuff.
Sep 03 02:52:07 <denkenz> Only thing we might consider is setting "Port" for phonesim
Sep 03 02:52:10 <denkenz> but that's minor
Sep 03 02:52:34 <holtmann> Done that already :)
Sep 03 02:53:20 <denkenz> don't see it yet
Sep 03 02:53:29 <holtmann> Pull again.
Sep 03 02:53:51 <denkenz> yep, ok, cool
Sep 03 02:54:39 <denkenz> Yes, so I'm happy with this now
Sep 03 02:55:04 <holtmann> Me too.
Sep 03 02:55:29 <holtmann> Cleaner and simpler :)
Sep 03 02:56:22 <denkenz> yep
Sep 03 02:57:19 <holtmann> So should we just make a release out of it?
Sep 03 02:58:20 <denkenz> gimme a sec, let me test that phonesim still starts
Sep 03 02:59:27 <denkenz> yep, works for me
Sep 03 02:59:30 <denkenz> So its all good :)
**** ENDING LOGGING AT Thu Sep 03 02:59:57 2009

**** BEGIN LOGGING AT Thu Sep 03 02:59:57 2009
Sep 03 03:03:14 <holtmann> dilinger: So I remove the hardcoded device node now. Make sure your modem.conf has Device=/dev/smd0
Sep 03 03:04:42 <holtmann> denkenz: Ran the build system test on my build machine. All is good.
Sep 03 03:04:43 <dilinger> cool, will do
Sep 03 03:05:29 * dilinger looks forward to 0.4 being autobuilt for debian, and just being able to use the arm package
Sep 03 03:05:41 <holtmann> We are just talking about doing 0.4 now.
Sep 03 03:05:49 <holtmann> denkenz: Any patches or features you have ready.
Sep 03 03:06:43 <denkenz> nope
Sep 03 03:06:53 <holtmann> So should we just go ahead?
Sep 03 03:07:03 <denkenz> lets live dangerously :)
Sep 03 03:22:27 <holtmann> So last chance guys. Otherwise I will be building 0.4
Sep 03 03:45:56 <holtmann> And now it is too late. The ofono-0.4 tarballs are uploading.
Sep 03 03:46:31 <holtmann> dilinger: And welcome to the AUTHORS file :)
Sep 03 03:47:05 <denkenz> btw, I might have missed a few guys in that
Sep 03 03:48:49 <holtmann> For the ones where I applied the patches, I updated it.
Sep 03 03:49:22 <denkenz> But Aki hasn't
Sep 03 03:50:47 <denkenz> So we're missing Alexander Kanavin, Ismo Puustinen
Sep 03 03:50:56 <denkenz> Shane Bryan, Luiz & Johan
Sep 03 03:51:14 <denkenz> Oh and Santtu Lakkala
Sep 03 04:41:36 <denkenz> Ok I updated AUTHORS
Sep 03 06:51:51 <holtmann> denkenz: So now the udev plugin can auto-detect Ericsson MBM devices.
Sep 03 07:40:23 <holtmann> denkenz: Still around?
Sep 03 10:33:36 <dagger> ping holtmann
Sep 03 10:35:28 <dagger> why does ofono-0.4 install empty dir /var/lib/lib/ofono ?
Sep 03 10:42:44 <dagger> ok nvm I can override localstatedir
Sep 03 10:43:39 <courmisch> hmm looks wrong indeed
Sep 03 10:44:24 <dagger> well my distro defaults localstatedir to /var/lib, so I need to override it to localstatedir=/var
Sep 03 10:53:48 <inz> It also installs conf to /usr/etc/ofono
Sep 03 10:53:57 <inz> Which can be overridden with sysconfdir
Sep 03 11:05:15 <courmisch> but that is normal
Sep 03 11:05:32 <courmisch> normally, the packaging system will --sysconfdir=/etc
Sep 03 11:11:10 <inz> Somewhere along the line it installed to /etc
Sep 03 11:13:21 <inz> Oh, no it didn't, sry
Sep 03 11:13:33 <inz> The generic_at.conf wasn't installed at all
Sep 03 14:51:31 <denkenz> inz: generic_at.conf is gone
Sep 03 14:51:44 <denkenz> inz: as is generic_at plugin
Sep 03 14:51:51 <inz> denkenz, yeah, I noticed
Sep 03 14:52:13 <inz> denkenz, and there was no .conf installed when it was there, you had to write it all manually
Sep 03 14:52:20 <inz> denkenz, my memory was just failing me
Sep 03 14:59:27 <denkenz> inz: Yah, I didn't write the automake rules for generic_at
Sep 03 14:59:49 <denkenz> inz: I didn't like it the way it was initially, was a first attempt
Sep 03 15:01:47 <inz> Is there any real difference between the plugins (except maybe g1)
Sep 03 15:03:42 <denkenz> The gprs ones not really
Sep 03 15:03:52 <denkenz> however that's because there's not proper hw integration
Sep 03 15:04:11 <denkenz> most will likely need a GAtSyntax specific to bugs in the particular modem
Sep 03 15:04:19 <denkenz> And also custom GPRS drivers for each one
Sep 03 15:04:38 <denkenz> + any quirks added
Sep 03 15:04:49 <denkenz> Proper modems will also likely need to implement their own voicecall driver
Sep 03 15:05:06 <denkenz> But at least the framework is there and we're happy with it
Sep 03 15:13:00 <inz> Btw, is the order of response to Dial and PropertyChanged:Calls signal guaranteed to be that?
Sep 03 15:13:43 <inz> I haven't actually tried what happends, but it would seem like a good idea
Sep 03 15:15:08 <denkenz> inz: guaranteed to be what?
Sep 03 15:16:18 <inz> That the Dial method response comes before the PropertyChanged notify
Sep 03 15:17:17 <denkenz> inz: Ok, so with regard to that, there are no guarantees
Sep 03 15:17:34 <denkenz> inz: However, voicecalls does try to be nice in that respect when it can
Sep 03 15:18:01 <inz> k
Sep 03 15:18:43 <inz> Then I guess there's a need to prepare for the "wrong" order with a delay or something.
Sep 03 15:20:14 <denkenz> why?
Sep 03 15:22:08 <denkenz> you're always going to be in sync since a signal or reply arrives
Sep 03 15:22:32 <denkenz> some parts like voicecalls its tricky, and to some extent you can rely on oFono to make it nice for you
Sep 03 15:23:02 <denkenz> But other parts doing a SetProperty might result in signal firing before set property returns
Sep 03 15:23:32 <inz> I was talking about the Dial -method
Sep 03 15:24:12 <inz> So if VoiceCallManager is nice with it, then no prob
Sep 03 15:25:19 <denkenz> That one _should_ always return before signaling
Sep 03 15:25:36 <inz> ok; that's enough for me
Sep 03 15:25:47 <inz> I'll yell at you on IRC if it doesn't ^^
Sep 03 15:26:16 <denkenz> nod
Sep 03 16:30:25 <holtmann> dagger: pong
Sep 03 16:32:00 <holtmann> denkenz: I have serious problems with some of my data cards :(
Sep 03 16:32:34 <denkenz> holtmann: Turn on AT debugging and lets see what they do
Sep 03 16:32:53 <denkenz> parser that comes with gatchat is _really_ _really_ strict
Sep 03 16:36:27 <holtmann> ofonod[23987]: > AT+COPS=0\r
Sep 03 16:36:27 <holtmann> ofonod[23987]: < AT+COPS=0\r
Sep 03 16:36:27 <holtmann> ofonod[23987]: < \r\nOK\r\n
Sep 03 16:36:27 <holtmann> ofonod[23987]: > AT+CREG?\r
Sep 03 16:36:27 <holtmann> ofonod[23987]: < AT+CREG?\r
Sep 03 16:36:28 <holtmann> ofonod[23987]: < \r\n+CREG: 2,2\r\n\r\nOK\r\n
Sep 03 16:36:41 <holtmann> Novatel cards when calling test-network-registration default.
Sep 03 16:36:52 <holtmann> It stays and sits there forever.
Sep 03 16:37:08 <denkenz> that looks fine
Sep 03 16:38:25 <denkenz> so basically what its saying is
Sep 03 16:38:29 <denkenz> I'm now in searching mode
Sep 03 16:38:43 <denkenz> You should get a signal from dbus stating that fact
Sep 03 16:38:59 <holtmann> {NetworkRegistration} [/novatel0] Status = searching
Sep 03 16:39:05 <holtmann> But it never succeeds.
Sep 03 16:39:09 <denkenz> oFono doesn't take any other action until netreg changes to something else
Sep 03 16:39:54 <denkenz> Ok so wild guesses:
Sep 03 16:40:16 <denkenz> you should be using +CGREG instead, some hardware is plain broken
Sep 03 16:40:26 <denkenz> or you need to poll the reg status
Sep 03 16:40:27 <holtmann> ofonod[23987]: < \r\n+CREG: 2,,\r\n
Sep 03 16:40:50 <denkenz> yeah that's bogus
Sep 03 16:40:51 <holtmann> And still nothing.
Sep 03 16:41:29 <denkenz> Can you get the novatel to work manually?
Sep 03 16:41:37 <holtmann> ofonod[23987]: > AT+COPS=0\r
Sep 03 16:41:37 <holtmann> ofonod[23987]: < AT+COPS=0\r
Sep 03 16:41:37 <holtmann> ofonod[23987]: < \r\nOK\r\n
Sep 03 16:41:37 <holtmann> ofonod[23987]: > AT+CREG?\r
Sep 03 16:41:37 <holtmann> ofonod[23987]: < AT+CREG?\r\r\n+CREG: 2,2\r\n\r\nOK\r\n
Sep 03 16:41:46 <holtmann> After calling test-netreg again.
Sep 03 16:42:16 <denkenz> same result, but oFono doesn't busy you there
Sep 03 16:42:25 <denkenz> since the register() method actually succeeded
Sep 03 16:42:38 <denkenz> Again, can you make it work manually?
Sep 03 16:42:54 <holtmann> AT+COPS=?
Sep 03 16:42:54 <holtmann> +COPS: (1,"Unknown","Unknown","302880",2)
Sep 03 16:42:54 <holtmann> +COPS: (1,"CAN Rogers Wirel","ROGERS","302720",0)
Sep 03 16:42:54 <holtmann> +COPS: (1,"CAN Rogers Wirel","ROGERS","302720",2)
Sep 03 16:43:23 <holtmann> AT+CREG?
Sep 03 16:43:23 <holtmann> +CREG: 2,2
Sep 03 16:43:38 <denkenz> so its still searching :)
Sep 03 16:43:42 <denkenz> Try +CGREG
Sep 03 16:43:58 <holtmann> AT+CGREG?
Sep 03 16:43:58 <denkenz> e.g. +CGREG?
Sep 03 16:43:58 <holtmann> +CGREG: 0,2
Sep 03 16:44:13 <denkenz> that one is also still searching
Sep 03 16:44:38 <holtmann> I also like the fact that we have 302880 now. Competition is coming :)
Sep 03 16:44:55 <denkenz> hehe
Sep 03 16:45:06 <denkenz> So your card is refusing to register
Sep 03 16:45:07 <holtmann> AT+COPS=1
Sep 03 16:45:42 <denkenz> that's not valid at btw
Sep 03 16:45:53 <denkenz> you have to give the oper
Sep 03 16:47:52 <holtmann> What is the correct AT+COPS= line. I don't have the spec open.
Sep 03 16:49:16 <denkenz> AT+COPS=2
Sep 03 16:49:25 <denkenz> AT+COPS=1,"mccmnc" I think
Sep 03 16:49:37 <denkenz> sorry
Sep 03 16:49:51 <holtmann> AT+COPS=2
Sep 03 16:49:51 <holtmann> ERROR
Sep 03 16:49:51 <holtmann> AT+COPS=1,"302720"
Sep 03 16:49:51 <holtmann> ERROR
Sep 03 16:49:58 <denkenz> its actually AT+COPS=3,2
Sep 03 16:50:19 <denkenz> AT+COPS=1,2,"mccmnc"
Sep 03 16:50:36 <denkenz> And you don't need the COPS=3,2
Sep 03 16:50:38 <denkenz> Been a while :P
Sep 03 16:51:13 <holtmann> No changes.
Sep 03 16:52:00 <denkenz> sprintf(buf, "AT+COPS=1,2,\"%s%s\"", oper->mcc, oper->mnc);
Sep 03 16:52:10 <denkenz> So that should work
Sep 03 16:52:12 <holtmann> That command hangs.
Sep 03 16:52:33 <denkenz> its probably just taking a while
Sep 03 16:54:48 <denkenz> I suspect your card is simply refusing to register for some reason
Sep 03 16:54:54 <denkenz> Maybe some special commands need to be used?
Sep 03 16:56:44 <holtmann> Still not finished.
Sep 03 16:57:34 <denkenz> btw, all your hardware drivers don't return EINPROGRESS on enable/disable
Sep 03 16:57:38 <denkenz> bad holtmann
Sep 03 16:57:54 <holtmann> I know.
Sep 03 16:58:52 <holtmann> Btw. which atoms beside netreg and sms might be useful for modem cards?
Sep 03 16:59:07 <denkenz> No idea, if we can't get COPS to work manually I've no idea whats wrong
Sep 03 16:59:09 <denkenz> sim
Sep 03 16:59:20 <denkenz> since that one will also do sim pin locks
Sep 03 16:59:30 <holtmann> Besides the Novatel card, which is weird.
Sep 03 16:59:42 <denkenz> devinfo
Sep 03 17:00:07 <denkenz> phonebook, maybe
Sep 03 17:07:17 <holtmann> ofonod[24772]: Could not register NetworkOperator /mbm0/operator/302720
Sep 03 17:07:29 <holtmann> So if the operator appears twice you are trying to register it twice.
Sep 03 17:07:59 <holtmann> ofonod[24772]: > AT+COPS=?\r
Sep 03 17:07:59 <holtmann> ofonod[24772]: < AT+COPS=?\r
Sep 03 17:08:00 <holtmann> ofonod[24772]: < \r\n+COPS: (2,"ROGERS","","302720",2),(2,"ROGERS","","302720",0),(1,"","","302880",2)\r\n
Sep 03 17:08:00 <holtmann> ofonod[24772]: < \r\nOK\r\n
Sep 03 17:08:00 <holtmann> ofonod[24772]: Could not register NetworkOperator /mbm0/operator/302720
Sep 03 17:08:24 <denkenz> yeah, we need to filter duplicates
Sep 03 17:08:34 <denkenz> I thought I did that, but apparently not
Sep 03 17:09:05 <denkenz> it should still work ;)
Sep 03 17:15:30 <holtmann> ofonod[25662]: > AT+CMGS=14\r
Sep 03 17:15:30 <holtmann> ofonod[25662]: < AT+CMGS=14\r
Sep 03 17:15:30 <holtmann> ofonod[25662]: < \r\n> 
Sep 03 17:15:30 <holtmann> ofonod[25662]: > 001100048102000000A704D4F29C0E<CtrlZ>
Sep 03 17:15:30 <holtmann> ofonod[25662]: < \r\n
Sep 03 17:15:31 <holtmann> ofonod[25662]: < 001100048102000000A704D4F29C0E
Sep 03 17:15:44 <holtmann> This is the Option HSO card and trying to send a SMS. After that it just is stuck.
Sep 03 17:16:53 <holtmann> Also the MBM card seems to be the only one that user unsolicited notifications for cell updates.
Sep 03 17:18:25 <denkenz> [12:07] <holtmann> ofonod[25662]: < \r\n
Sep 03 17:18:26 <denkenz> [12:07] <holtmann> ofonod[25662]: < 001100048102000000A704D4F29C0E
Sep 03 17:18:29 <denkenz> So that part is wrong
Sep 03 17:18:41 <denkenz> I suggest you send ATE0 to the modem to disable echo
Sep 03 17:18:50 <denkenz> As they've no idea how to echo properly
Sep 03 17:20:35 <denkenz> holtmann: it might be others are using +CGREG for cell updates
Sep 03 17:20:47 <denkenz> holtmann: Since they are GPRS cards it would actually make sense
Sep 03 17:20:58 <holtmann> ofonod[25662]: < 001100048102000000A704D4F29C0E
Sep 03 17:20:58 <holtmann> ofonod[25662]: < \r\n+CMS ERROR: 500\r\n
Sep 03 17:21:02 <holtmann> Month later it gets an error.
Sep 03 17:22:10 <denkenz> lol
Sep 03 17:22:12 <holtmann> ofonod[26071]: > AT+CMGS=14\r
Sep 03 17:22:12 <holtmann> ofonod[26071]: < \r\n> 
Sep 03 17:22:12 <holtmann> ofonod[26071]: > 001100048102000000A704D4F29C0E<CtrlZ>
Sep 03 17:22:12 <holtmann> ofonod[26071]: < \r\n
Sep 03 17:22:31 <holtmann> Same issue with ATE0Q0V1
Sep 03 17:22:43 <denkenz> why the fuck is it sending an extraneous \r\n
Sep 03 17:23:42 <denkenz> freaking christ, are monkeys implementing these modems?
Sep 03 17:23:56 <holtmann> Most likely actually ;)
Sep 03 17:28:25 <denkenz> sounds like at least the option doesn't have proper SMS
Sep 03 17:29:19 <denkenz> Btw, error 500 is a very helpful "Unknown Error"
Sep 03 17:29:25 <denkenz> gotta love it
Sep 03 17:37:23 <holtmann> Andy quick hack I could try?
Sep 03 17:39:25 <denkenz> no idea, this very much depends on the network, SIM, etc
Sep 03 17:39:33 <denkenz> Does the option card advertise SMS capability?
Sep 03 17:41:01 <holtmann> How to check?
Sep 03 17:41:21 <balrog-kun> you could try the text mode
Sep 03 17:42:55 <balrog-kun> although if the modem only supports text mode, it'll be rather difficult to write a backend for it
Sep 03 17:49:10 <dilinger> sweet, 0.4
Sep 03 17:49:31 <denkenz> balrog-kun: yah, good luck with that one :)
Sep 03 17:49:40 <denkenz> text mode is even more braindead than pdu mode
Sep 03 17:50:38 <denkenz> holtmann: one thing you can try is to set the SMS preferred transport to GPRS
Sep 03 17:50:39 <holtmann> How do I check if SMS is supported?
Sep 03 17:51:26 <balrog-kun> but i can imagine how a manufacturer only tests this
Sep 03 17:52:20 <denkenz> holtmann: Theoretically if the SMS driver registers
Sep 03 17:52:30 <holtmann> It does.
Sep 03 17:52:32 <denkenz> holtmann: Then everything the modem tells us is that SMS is supported
Sep 03 17:53:30 <denkenz> So I know some of these cards have a "GPRS-only" mode command
Sep 03 17:53:36 <denkenz> AFAIK Option does this
Sep 03 17:54:19 <holtmann> I have no idea on how to enforce this.
Sep 03 17:54:19 <denkenz> holtmann: Try AT+CGSMS=? 
Sep 03 17:54:23 <denkenz> AT+CGSMS?
Sep 03 17:54:37 <denkenz> holtmann: Yeah its some Option specific command
Sep 03 17:54:48 <holtmann> AT+CGSMS=?
Sep 03 17:54:48 <holtmann> +CGSMS: (0-3)
Sep 03 17:55:10 <holtmann> AT+CGSMS?
Sep 03 17:55:10 <holtmann> +CGSMS: 1
Sep 03 17:55:38 <denkenz> so its using circuit switched sms
Sep 03 17:55:53 <denkenz> Potentially if they turned off the circuit switched paths inside, sms won't work
Sep 03 17:55:57 <denkenz> pure speculation though
Sep 03 17:56:07 <holtmann> So which one is the GPRS one.
Sep 03 17:56:35 <denkenz> holtmann: 0 - Packet Domain
Sep 03 17:56:45 <denkenz> 2 - Packet Domain preferred (use circuit switched if GPRS not available)
Sep 03 17:57:03 <denkenz> however, you might have to attach GPRS first
Sep 03 18:02:50 <holtmann> Same problem.
Sep 03 18:03:31 <denkenz> then beats me
Sep 03 18:07:16 <denkenz> What is the card id/type
Sep 03 18:07:21 <denkenz> maybe google can do something for ya
Sep 03 19:14:18 <holtmann> denkenz: So the Huawei cards have a second TTY where you only receive unsolicited notifications. Can we feed that into GAtChat or can we just create a new instance only for that.
Sep 03 19:14:49 <denkenz> Right now you'd probably just create a new instance
Sep 03 19:14:49 <holtmann> ^RSSI:14
Sep 03 19:14:49 <holtmann> ^RSSI:17
Sep 03 19:14:49 <holtmann> ^MODE:3,3
Sep 03 19:15:01 <holtmann> Thins like this and also the +C... ones.
Sep 03 19:15:05 <denkenz> That is a weird setup though
Sep 03 19:15:28 <holtmann> I know. They wanna be able to do PPP and receives notifications at the same time.
Sep 03 19:15:51 <denkenz> Can you run commands on the second tty or just notifications?
Sep 03 19:15:54 <holtmann> Btw. this one supports SMS, but we can't detect it properly.
Sep 03 19:16:02 <holtmann> No commands on the second one.
Sep 03 19:16:27 <holtmann> So just using GAtChat and registering callbacks for notifications would work?
Sep 03 19:16:42 <denkenz> Yes, but you must also keep pointers to the individual atoms
Sep 03 19:16:51 <denkenz> since your notifications can be across atoms
Sep 03 19:17:52 <denkenz> at what point in the sms initialization does it bork?
Sep 03 19:18:37 <holtmann> It tells me that it is not supported.
Sep 03 19:18:46 <denkenz> yes, but where :P
Sep 03 19:19:02 <holtmann> Can we add support to GAtChat for a second fd (slave fd) for notifications only?
Sep 03 19:20:02 <denkenz> probably can
Sep 03 19:20:35 <holtmann> ofonod[31964]: > AT+CSMS?\r
Sep 03 19:20:35 <holtmann> ofonod[31964]: < AT+CSMS?\r
Sep 03 19:20:35 <holtmann> ofonod[31964]: < \r\n+CSMS: ,1,1,1\r\n\r\nOK\r\n
Sep 03 19:20:35 <holtmann> ofonod[31964]: SMS not supported by this modem.  If this is in error please submit patches to support this hardware
Sep 03 19:21:22 <denkenz> wtf
Sep 03 19:21:28 <denkenz> again, this is plain fucked
Sep 03 19:21:48 <denkenz> +CSMS: <service>,<mt>,<mo>,<bm>
Sep 03 19:21:55 <denkenz> <service> is not optional
Sep 03 19:22:21 <denkenz> try quirking it
Sep 03 19:22:28 <holtmann> How?
Sep 03 19:23:17 <denkenz> Well try manually forcing it into service=1 and see if it detects
Sep 03 19:23:22 <denkenz> then manually into service=0
Sep 03 19:23:27 <denkenz> see which one works
Sep 03 19:23:58 <denkenz> generally service=1 is preferred
Sep 03 19:24:04 <dilinger> yikes
Sep 03 19:24:07 <denkenz> since then we don't use the SIM
Sep 03 19:24:29 <holtmann> AT+CSMS=1
Sep 03 19:24:31 <holtmann> right?
Sep 03 19:24:35 <denkenz> yah
Sep 03 19:25:17 <denkenz> btw, that result was already result of AT+CSMS=<something>
Sep 03 19:26:01 <denkenz> actually lemme check
Sep 03 19:26:37 <denkenz> What does AT+CSMS=? report
Sep 03 19:27:52 <denkenz> our flow is -> AT+CSMS=?, pick the highest mode (1) if available
Sep 03 19:27:55 <denkenz> AT+CSMS=1
Sep 03 19:27:59 <denkenz> AT+CSMS?
Sep 03 19:28:14 <denkenz> make sure that <service> really is set, use that value
Sep 03 19:28:31 <holtmann> ofonod[32524]: > AT+CNMI=?\r
Sep 03 19:28:32 <holtmann> ofonod[32524]: < AT+CNMI=?\r\r\n+CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)\r\n\r\nOK\r\n
Sep 03 19:28:32 <holtmann> ofonod[32524]: > AT+CNMI=2,1,2,1,0\r
Sep 03 19:28:32 <holtmann> ofonod[32524]: < AT+CNMI=2,1,2,1,0\r\r\n+CMS ERROR: 303\r\n
Sep 03 19:28:32 <holtmann> ofonod[32524]: SMS not supported by this modem.  If this is in error please submit patches to support this hardware
Sep 03 19:28:49 <holtmann> If I force it to supported = TRUE.
Sep 03 19:29:09 <denkenz> try cnmi of 2,1,1,1,0
Sep 03 19:29:17 * dilinger has g1 flashbacks
Sep 03 19:29:57 <holtmann> AT+CSMS=?
Sep 03 19:29:57 <holtmann> +CSMS: (0-1)
Sep 03 19:29:57 <holtmann> OK
Sep 03 19:29:57 <holtmann> AT+CSMS?
Sep 03 19:29:57 <holtmann> +CSMS: ,1,1,1
Sep 03 19:30:35 <denkenz> yeah, that's just stupid
Sep 03 19:30:42 <holtmann> AT+CNMI=2,1,1,1,0
Sep 03 19:30:43 <holtmann> +CMS ERROR: 303
Sep 03 19:31:05 <dilinger> i highly doubt the majority of hardware out there will actually follow 27.00*
Sep 03 19:31:08 <holtmann> The notification will go via the ttyUSB1 anyway.
Sep 03 19:32:53 <holtmann> denkenz: If you have patches for the ttyUSB1 as slave inside GAtChat let me know. I am giving up right now.
Sep 03 19:33:18 <denkenz> holtmann: it isn't that simple, we need to discuss this
Sep 03 19:33:37 <denkenz> holtmann: Since we also need libgsm0710 and gatchat integration sometime too
Sep 03 19:34:07 <denkenz> try AT+CNMI=1,1,2,0,0
Sep 03 19:34:43 <holtmann> T+CNMI=1,1,2,0,0
Sep 03 19:34:43 <holtmann> OK
Sep 03 19:35:06 <denkenz> sounds like same issue as the G1
Sep 03 19:36:30 <denkenz> btw, I've no idea what CNMI mode is better
Sep 03 19:37:02 <denkenz> from the spec it sounds like 2 is better, but it probably has no bearing in reality
Sep 03 19:37:16 <holtmann> ofonod[313]: > AT+CMGF=0\r
Sep 03 19:37:16 <holtmann> ofonod[313]: < AT+CMGF=0\r\r\nOK\r\n
Sep 03 19:37:16 <holtmann> ofonod[313]: > AT+CRSM=192,28489,0,0,15\r
Sep 03 19:37:16 <holtmann> ofonod[313]: < AT+CRSM=192,28489,0,0,15\r
Sep 03 19:37:16 <holtmann> ofonod[313]: < \r\n+CME ERROR: invalid index\r\n
Sep 03 19:37:18 <holtmann> ofonod[313]: > AT+CPMS="ME","ME","ME"\r
Sep 03 19:37:20 <holtmann> ofonod[313]: < AT+CPMS="ME","ME","ME"\r
Sep 03 19:37:22 <holtmann> ofonod[313]: < \r\n+CPMS: 0,23,0,23,0,23\r\n\r\nOK\r\n
Sep 03 19:37:24 <holtmann> ofonod[313]: > AT+CNMI=?\r
Sep 03 19:37:26 <holtmann> ofonod[313]: < AT+CNMI=?\r
Sep 03 19:37:28 <holtmann> ofonod[313]: < \r\n+CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)\r\n\r\nOK\r\n
Sep 03 19:37:30 <holtmann> ofonod[313]: > AT+CNMI=1,1,2,1,0\r
Sep 03 19:37:32 <holtmann> ofonod[313]: < AT+CNMI=1,1,2,1,0\r
Sep 03 19:37:34 <holtmann> ofonod[313]: < \r\nOK\r\n
Sep 03 19:37:36 <holtmann> If setting the G1 quirk.
Sep 03 19:37:46 <holtmann> And forcing supported=true since service= is empty.
Sep 03 19:38:23 <dilinger> perhaps the quirk should be renamed to something else? :)
Sep 03 19:38:25 <denkenz> try send / receive sms
Sep 03 19:38:34 <denkenz> Yeah, like Ericsson ;)
Sep 03 19:39:28 <dilinger> i mean a generic non-vendor quirk
Sep 03 19:39:49 <dilinger> QUIRK_CNMI_BORKED
Sep 03 19:39:57 <denkenz> nod, we've flexibility with this
Sep 03 19:40:17 <denkenz> FORCE_CNMI_MODE_1 or something :P
Sep 03 19:41:24 <denkenz> holtmann: So your huawei device takes commands on usb0, but _all_ unsolicited notifications arrive on usb1
Sep 03 19:41:28 <denkenz> or just certain ones?
Sep 03 19:42:00 <denkenz> holtmann: e.g. what happens if an SMS arrives in GPRS online state?
Sep 03 19:42:13 <holtmann> No way of testing this right now.
Sep 03 19:42:13 <denkenz> or trying to send one?
Sep 03 19:42:37 <holtmann> ofonod[812]: > AT+CMGS=14\r
Sep 03 19:42:37 <holtmann> ofonod[812]: < AT+CMGS=14\r
Sep 03 19:42:37 <holtmann> ofonod[812]: < \r\n> 
Sep 03 19:42:37 <holtmann> ofonod[812]: > 001100048102000000A704D4F29C0E<CtrlZ>
Sep 03 19:42:37 <holtmann> ofonod[812]: < \r\n
Sep 03 19:42:38 <holtmann> ofonod[812]: < 001100048102000000A704D4F29C0E
Sep 03 19:43:03 <holtmann> ofonod[812]: < \r\n+CMS ERROR: 500\r\n
Sep 03 19:43:08 <denkenz> lol
Sep 03 19:43:08 <holtmann> Maybe that is my SIM card.
Sep 03 19:43:29 <denkenz> do you have your service center set right?
Sep 03 19:43:54 <denkenz> AT+CSCA?
Sep 03 19:54:43 <sabotage> holtmann: what's your stand on exposing the g_dbus_* APIs by putting the gdbus.h in includes and installing it?
Sep 03 19:56:00 <sabotage> I've got a plugin that needs some properties shared with clients and have tested/verified it works, but requires me to have a local copy of gdbus.h in my out-of-tree sources
Sep 03 23:34:06 <dilinger> ah, there it is
Sep 03 23:34:20 <dilinger> http://packages.qa.debian.org/o/ofono.html
Sep 03 23:45:20 <denkenz> hehe
Sep 04 02:16:09 <denkenz> holtmann: Is the Huawei modem the only one that has this weird unsolicited-only tty setup?
Sep 04 02:26:27 <denkenz> holtmann: Btw, that one most likely needs something special anyway, since there's no way to run any commands in online state
Sep 04 02:26:41 <denkenz> holtmann: Which means its just plain borked device
**** ENDING LOGGING AT Fri Sep 04 02:59:57 2009

**** BEGIN LOGGING AT Fri Sep 04 02:59:57 2009
Sep 04 03:25:53 <Robot101> maybe network manager knows how to make it work? :P
Sep 04 03:52:06 <denkenz> network manager has to do alot less
Sep 04 03:58:58 <denkenz> e.g. they bake in the online state into the assumptions in the core
Sep 04 03:59:02 <denkenz> We can't do that ;)
Sep 04 04:07:18 <tmzt> denkenz: is it muxed? I believe the gsm mux standard allows that to be configured
Sep 04 04:07:37 <denkenz> that's the problem, it seems huawei hardware is pre-muxed
Sep 04 04:08:04 <denkenz> so we get two tty ports, one of which doesn't accept any commands
Sep 04 04:08:13 <tmzt> right
Sep 04 04:08:23 <tmzt> I just mean that probably needs to be supported on other at devices as well
Sep 04 04:08:30 <tmzt> so it might be worth including support for it
Sep 04 04:08:38 <denkenz> we can support it
Sep 04 04:08:54 <denkenz> but the 'online' state handling has to be done in the driver, not the core
Sep 04 04:09:10 <denkenz> Which makes it different from the way the generic at drivers work
Sep 04 04:11:15 <denkenz> more thought required, if anyone has ideas let me know
Sep 04 05:29:13 <inz> Wouldn't it make more sense to just provide all config strings from the config file to the plugins and not hardcode "what does plugin xyz want"?
Sep 04 05:29:52 <inz> Oh yeah, you don't know the type, that's one problem
Sep 04 05:30:19 <inz> But that doesn't seem too extensible =)
Sep 04 05:34:43 <inz> Well, I guess the plugin system is going to see much more changes
Sep 04 14:11:18 <holtmann> sabotage: I am against out of tree plugins at this stage. Submit it for review.
Sep 04 14:12:13 <holtmann> denkenz: Btw. the laptop crashed on me yesterday and then I gave up. One reason why the SMS stuff stalled was that my SIM card didn't had SMS enabled. It is one of these MultiSIMs where only one can do SMS. Seems modems don't like them.
Sep 04 15:21:06 <denkenz> holtmann: Nod, well we need to talk about how to support some of these devices
Sep 04 15:36:04 <sabotage> holtmann: ok, I actually had the impression you prefered the history bits to be out of tree since it pulls in deps to libical and libecal
Sep 04 15:36:34 <sabotage> if you'd rather have it in tree, I'll work with raji to have it cleaned up and submitted
Sep 04 15:36:50 <sabotage> probably not till next week though
Sep 04 15:37:06 <sabotage> I'm heading out for a long holiday weekend shortly
Sep 04 15:53:11 <denkenz> akiniemi: Why do you have two tables / extension?
Sep 04 15:53:19 <denkenz> akiniemi: Can't we simply reverse the mapping?
Sep 04 15:54:10 <holtmann> sabotage: Why does the history plugin need g_dbus_* functions?
Sep 04 18:07:34 <sabotage> holtman: to expose a GetProperties method on a registered interface (org.ofono.CallHistory)
Sep 04 18:08:54 <sabotage> In the props we expose a string for the Backend type (ECal only right now), and the URI to the backend storage (calendar.ics fullpath) that the plugin is writing to
Sep 04 18:09:44 <sabotage> the model is that the plugin writes events to the ECal file and client apps interested in history will open and query the ECal file in RO mode
Sep 04 18:10:42 <sabotage> using the ECal signals to be notified of new events, rather than burdoning ofono with query handling and sending data streams over DBus
Sep 04 18:11:53 <sabotage> so the plugin only writes the data, does not send signals or handle data requests, only provides info needed for clients to get the data out-of-band
Sep 04 21:46:45 <dilinger> oooh
Sep 04 21:46:46 <dilinger> process 15540: arguments to dbus_message_new_signal() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1165.
Sep 04 21:46:49 <dilinger> This is normally a bug in some application using the D-Bus library.
Sep 04 21:46:52 <dilinger> ofonod[15540]: Unable to allocate new org.ofono.NetworkOperator.PropertyChanged signal
Sep 04 22:43:30 <denkenz> what is the path?
Sep 04 22:50:12 <denkenz> and what does your cops line return?
Sep 04 23:25:14 <dilinger> oh, uh
Sep 04 23:26:12 <dilinger> i don't think it's in my scrollback any more :/
Sep 04 23:26:21 <dilinger> the path was /g10
Sep 04 23:27:16 <dilinger> it was when it was powering off the modem (/g10 had already been powered on).  the SetProperty call succeeded, it was a signal after that (which nothing was listening for) that gave that error
Sep 04 23:27:27 <dilinger> so i'm looking at phonebook.import again..
Sep 04 23:27:37 <dilinger> ofonod[25473]: plugins/g1.c:g1_debug() < \r\n+CPBR: 1,"411",129,"00000000000000000000"\r\n+CPBR: 2,"611",129,"00000000000000000000000000"\r\n+CPBR: 3,"+18056377243",145,"00000000000000000000"\r\n+CPBR: 249,"#999#",129,"00000000000000000000000000"\r\n+CPBR: 250,"*233",129,"00000000000000000000"\r\n\r\nOK\r\n
Sep 04 23:28:02 <dilinger> i don't know where those 0's come from, but the android's contacts importer sees something different for each entry
Sep 04 23:28:38 <dilinger> for example, *233 has the header "Refill Now".  +18056377243 has "Voice Mail".  etc
Sep 04 23:31:51 <dilinger> hm, and phonebook entries are definitely coming from ril-daemon..
Sep 04 23:52:04 <dilinger> overall, i'm not impressed w/ android
Sep 04 23:58:45 <dilinger> it appears to be doing AT+PHSM=192,50,0,0,15\r to import the contacts
Sep 04 23:59:14 <dilinger> AT+PHSM=178,50,1,4,30                   
Sep 04 23:59:15 <dilinger> +PHSM: 144,0,3431312026204D6F7265FFFFFFFFFFFF038114F1FFFFFFFFFFFFFFFFFFFF
Sep 04 23:59:16 <dilinger> and so on
Sep 05 00:03:05 <holtmann> sabotage: Send it for review and then we see. I currently don't understand how you trying to make that work.
Sep 05 00:10:35 <dilinger> i can't find documentation of PHSM *anywhere*. :/
Sep 05 00:11:56 <denkenz> dilinger: PHSM is probably some HTC command
Sep 05 00:12:31 <denkenz> dilinger: Since the RIL is open for the G1, can you reverse engineer it?
Sep 05 00:12:50 <dilinger> denkenz: ril is only partially open, unfortunately
Sep 05 00:12:55 <dilinger> there's a binary blob..
Sep 05 00:13:06 <denkenz> Yuck
Sep 05 00:14:33 <dilinger> sh-4.0# strings /system/lib/libhtc_ril.so |grep PHSM
Sep 05 00:14:33 <dilinger> +PHSM: 
Sep 05 00:15:26 <dilinger> http://groups.fsf.org/wiki/Freest_hardware_comparisons/proprietary_G1_files  (libhtc_ril.so is in the proprietary list)
Sep 05 00:17:14 <denkenz> dilinger: ogsmd doesn't use this command though
Sep 05 00:19:12 <denkenz> dilinger: Check 3GPP 31.102, it sounds like the PHSM stuff is simply reading the SIM phonebook in the native format
Sep 05 00:20:31 <holtmann> denkenz: Wanna talk about the stupid Huawei stuff?
Sep 05 00:21:18 <denkenz> dilinger: For instance, 343131202620.. is GSM 7bit alphabet for '411 & ...'
Sep 05 00:21:23 <denkenz> holtmann: Sure
Sep 05 00:22:21 <holtmann> denkenz: So I am thinking that we should change GAtChat a little bit. For example just adding g_at_chat_attach(fd, flags) to allow adding multiple TTYs.
Sep 05 00:22:43 <dilinger> denkenz: hrm.  i'm looking at 31.102 and not finding "phsm" anywhere; what section are you looking at?  
Sep 05 00:22:59 <holtmann> And then have flags like ONLY_NOTIFICATIONS, FOR_PPP, FOR_COPS or something.
Sep 05 00:23:07 <dilinger> this is v7.3.0.  maybe there's something newer..
Sep 05 00:23:15 <denkenz> dilinger: Its not a command, but it might follow the same storage format as EFadn 
Sep 05 00:23:37 <denkenz> dilinger: Simce +PHSM follows rules _very_ similar to SIM file system
Sep 05 00:23:50 <denkenz> holtmann: Problem is we need multiplexer integration
Sep 05 00:24:05 <denkenz> holtmann: We can't just pass FDs
Sep 05 00:24:16 <denkenz> holtmann: Since a multiplexer uses 1 FD but talks stupid protocol
Sep 05 00:24:30 <holtmann> So you wanna have GAtChat with an abstraction for various multi-plexers.?
Sep 05 00:24:53 <denkenz> The way I was thinking was to have libg27010
Sep 05 00:25:02 <denkenz> You'd hand it 1 FD / serial port
Sep 05 00:25:09 <holtmann> While initially we might use a userspace one, but we also have to support a kernel one.
Sep 05 00:25:14 <denkenz> And then it can farm out GIOChannels for each multiplexer channe
Sep 05 00:25:16 <denkenz> +l
Sep 05 00:25:29 <denkenz> Then you can simply run GAtChat over each one
Sep 05 00:25:53 <holtmann> That sounds fine and would also work with chat_attach(GIOChannel).
Sep 05 00:26:20 <holtmann> However I question if we just not should integrate a multiplexer abstraction into GAtChat directyl.
Sep 05 00:26:22 <denkenz> So its probably better to simply use 2 GAtChats for things
Sep 05 00:26:48 <denkenz> Then each and every send/register needs to pass in a channel id
Sep 05 00:26:59 <denkenz> That becomes fun fast :)
Sep 05 00:27:05 <holtmann> I don't wanna use two GAtChat for this. It puts too much work on the drivers/atoms.
Sep 05 00:27:28 <denkenz> Problem is, some modems are pre-multiplexed
Sep 05 00:27:33 <denkenz> like your Huawei ones
Sep 05 00:27:36 <holtmann> Especially with the unsolicited notifications and some funny hardware.
Sep 05 00:27:38 <denkenz> or once we have kernel multiplexer
Sep 05 00:28:17 <holtmann> So I like to have an option to just use two GIOChannel as GAtChat input and it mixes them together for me.
Sep 05 00:28:49 <holtmann> And yes, I am fully aware of that Huawei is doing stupid things here.
Sep 05 00:29:02 <denkenz> So nothing except Huawei driver is likely to use this
Sep 05 00:29:21 <denkenz> Are you sure you want alot of extra complexity in GAtChat for this?
Sep 05 00:29:32 <holtmann> My idea would be just that we then can also define groups of AT commands that each channel inside GAtChat is running.
Sep 05 00:29:51 <holtmann> Like AT+COPS for example. Just run it on a second channel if available.
Sep 05 00:30:08 <denkenz> That intelligence is up to the driver, not atchat
Sep 05 00:30:27 <holtmann> Non of the atoms or drivers should care about such detail. How else do you wanna make it generic.
Sep 05 00:30:28 <denkenz> Besides, you can have up to 11 or so multiplexer channels
Sep 05 00:30:50 <denkenz> I want the generic drivers to receive a single atchat
Sep 05 00:31:02 <denkenz> it something needs something special, its up to the driver / modem plugin
Sep 05 00:31:37 <denkenz> Remember, theoretical maximum for GPRS-> 11 active contexts
Sep 05 00:31:45 <holtmann> For the Huawei the +CGREG for example and some others (like SMS) come via the notification channel.
Sep 05 00:31:49 <denkenz> so we need 11 + 2 = 13 multiplexers
Sep 05 00:32:14 <denkenz> Huawei hardware is useless for SMS, since if you're in online state, you can only receive, not send
Sep 05 00:32:33 <denkenz> right there you want a custom driver
Sep 05 00:32:39 <holtmann> So why don't we do this g_at_chat_attach(GIOChannel, flags) and then see what comes out of it. You don't have to use it, but the huawei plugin would.
Sep 05 00:33:20 <denkenz> _attach is not enough
Sep 05 00:33:22 <holtmann> If you use that hardware for online states. Some just use it for SMS text messaging.
Sep 05 00:33:45 <denkenz> Yeah, but you should either remove the SMS atom in online state
Sep 05 00:33:57 <denkenz> or simply error on the cmgs when in online state
Sep 05 00:34:04 <denkenz> both cases the generic driver is not enough
Sep 05 00:34:43 <holtmann> I am little bit worried that we get a lot of code duplication with having custom drivers everywhere.
Sep 05 00:35:04 <holtmann> There are more devices where you need to disconnected to send SMS/MMS and then re-connect (or suspend or something).
Sep 05 00:35:37 <denkenz> Hopefully not
Sep 05 00:35:53 <denkenz> That means you have a device with no multiplexer
Sep 05 00:36:08 <denkenz> If you have that, just pack up and go home
Sep 05 00:36:54 <holtmann> You can always get out of a PPP session, suspend it, send AT commands and get back on it.
Sep 05 00:37:12 <holtmann> Or at least the spec. allows it.
Sep 05 00:37:36 <denkenz> You can
Sep 05 00:37:44 <denkenz> But I'm not sure I want this logic in the core
Sep 05 00:38:51 <denkenz> So one way we can do this is 'powered' property for each atom
Sep 05 00:39:10 <denkenz> To simply say its not useable right now
Sep 05 00:39:46 <denkenz> Or figure out some way to check channel useability
Sep 05 00:41:03 <denkenz> and I don't like the _attach part, its easier to quirk the driver and make it accept two GAtChat instances
Sep 05 00:41:18 <denkenz> Hell, we can make all drivers accept two GAtChat instances
Sep 05 00:41:31 <denkenz> Since it would be useful for calls, gprs at least
Sep 05 00:44:36 <holtmann> Okay.
Sep 05 00:45:09 <holtmann> However we would still need a flag to GAtChat that says you can't send commands ;)
Sep 05 00:45:21 <denkenz> For normal operation simply pass both pointing to the same one
Sep 05 00:45:37 <denkenz> Yeah, that part is stupid.  Huawei was on drugs for doing it this way
Sep 05 00:45:57 <holtmann> They are all on drugs. And really good ones.
Sep 05 00:46:07 <denkenz> So ModemManager simply refuses to do anything in online state
Sep 05 00:46:16 <denkenz> But I'm not sure we can do that
Sep 05 00:46:16 <holtmann> zli47: /etc/ofono/modem.conf :)
Sep 05 00:47:17 <zli47> I modified it as : [btmodem] Driver=atmodem, Device = /dev/rfcomm0 but doesn't work
Sep 05 00:47:29 <holtmann> No we can not. ModemManager is a broken design anyway. It is PPP Manager converted from NetworkManager and then extended with SMS support.
Sep 05 00:47:32 <denkenz> dilinger: +PHSM: 144,0,3431312026204D6F7265FFFFFFFFFFFF038114F1FFFFFFFFFFFFFFFFFFFF
Sep 05 00:47:53 <denkenz> dilinger: So this part is formatted exactly like EFadn in 31.102 section 4.4.2.3
Sep 05 00:48:03 <holtmann> zli47: Driver=atmodem is not valid. We don't have a generic AT driver anymore.
Sep 05 00:48:16 <denkenz> dilinger: if you can figure out the syntax for PHSM we should be able to import the phonebook easily enough
Sep 05 00:48:28 <holtmann> denkenz: I think I need to add atgen.c driver.
Sep 05 00:49:04 <zli47> holtmann: but even I remove it, also doesn't work, what should I set ?
Sep 05 00:49:32 <holtmann> denkenz: Or you we call that atgen.c driver something different?
Sep 05 00:50:45 <denkenz> holtmann: say what?
Sep 05 00:50:56 <holtmann> I would just call it atgen.c now.
Sep 05 00:51:02 <denkenz> holtmann: what does that do?
Sep 05 00:51:22 <holtmann> You get Device=TTY and sets up everything use atmodem with no quirks.
Sep 05 00:52:00 <denkenz> ah, you mean for arbitrary devices
Sep 05 00:52:04 <denkenz> yeah that's fine
Sep 05 00:52:19 <holtmann> Yes.
Sep 05 00:52:59 <zli47> holtmann: I havent' my "modem"driver, because I use my phone as modem to test ofono. the generic_at is gone, then what should I set?
Sep 05 00:53:47 <denkenz> btw, I've added a permissive_v0 syntax to g_at_chat
Sep 05 00:53:53 <denkenz> I haven't pushed it yet
Sep 05 00:54:05 <denkenz> But that might be good to use for generic driver
Sep 05 00:55:21 <holtmann> Btw. what happens if we give syntax = NULL to GAtChat. Should we not have a default?
Sep 05 00:57:34 <denkenz> if syntax is NULL it fails right now
Sep 05 00:58:05 <denkenz> and if anything, there is no sane default :)
Sep 05 01:00:02 <denkenz> btw, we've ton of code duplication in modem plugins too ;)
Sep 05 01:02:10 <holtmann> zli47: Pushed. So just set Driver=atgen and Device= and you should be good to go.
Sep 05 01:02:22 <holtmann> See modem.conf examples.
Sep 05 01:03:13 <holtmann> denkenz: The code duplication in the modem plugins will go away once we start adding more and more support to them. Only now the look alike. Since they are not really useful. I just pushed that code to give people a starting point.
Sep 05 01:03:32 <denkenz> I know
Sep 05 01:16:33 <zli47> hotlmann: got it, thanks
Sep 05 01:58:57 <denkenz> holtmann: I just pushed a calypso voicecall driver
Sep 05 01:59:02 <denkenz> holtmann: Review it please
Sep 05 01:59:09 <holtmann> Looking at it now.
Sep 05 01:59:24 <denkenz> dilinger: I changed g1 driver to use the 'permissive' syntax from gatchat
Sep 05 01:59:52 <denkenz> dilinger: Its essentially g1 syntax, but let me know if it doesn't work
Sep 05 02:02:34 <holtmann> denkenz: Looks good to me.
Sep 05 02:18:02 <denkenz> holtmann: cool
Sep 05 02:46:05 <denkenz> holtmann: btw
Sep 05 02:46:10 <denkenz>         if (!g_strcmp0(driver, "g1") || !g_strcmp0(driver, "mbm") ||
Sep 05 02:46:11 <denkenz>                         !g_strcmp0(driver, "calypso"))
Sep 05 02:46:17 <denkenz> Might wanna add atgen
Sep 05 02:47:11 <denkenz> Or simply make that the default ;)
Sep 05 02:47:38 <holtmann> And remove mbm since that is auto-detect by udev now ;)
Sep 05 02:53:25 <holtmann> denkenz: About the GPRS stuff.
Sep 05 02:53:52 <holtmann> We need to split it between setup of context and actually then doing the connect/PPP/IP interface stuff.
Sep 05 02:54:19 <holtmann> The setup itself will be common. Besides the username/password thing.
Sep 05 02:57:40 <denkenz> sounds reasonable
Sep 05 02:58:02 <holtmann> Real problem is that I have no time to work on it. I really want that feature, but I am way too busy.
Sep 05 02:58:12 <denkenz> tell me about it
Sep 05 02:58:29 <holtmann> If we get it, I would just remove all the crap from ConnMan and just use it.
Sep 05 02:58:56 <denkenz> We need multiplexer, libgppp and mods to atchat first
Sep 05 02:59:14 <holtmann> No we don't. I would focus on the MBM and HSO ones first. They have highspeed interfaces.
Sep 05 02:59:17 <denkenz> Of course we can use devices that don't use ppp in the beginning
**** ENDING LOGGING AT Sat Sep 05 02:59:58 2009

**** BEGIN LOGGING AT Sat Sep 05 02:59:58 2009
Sep 05 03:00:01 <denkenz> So maybe Ismo gets us the interface impl soon
Sep 05 03:00:14 <denkenz> Since I really need to finish up some other parts before doing gprs
Sep 05 03:01:15 <denkenz> But we really need a solution for multiplexer and how atchat interacts with it
Sep 05 03:01:46 <denkenz> and more importantly how to handle 'online' bs
Sep 05 03:01:50 <holtmann> So which userspace lib where you thinking about it. I think we need to include one userspace implementation. And then later on give the option for a kernel one.
Sep 05 03:02:30 <holtmann> Should we just take the one FSO is using, clean that up and make its API sensible.
Sep 05 03:02:49 <denkenz> fso one is basically copy of whats in Qtopia
Sep 05 03:02:54 <denkenz> just made in c instead of c++
Sep 05 03:03:06 <denkenz> The main guts are in 0710muxd though
Sep 05 03:03:16 <holtmann> Still the question. Which one. FSO keeps using different things and re-writing themselves.
Sep 05 03:03:33 <denkenz> I say we just start from scratch and do it properly
Sep 05 03:03:41 <denkenz> We can base off Qtopia/fso in the beginning
Sep 05 03:03:59 <holtmann> Then you are in for a treat. As one person who has written one for RFCOMM, no thank so.
Sep 05 03:04:20 <denkenz> Trouble is, what fso has isn't good
Sep 05 03:04:27 <denkenz> There's no real easy way out
Sep 05 03:05:24 <holtmann> So I don't want an extra daemon with D-Bus interface. That is just overhead. I want an included library.
Sep 05 03:06:31 <denkenz> That's what I want as well
Sep 05 03:07:26 <denkenz> So I'm thinking something like libg27010
Sep 05 03:07:30 <holtmann> So libgsm0710mux is the Vala daemon non-sense.
Sep 05 03:07:53 <denkenz> Takes a tty port, has create/destroy channel
Sep 05 03:08:03 <holtmann> And libgsm0710 seems to be the good one.
Sep 05 03:08:11 <denkenz> Does some magic behind the scenes for gio integration
Sep 05 03:08:25 <holtmann> GIOChannel and not GIO.
Sep 05 03:08:34 <denkenz> yah, what I meant
Sep 05 03:08:47 <holtmann> Big difference from a lib dep point of view ;)
Sep 05 03:09:07 <denkenz> well, they have g_io_channel, hence gio, anyway, you get the point :)
Sep 05 03:09:10 <holtmann> Who sends the AT mux command?
Sep 05 03:09:17 <denkenz> the lib
Sep 05 03:09:29 <holtmann> So can we just name it libgatmux ;)
Sep 05 03:09:43 <denkenz> name's not really important
Sep 05 03:09:51 <denkenz> but yeah :)
Sep 05 03:10:17 <holtmann> I can start looking into if we get this code compiled with our strict set of compiler warnings. It looks like I would spent one day in just fixing that.
Sep 05 03:10:36 <holtmann> There is so much casting going on, that I might go blind.
Sep 05 03:10:54 <denkenz> again, I looked at it briefly and thought it sucked monkey balls
Sep 05 03:11:08 <holtmann> The spec. itself sucks. Trust me it is a nasty one.
Sep 05 03:11:09 <denkenz> Maybe its actually not bad if it were to be cleaned up
Sep 05 03:11:32 <denkenz> Shrug, after sms spec I'm not afraid of anything :)
Sep 05 03:12:10 <holtmann> And we should do the same as with GAtChat. One with GIOChannel, one with a native TTY devnode.
Sep 05 03:12:15 <holtmann> For the init that is.
Sep 05 03:12:28 <denkenz> Yeah potentially
Sep 05 03:12:40 <denkenz> Though I've never seen mux supported over anything except tty
Sep 05 03:12:54 <denkenz> But AFAIK even phonesim has rudimentary mux support
Sep 05 03:13:05 <holtmann> Actually the TTY layer in between is stupid if it is connected via SPI.
Sep 05 03:13:28 <denkenz> True, _from_tty is a wrapper anyway
Sep 05 03:13:32 <denkenz> its still GIOChannel in the end
Sep 05 03:14:06 <denkenz> The trickiest part is how to create n g_sources from a single file descriptor
Sep 05 03:14:09 <holtmann> Where is the original C++ code from Trolltech for this one. Any easy way to get it.
Sep 05 03:14:24 <denkenz> I can send it to you, hold on
Sep 05 03:15:06 <holtmann> Either we go via PTY or unix socket or we have to find a way.
Sep 05 03:15:24 <holtmann> Maybe GAtChat then also needs to take a GSource instead of GIOChannel ;)
Sep 05 03:15:42 <denkenz> well GIOChannel watch is essentially a g_source
Sep 05 03:15:54 <denkenz> And there are ways to hack into g_source to make it work
Sep 05 03:16:03 <denkenz> I even remember I thought up a way a few months back  :)
Sep 05 03:16:09 <denkenz> Forgot it now
Sep 05 03:16:15 <holtmann> I know, but originally it wasn't and that why it is kinda wrapped somehow.
Sep 05 03:17:20 <holtmann> Okay. So we can take that code, but then of course we have to do it properly and add GSource to it.
Sep 05 03:17:46 <holtmann> No need to go back and force via the kernel.
Sep 05 03:18:16 <holtmann> Meaning the API is totally bogus.
Sep 05 03:18:25 <holtmann> We need g_at_mux_new_from_tty()
Sep 05 03:18:44 <holtmann> g_at_mux_create_channel()
Sep 05 03:18:54 <holtmann> g_at_mux_release_channel()
Sep 05 03:19:28 <denkenz> yah, about that simple
Sep 05 03:19:36 <holtmann> And g_at_mux_unref()
Sep 05 03:20:30 <holtmann> Maybe some helpers for max channel numbers, some flags for weird quirks, but that is it.
Sep 05 03:20:54 <holtmann> Also then we can start using it now and just have a void muxer. One that has only one channel and does nothing at all.
Sep 05 03:20:58 <denkenz> yeah, the trickiest part is actually GIOChannel stuff
Sep 05 03:21:34 <denkenz> Since presumably even the fso/qtopia implementation works to some extent
Sep 05 03:22:21 <holtmann> I don't care. We need sort of different backend for it anyway. So just starting with a void/null/dummy one that only gets you max 1 channel. Would be a good idea.
Sep 05 03:22:50 <holtmann> So it basically hands you back the GIOChannel :)
Sep 05 03:22:57 <holtmann> Just with an extra reference count.
Sep 05 03:23:15 <denkenz> yah, but its a bit trickier than that
Sep 05 03:23:34 <denkenz> since the frames being read must only be destined to the particular virtual channel
Sep 05 03:23:38 <holtmann> Not for getting the API started and using it. Then we can have someone else actually work on the details.
Sep 05 03:23:50 <denkenz> True enough
Sep 05 03:24:26 <holtmann> So the core or driver just needs to read the max channel values. If it is one, it just have to deal with the fact that there is only one channel.
Sep 05 03:25:05 <denkenz> I think we might have to introduce some sort of limits knowledge into the core
Sep 05 03:25:34 <denkenz> But all of this requires lots of thought and experimentation
Sep 05 03:25:38 <holtmann> We do since some modem have limits on the number of muxes.
Sep 05 03:25:56 <denkenz> Yeah, but I was hoping to do it at the driver level
Sep 05 03:26:06 <denkenz> e.g. 1 active context, activate another -> error
Sep 05 03:26:16 <denkenz> The core doesn't have to know exactly why...
Sep 05 03:26:38 <holtmann> Something like that.
Sep 05 03:27:06 <denkenz> however, for your weird huawei hardware that won't work
Sep 05 03:27:11 <denkenz> :)
Sep 05 03:27:21 <holtmann> I know :(
Sep 05 03:27:23 <holtmann> http://www.freesmartphone.org/index.php/Implementations/dbus-hlid
Sep 05 03:27:31 <holtmann> That is btw. another fuckup of FSO.
Sep 05 03:28:01 <holtmann> The GSM mux with two libraries, one extra daemon and D-Bus between that and their GSM daemon is pure stupid. No wonder that this is slow.
Sep 05 03:29:06 <denkenz> yah, but a full telephony stack is just too much for them to bite off
Sep 05 03:29:21 <denkenz> Especially on the shit hardware they had
Sep 05 03:29:23 <holtmann> And Trolltech one is already GPLv2 and C only. Nice. We don't need the C++ class integration stuff.
Sep 05 03:29:46 <denkenz> fso one is just rehash of trolltech one
Sep 05 03:29:58 <denkenz> I think they simply cloned it
Sep 05 03:32:44 <holtmann> And put a copyright in there. I am not feeling to give them credit if they haven't done anything.
Sep 05 03:34:18 <holtmann> gatmux/gsm0710.c: In function ‘gsm0710_packet’:
Sep 05 03:34:19 <holtmann> gatmux/gsm0710.c:290: warning: ISO C90 forbids mixed declarations and code
Sep 05 03:34:19 <holtmann> gatmux/gsm0710.c: In function ‘gsm0710_ready_read’:
Sep 05 03:34:19 <holtmann> gatmux/gsm0710.c:331: warning: ISO C90 forbids mixed declarations and code
Sep 05 03:34:19 <holtmann> gatmux/gsm0710.c:348: warning: ISO C90 forbids mixed declarations and code
Sep 05 03:34:37 <denkenz> yah, remember its C++ ;)
Sep 05 03:34:40 <holtmann> Not too bad, but they cast like crazy. Have to remove these. Otherwise we are just hiding real errors.
Sep 05 03:35:51 <holtmann> Let me work on this a little bit so we have a clean history in GIT and can track where different sources came from.
Sep 05 03:36:52 <denkenz> yah, I can't keep track of the mux implementations
Sep 05 03:38:00 <denkenz> I think fso had 2?
Sep 05 03:38:10 <holtmann> Or three or five.
Sep 05 03:38:53 <denkenz> and they all just hacked versions of each other or new implementations?
Sep 05 03:39:50 <holtmann> Hacked. They have nothing written by themselves.
Sep 05 03:40:01 <holtmann> And if, then it would be in Python ;)
Sep 05 03:40:22 <denkenz> http://git.freesmartphone.org/?p=libgsm0710.git;a=summary
Sep 05 03:40:30 <denkenz> this one is at least definitely Qtopia one
Sep 05 03:41:54 <holtmann> And the you can't tell from the git history which is the original code. They mixed it in to begin with. I hate that. So besides hacking around everything they can't even keep a clean history.
Sep 05 03:42:24 <denkenz> Then there's this one http://git.freesmartphone.org/?p=gsm0710muxd.git;a=summary
Sep 05 03:42:40 <denkenz> And this one http://git.freesmartphone.org/?p=libgsm0710mux.git;a=summary
Sep 05 03:42:41 <denkenz> lol
Sep 05 03:43:12 <holtmann> Oh yeah. I fixed their autoconf magic for that one. That was a pain.
Sep 05 03:43:57 <holtmann> And again. As long as they do D-Bus as control interface it is bloody stupid.
Sep 05 03:44:11 <denkenz> it makes sense since they reuse pppd
Sep 05 03:44:18 <denkenz> But at a serious cost
Sep 05 03:44:43 <holtmann> And if you dig deep enough you find the kernel one from Motorola, which is a hacked version from OpenBT. And of course there is a userspace port of that one too somewhere.
Sep 05 03:45:14 <holtmann> pppd is another loose end. No idea why people keep holding on to it. Especially with GSM where the air protocol is not PPP at all.
Sep 05 03:45:45 <holtmann> You only need a minimal PPP implementation for these stupid modem without highspeed endpoints.
Sep 05 03:46:02 <denkenz> serial interface, reuse tech
Sep 05 03:46:09 <denkenz> Never think about how to do it properly :)
Sep 05 03:46:36 <holtmann> Dan Williams keeps telling me how create pppd and that it is maintained. It is not (but it does have a git tree, yeah) and every distro ships at least 20-30 different patches on top of it.
Sep 05 03:47:08 <holtmann> pppd should only be used for POTS and not for GSM.
Sep 05 03:47:47 <denkenz> yah, Qtopia had tons of hacks for various versions of pppd
Sep 05 03:48:24 <holtmann> So I like the MUX idea now. Simple and clean. No big overhead if we sort out the GSource part. We might not even need a kernel version of it.
Sep 05 03:48:47 <holtmann> Of course then pppd is out of the question, but I did wanna write libgppp anyway.
Sep 05 03:48:56 <denkenz> exactly :)
Sep 05 03:50:15 <holtmann> Okay. So let me do this. I create the proper history so we can track the Trolltech source code. Add gatmux and create the minimal API so we can use a simple passthrough/dummy with GAtChat.
Sep 05 03:50:22 <denkenz> All of it is terribly fun, but its going to take a while before we have a complete package
Sep 05 03:50:24 <holtmann> Then we have to find someone working on the GSource magic.
Sep 05 03:50:48 <denkenz> sounds good to me
Sep 05 03:51:21 <denkenz> btw, from the very beginning g_at_chat should have pluggable  implementations
Sep 05 03:51:25 <denkenz> so we can do kernel mux, etc
Sep 05 03:51:41 <holtmann> You mean g_at_mux :)
Sep 05 03:52:01 <denkenz> yeah g_at_mux
Sep 05 04:08:06 <holtmann> gatmux/gsm0710.c: In function ‘gsm0710_packet’:
Sep 05 04:08:06 <holtmann> gatmux/gsm0710.c:251: warning: comparison is always false due to limited range of data type
Sep 05 04:08:06 <holtmann> gatmux/gsm0710.c:254: warning: comparison is always false due to limited range of data type
Sep 05 04:08:06 <holtmann> gatmux/gsm0710.c:290: warning: ISO C90 forbids mixed declarations and code
Sep 05 04:08:06 <holtmann> gatmux/gsm0710.c: In function ‘gsm0710_ready_read’:
Sep 05 04:08:07 <holtmann> gatmux/gsm0710.c:331: warning: ISO C90 forbids mixed declarations and code
Sep 05 04:08:09 <holtmann> gatmux/gsm0710.c:348: warning: ISO C90 forbids mixed declarations and code
Sep 05 04:08:11 <holtmann> gatmux/gsm0710.c:353: warning: comparison is always false due to limited range of data type
Sep 05 04:08:13 <holtmann> gatmux/gsm0710.c:357: warning: comparison is always false due to limited range of data type
Sep 05 04:08:16 <holtmann> After removing the casting crap. No too bad actually.
Sep 05 04:08:38 <holtmann> Need to check if it would be endian safe. I guess not.
Sep 05 04:14:24 <denkenz> yah right :P
Sep 05 04:45:37 <holtmann> That code uses not memory allocation error checking :(
Sep 05 04:47:56 <denkenz> yah, c++ assumes it never fails
Sep 05 04:48:09 <denkenz> so some parts are lax
Sep 05 04:55:43 <denkenz> anyway I'm off, long weekend
**** ENDING LOGGING AT Sun Sep 06 02:59:57 2009

**** BEGIN LOGGING AT Sun Sep 06 02:59:57 2009
Sep 06 07:27:14 <eliasp> hi
Sep 06 07:32:48 <eliasp> i'm looking for an application/script/whatever to control ofonod ... i have ofonod up'n'running on Gentoo, but don't have the slightest clue how to configure or use it. tried it using D-Bus but it seems org.ofono is not introspectable... 
Sep 06 07:33:25 <eliasp> i want to use it to establish a data-connection via 3G/UMTS...
Sep 06 07:36:13 <eliasp> ah, found in the source tarball doc/modem-api.txt .. so tried now: "qdbus --system org.ofono.Modem" but all i get is "Service 'org.ofono.Modem' does not exist" ... do i have to load the modem plugin? am i using qdbus in a wrong way?
Sep 06 15:49:29 <balrog-kun> i don't think ofonod will be any help in setting up data connections right now
Sep 06 15:50:50 <balrog-kun> to get a org.ofono.Modem i believe you need to ask the Manager interface for list of modems and take the first one, provided you've set it up in ofono.conf in /etc somewhere
Sep 06 15:51:13 <holtmann> /etc/ofono/modem.conf and test with test/list-modems :)
Sep 06 15:51:42 <holtmann> If you have udev and USB modem sticks, they should be auto-detected. No need for /etc/ofono/modem.conf.
Sep 07 00:23:13 <tmzt> eliasp: you have an ebuild somewhere?
**** ENDING LOGGING AT Mon Sep 07 02:59:57 2009

**** BEGIN LOGGING AT Mon Sep 07 02:59:57 2009
Sep 07 12:03:43 <akiniemi> denkenz: about having two tables per single shift; they need to be sorted because I'm using bsearch()
Sep 07 12:06:22 <eliasp> tmzt: there's an ebuild in portage
Sep 07 12:22:53 <holtmann> akiniemi: I would help you, but I have no idea what you are talking about. And the US guys have labor day today :)
Sep 07 12:26:32 <inz> holtmann, can you comment on the PIN patch; will such functionality be included in oFono?
Sep 07 12:26:57 <inz> holtmann, I recall some discussion which said that oFono would not feed the code to ME
Sep 07 12:28:23 <holtmann> inz: It will, but I am leaving this up to Denis. However my personal take on the PIN stuff is that the general concept is non-sense and flawed.
Sep 07 12:31:12 <holtmann> akiniemi: Now I see. It is the language stuff.
Sep 07 13:30:57 <akiniemi> holtmann: yeah, my bad. /n'd only after I replied to denkenz. :)
Sep 07 14:53:23 <tmzt> holtmann: you are working on a new ppp daemon? will that support (or could it support) other mux protocols?
Sep 07 14:54:03 <holtmann> I am doing a mux integration with GIOChannel and GAtChat. If I get this old Neo1973 working.
Sep 07 14:54:21 <holtmann> And we will do a PPP library. The PPP daemon idea is bogus.
Sep 07 14:54:49 <tmzt> still using ldiscs in the kernel?
Sep 07 14:54:57 <tmzt> or all in userspace
Sep 07 14:55:48 <holtmann> The mux will be all in userspace, but no PTY or unix sockets or whatever. Direct integration.
Sep 07 14:56:09 <holtmann> I would have it finished but the mux part of phonesim is useless. It is actually broken.
Sep 07 14:56:30 <holtmann> Alternative is a kernel mux. If anyone ever writes a proper one.
Sep 07 14:56:50 <holtmann> So you can choose between them. Like the GAtSyntax stuff.
Sep 07 14:57:35 <holtmann> So for PPP we still need some more changes. No idea on how we do it if we don't have a file descriptor.
Sep 07 15:06:45 <holtmann> tmzt: If you know of any USB dongle that supports AT+CMUX, tell me. I am more than happy to buy one of these. All my cards don't support it.
Sep 07 15:07:14 <tmzt> no, I don'tt
Sep 07 15:26:25 <eliasp> holtmann: do you need a neo1973 for it or would a Freerunner (GTA02) suffice too? i could borrow you my Freerunner for a while if needed.... if this would help speeding up the development of the new PPP part for ofono?
Sep 07 15:27:00 <holtmann> Freerunner is just fine. I only happen to have 10 Neo1973 laying around from which are 8 dead.
Sep 07 15:27:13 <holtmann> Just upgraded the GSM firmware on one of them yesterday.
Sep 07 15:27:25 <holtmann> However the GSM passthrough via u-boot is crap.
Sep 07 15:27:51 <holtmann> And export the ttySAC0 over TCP, I have to write a program that does proper TTY settings first.
Sep 07 15:27:57 <eliasp> yeah, having Qi now on my FR... FR was my first OM phone, didn't have a Neo1973 before...
Sep 07 15:28:10 <holtmann> Haven't gotten that part yet.
Sep 07 15:28:13 <holtmann> What is Qi?
Sep 07 15:28:48 <eliasp> holtmann: Qi is some kind of "next-gen" bootmanager for the FR... http://wiki.openmoko.org/wiki/Qi
Sep 07 15:29:23 <eliasp> but uBoot is still there... the FR has 2 bootmanagers... on in NAND flash, one in NOR flash
Sep 07 15:29:37 <eliasp> you can choose which one to use at bootup by pressing the Aux key (or not)
Sep 07 15:30:07 <eliasp> so no matter whether you brick the NAND bootmanager, there's always the NOR to recover....
Sep 07 15:31:19 <eliasp> holtmann: if you're interested in having the FR for 2-3 months for playing around, query me your postal address... 
Sep 07 15:31:33 <eliasp> holtmann: you're living in the EU, right?
Sep 07 15:31:52 <holtmann> So Qi has no GSM passthrough. Hence pointless.
Sep 07 15:31:59 <eliasp> ah, ok... too bad ;(
Sep 07 15:32:09 <holtmann> I just ordered a Freerunner.
Sep 07 15:32:13 <eliasp> ah, ok
Sep 07 15:32:40 <holtmann> It still have the GTA01v1 and v2 somewhere.
Sep 07 15:34:05 <eliasp> hehe, vintage phones... ;-)
Sep 07 15:34:42 <holtmann> One of them doesn't even have a display. Funny guys in Taiwan send me only the board ;)
Sep 07 15:34:51 <eliasp> ;)
Sep 07 16:24:26 <tmzt> holtmann: I might suggest an ezx device but that has it's own problems
Sep 07 20:08:33 <denkenz> holtmann: AFAIK the GTA01 doesn't support mux properly
Sep 07 20:08:36 <denkenz> holtmann: FR does
Sep 07 20:11:25 <denkenz> akiniemi: Yeah I knew they were sorted, but didn't seem worth it at first.  But some of those tables are so big its probably worth the cpu cycle savings
Sep 07 20:13:11 <denkenz> akiniemi: Go ahead and push the changes, I'll see whether there's a nice way to make a single table for lookup
Sep 07 20:17:34 <denkenz> holtmann: Also checkout ser2net, handles all the serial port crap just fine
Sep 08 00:05:36 <holtmann> denkenz: Since when is the modem different in GTA01 and FR? I just updated my GTA01 modem to Moko11 firmware.
Sep 08 00:10:08 <denkenz> holtmann: Dunno, AFAIK Qtopia had problems with GTA01 mux
Sep 08 00:10:38 <holtmann> So do you have pre-configured ser2net package somewhere.
Sep 08 00:10:49 <holtmann> I did just cross-compiled it, but that is always a pain.
Sep 08 00:11:11 <holtmann> And the phonesim mux is a joke. Basic mode only and broken :(
Sep 08 00:11:34 <denkenz> e.g. neo multiplexer plugin:
Sep 08 00:11:39 <denkenz> QSerialIODeviceMultiplexer *NeoMultiplexerPlugin::create( QSerialIODevice *device )
Sep 08 00:11:40 <denkenz> {
Sep 08 00:11:42 <denkenz>     qLog(Hardware) << __PRETTY_FUNCTION__;
Sep 08 00:11:43 <denkenz>     if (isFreerunner)
Sep 08 00:11:45 <denkenz>         return new QGsm0710Multiplexer( device, NEO_FRAME_SIZE, true );
Sep 08 00:11:46 <denkenz>     return new QNullSerialIODeviceMultiplexer( device );
Sep 08 00:11:48 <denkenz> }
Sep 08 00:11:52 <denkenz> yeah I have a ser2net somewhere, lemme look
Sep 08 00:12:22 <holtmann> denkenz: I do have figured out on how we integrate GAtMux with GIOChannel (aka GAtMuxChannel). Just need to start testing it and fix the missing pieces.
Sep 08 00:12:43 <denkenz> nice, I wouldn't mind seeing it
Sep 08 00:12:53 <holtmann> I wouldn't mind getting it working.
Sep 08 00:13:12 <denkenz> sure, I'm just curios, I was thinking about how to do it as well
Sep 08 00:13:23 <denkenz> curios -> curious
Sep 08 00:14:02 <denkenz> Btw, unless we get ppp in userspace, GIOChannel might be the wrong way
Sep 08 00:14:07 <holtmann> So really define your own type of GIOChannel with proper ops. Then you need your own GSource and since you can use PollFD since you have no FD. You need a g_main_context_wakeup.
Sep 08 00:14:33 <holtmann> It is not. You can always assign a PTY in the background for it.
Sep 08 00:14:52 <holtmann> But if you talk directly with GAtChat to it, the PTY is waste of context switches.
Sep 08 00:15:28 <denkenz> btw, do you really need g_main_context_wakeup?
Sep 08 00:15:32 <holtmann> And btw. GAtMux will be part of gatchat. Works out way nicer this way. I have a function g_at_mux_create_chat(mux, syntax) now ;)
Sep 08 00:15:40 <denkenz> The way I was thinking was to simply call the proper callback :)
Sep 08 00:15:53 <holtmann> Not possible.
Sep 08 00:15:59 <denkenz> oh?
Sep 08 00:16:46 <denkenz> g_io_unix_dispatch simply calls the watch func
Sep 08 00:16:47 <holtmann> So the wakeup of your GIOChannel or GAtMuxChannel in this case is triggered by dispatch of its GSource. That can only be woken up by the main context.
Sep 08 00:17:16 <holtmann> g_io_unix_dispatch is part of GIOUnixSource. And that dispatch function is woken up via a FD ;)
Sep 08 00:17:25 <denkenz> Yeah, but you have the FD anyway
Sep 08 00:17:28 <denkenz> On the main serial port
Sep 08 00:17:48 <denkenz> You just simply peek at the id of the mux, and send it to the right one
Sep 08 00:17:53 <holtmann> We could do that, but that makes no difference since in the end it does the same g_main_context_wakeup.
Sep 08 00:18:27 <denkenz> nod, maybe just simpler :)
Sep 08 00:18:48 <holtmann> You think there is a shortcut, but there is not. It goes the full length via the main context anyway.
Sep 08 00:19:19 <denkenz> true, but doesn't g_main_context_wakeup cause an extra loop iteration?
Sep 08 00:19:22 <holtmann> Did you ever use ser2net. What is the correct config option for the FR.
Sep 08 00:19:55 <denkenz> yeah I have, lemme look
Sep 08 00:22:03 <denkenz> waits for his FR to bootup...
Sep 08 00:22:51 <denkenz> here's the ser2net.conf line I use:
Sep 08 00:22:55 <denkenz> 2000:raw:600:/dev/ttySAC0:115200 NONE 1STOPBIT 8DATABITS XONXOFF LOCAL RTSCTS
Sep 08 00:23:11 <denkenz> You want the ser2net bin itself?
Sep 08 00:25:01 <denkenz> Btw, can we use FUSE or CUSE or similar for ppp in userspace?
Sep 08 00:25:31 <holtmann> Why does this not work for me. I have serious issues with the serial port.
Sep 08 00:26:02 <holtmann> You mean TUN/TAP for it. Yes, we could.
Sep 08 00:27:25 <denkenz> Is there something like FUSE for sockets?  Since filesystem isn't quite what we need
Sep 08 00:27:26 <holtmann> When I use netcat on the host nothing happens. Does ser2net has a verbose mode somewhere hidden.
Sep 08 00:27:36 <denkenz> Did you turn the modem on?
Sep 08 00:27:47 <holtmann> Yes.
Sep 08 00:27:55 <denkenz> PATH=/bin:/usr/bin:/sbin:/usr/sbin
Sep 08 00:27:57 <denkenz> [ -f /etc/default/gsmd ] && . /etc/default/gsmd
Sep 08 00:27:58 <denkenz> [ -n "$GSM_POW" ] && ( echo "0" >$GSM_POW; sleep 1 )
Sep 08 00:28:00 <denkenz> [ -n "$GSM_POW" ] && ( echo "1" >$GSM_POW; sleep 1 )
Sep 08 00:28:01 <denkenz> [ -n "$GSM_RES" ] && ( echo "1" >$GSM_RES; sleep 1 )
Sep 08 00:28:03 <denkenz> [ -n "$GSM_RES" ] && ( echo "0" >$GSM_RES; sleep 2 )
Sep 08 00:28:05 <denkenz> No idea then :)
Sep 08 00:28:18 <denkenz> for me that script + ser2net just works
Sep 08 00:29:43 <holtmann> I stripped down my image to udev and networking. Nothing else.
Sep 08 00:30:49 <denkenz> try 
Sep 08 00:30:50 <denkenz> GSM_POW="/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on"
Sep 08 00:30:52 <denkenz> 		GSM_RES="/sys/bus/platform/devices/neo1973-pm-gsm.0/reset"
Sep 08 00:31:18 <holtmann> Now it works somehow. Problem with TTY it seems :(
Sep 08 00:31:21 <holtmann> Btw. one other thing. The calypso plugin should better be called freerunner or something.
Sep 08 00:31:28 <holtmann> It is not calypso specific.
Sep 08 00:31:45 <denkenz> fair enough
Sep 08 00:31:55 <holtmann> Or just call it moko since are using really short names ;)
Sep 08 00:32:04 <denkenz> Neo?
Sep 08 00:32:23 <holtmann> Did they still use the term neo for the freerunner?
Sep 08 00:32:34 <denkenz> No, just 1973
Sep 08 00:32:36 <holtmann> gta0x is also fine.
Sep 08 00:32:47 <denkenz> could name it gta0.. yeah, that's good enough
Sep 08 00:33:08 <holtmann> I would have just called it moko.
Sep 08 00:33:26 <holtmann> Nevermind. I just wanted to say, I need a calypsomodem variant that works over the network like phonesim.
Sep 08 00:34:05 <holtmann> If we call the current moko, I would just call the other mokosim ;)
Sep 08 00:34:06 <denkenz> just hack device property to send an IP address
Sep 08 00:34:21 <holtmann> Tried that, but with the power up stuff etc. it becomes messy.
Sep 08 00:34:23 <denkenz> Its only useful for development
Sep 08 00:34:30 <holtmann> So is phonesim.
Sep 08 00:34:47 <denkenz> Yeah, so lets fix phonesim to do proper mux
Sep 08 00:35:05 <holtmann> However we can add a hack to phonesim to support different modems.
Sep 08 00:35:10 <holtmann> That sounds better anyway.
Sep 08 00:35:22 <holtmann> Modem=calypso.
Sep 08 00:35:49 <denkenz> There's no difference, the only thing different is the CPI crap
Sep 08 00:36:13 <holtmann> And the phonesim only does basic mux, while the calypso only uses advanced mode.
Sep 08 00:37:05 <denkenz> nod, have you looked at what's involved in making phonesim do either?
Sep 08 00:37:17 <holtmann> No. C++ non-sense.
Sep 08 00:37:32 <holtmann> What is the deal with the keep-alive stuff. Seems like my modem shut itself down.
Sep 08 00:37:40 <holtmann> Now nothing works anymore.
Sep 08 00:37:52 <denkenz> yeah, you have send a command every 5 secs
Sep 08 00:37:57 <denkenz> otherwise it goes to bed
Sep 08 00:38:05 <denkenz> just send press enter twice
Sep 08 00:38:11 <holtmann> So far for good power management
Sep 08 00:39:06 <denkenz> Yeah, this is why g_at_chat_set_wakeup_command was invented
Sep 08 00:39:39 <holtmann> How do you wake the modem from this state?
Sep 08 00:39:52 <denkenz> Usually just a single \r should do it
Sep 08 00:39:58 <denkenz> after that it responds to commands
Sep 08 00:45:06 <holtmann> Does the calypso still need the AT+CFUN=1
Sep 08 00:45:43 <denkenz> yes
Sep 08 01:00:18 <holtmann> Hah. So that works now.
Sep 08 01:03:00 <holtmann> denkenz: Just add a line Modem=calypso to your phonesim config in modem.conf and it should do the trick.
Sep 08 01:07:53 <denkenz> yeah, that's a hack :P
Sep 08 01:08:22 <denkenz> and btw, you can probably enable sms/phonebook
Sep 08 01:08:36 <denkenz> you just simply have to give 10 seconds or so after powerup
Sep 08 01:09:15 <holtmann> I work on that once I have the mux done. But now I can do proper testing without the arm crap in between.
Sep 08 01:10:08 <holtmann> 	g_at_chat_send(data->chat, "AT%CUNS=0", NULL, NULL, NULL, NULL);
Sep 08 01:10:09 <holtmann> 	g_at_chat_send(data->chat, "AT%CSTAT=1", NULL, NULL, NULL, NULL);
Sep 08 01:10:09 <holtmann> 	g_at_chat_send(data->chat, "@ST=\"-26\"", NULL, NULL, NULL, NULL);
Sep 08 01:10:09 <holtmann> 	g_at_chat_send(data->chat, "%SLEEP=2", NULL, NULL, NULL, NULL);
Sep 08 01:10:09 <holtmann> 	g_at_chat_send(data->chat, "+CLVL=255", NULL, NULL, NULL, NULL);
Sep 08 01:10:09 <holtmann> 	g_at_chat_register(data->chat, "%CSTAT:", cstat_notify, FALSE,
Sep 08 01:10:11 <holtmann> 				modem, NULL);
Sep 08 01:10:41 <holtmann> Do you mind adding some comments to the calypso plugin so we know what each some does exactly. Looking it up on Google is annoying.
Sep 08 01:11:31 <holtmann> And btw. the hack is now only in a plugin that is meant for development only. So that is acceptable.
Sep 08 01:12:08 <holtmann> ofono_netreg_create(modem, OFONO_VENDOR_CALYPSO, "atmodem", data->chat);
Sep 08 01:12:18 <holtmann> What is that quirk for btw.?
Sep 08 01:12:18 <denkenz> yah hold on
Sep 08 01:12:55 <denkenz> that one simply register's calypso specific CSQ notification
Sep 08 01:13:09 <denkenz> It is sent unsolicited and carries a little more info
Sep 08 01:13:18 <holtmann> Okay.
Sep 08 01:16:03 <holtmann> Add these special quirks now, too.
Sep 08 01:16:15 <holtmann> For netreg and voicecall that is.
Sep 08 01:17:28 <denkenz> Ok, comments added
Sep 08 01:17:37 <denkenz> and I actually had AT missing from a few of them
Sep 08 01:18:04 <holtmann> So that was a bug. And I thought the modem was utterly broken. You never know ;)
Sep 08 01:18:20 <denkenz> Yeah, I was copy/pasting from ogsmd
Sep 08 01:18:26 <denkenz> That one sends AT magically :)
Sep 08 01:19:20 <holtmann> Stupid ogsdm.
Sep 08 01:19:35 <holtmann> So the disable deep-sleep is a good thing and needed or the wakeup thing is enough.
Sep 08 01:21:17 <holtmann> 	switch (data->state) {
Sep 08 01:21:18 <holtmann> 	case POWERCYCLE_STATE_POWER0:
Sep 08 01:21:18 <holtmann> 		if (write_file(CALYPSO_RESET_PATH, FALSE)) {
Sep 08 01:21:18 <holtmann> 			data->state = POWERCYCLE_STATE_RESET0;
Sep 08 01:21:18 <holtmann> 			return TRUE;
Sep 08 01:21:19 <holtmann> 		}
Sep 08 01:21:32 <holtmann> Also please add comments for the power cycle state machine. This looks like a bug.
Sep 08 01:21:42 <holtmann> CALYPSO_RESET_PATH should be CALYPSO_POWER_PATH
Sep 08 01:23:37 <holtmann> How does the muxer deal with this weird wakup \r command thing?
Sep 08 01:29:22 <denkenz> good question :)
Sep 08 01:30:27 <holtmann> And check the power stuff, it is different from what your script does.
Sep 08 01:30:52 <denkenz> its not
Sep 08 01:31:10 <denkenz> its just post-state, not pre-state
Sep 08 01:32:19 <holtmann> Then check the whole thing. You have three times the reset path and 1 time the power path.
Sep 08 01:32:58 <denkenz> it works just fine
Sep 08 01:33:02 <denkenz> power0, reset0
Sep 08 01:33:04 <denkenz> power1, reset1
Sep 08 01:33:06 <denkenz> reset0
Sep 08 01:33:22 <denkenz> it just starts in calypso_enable
Sep 08 01:33:25 <holtmann> Okay. Just checking.
Sep 08 01:52:01 <holtmann> So my gta01 with ser2net and ofonod on the host stack runs fine now.
Sep 08 01:52:19 <denkenz> nice
Sep 08 01:58:31 <holtmann> What is proper AT+CMUX command? Do you know it?
Sep 08 01:58:53 <holtmann> AT+CMUX=1,0,5,31 is what I send now.
Sep 08 01:59:16 <denkenz> I haven't read that part of the spec at all
Sep 08 01:59:23 <holtmann> Also I am thinking of using GAtChat for sending the AT+CMUX. Since the gsm0710.c of it is broken.
Sep 08 01:59:46 <denkenz> Seems silly to do it for 1 command
Sep 08 01:59:57 <denkenz> Can you just do a blocking read or something?
Sep 08 02:03:44 <holtmann> I can, but you might need special modem setup anyway. We will see.
Sep 08 02:04:34 <denkenz> perhaps, I've no idea whether e.g. CFUN needs to be done first
Sep 08 02:21:45 <holtmann> I can not do g_at_chat_shutdown(mux->chat) from a command callback?
Sep 08 02:33:54 <denkenz> I don't see why not
Sep 08 02:34:33 <denkenz> Just remember, shutdown is not instantenous
Sep 08 02:34:50 <holtmann> I know. Do we get the disconnect callback when it succeeds?
Sep 08 02:35:05 <holtmann> My muxer test program quits on me when I call shutdown.
Sep 08 02:35:06 <denkenz> You should, all it does is g_source_remove
Sep 08 02:35:34 <denkenz> So once we return from g_io_add_watch callback, the disconnect should fire
Sep 08 02:36:57 <denkenz> so there's this:
Sep 08 02:36:59 <denkenz>         if (chat->disconnecting)
Sep 08 02:37:00 <denkenz>                 return;
Sep 08 02:37:04 <denkenz> in read_watcher_destroy_notify
Sep 08 02:37:14 <denkenz> I've no idea why it is there now, but that could explain why its not firing
Sep 08 02:39:44 <denkenz> Not all of this was written when I was fully sober :)
Sep 08 02:41:14 <denkenz> ah ok I see
Sep 08 02:41:17 <denkenz> it makes sense, sorta
Sep 08 02:41:26 <denkenz> disconnect only fires when the other side hung up
Sep 08 02:41:33 <denkenz> Not if you trigger it manually
Sep 08 02:45:20 <holtmann> received data: condition 1
Sep 08 02:45:20 <holtmann> read: 7e 05 ef 41 54 2d 43 6f 6d 6d 61 6e 64 20 49 6e 74 65 72 70 72 65 74 65 72 20 72 65 61 64 79 0d 0a df 7e [35 bytes]
Sep 08 02:45:20 <holtmann> deliver data: 41 54 2d 43 6f 6d 6d 61 6e 64 20 49 6e 74 65 72 70 72 65 74 65 72 20 72 65 61 64 79 0d 0a [channel 1 with 30 bytes]
Sep 08 02:45:20 <holtmann> [Invalid UTF-8] AT-Command Interpreter ready
Sep 08 02:45:26 <holtmann> Here we go. Found my bug.
Sep 08 02:45:36 <holtmann> That is from a mux channel.
Sep 08 02:47:51 <denkenz> heh
Sep 08 02:48:36 <denkenz> It sends that string to each and every mux I guess
Sep 08 02:48:49 <denkenz> I imagine the timeout command is also needed for every mux as well
Sep 08 02:52:19 <holtmann> Maybe.
**** ENDING LOGGING AT Tue Sep 08 02:59:57 2009

**** BEGIN LOGGING AT Tue Sep 08 02:59:57 2009
Sep 08 03:10:50 <denkenz> holtmann: When you have time, comment on how you want the SIM PIN crap done.  That one should probably use ofono.Agent of some sort
Sep 08 03:12:24 <holtmann> Can we first a property UnlockRequired or something. That indicates a PIN is needed. And then an extra method Unlock() or similar.
Sep 08 03:12:46 <holtmann> So you have to call Unlock before Powered=true.
Sep 08 03:13:14 <denkenz> We can't actually do that, since we don't know the lock state until we power on
Sep 08 03:14:11 <denkenz> And we don't even have the SIM atom until powered is on
Sep 08 03:15:06 <holtmann> Crap.
Sep 08 03:15:22 <holtmann> I hate this SIM carp.
Sep 08 03:15:31 <denkenz> yah, tell me about it
Sep 08 03:15:54 <denkenz> We can't even cache the setting, since the PIN can be set while SIM is taken out 
Sep 08 03:16:25 <holtmann> Can we pre-stage this with Powered=true, then add SIM atom, then check PIN states and show UnlockRequired property. Then allow Unlock method, then go ahead.
Sep 08 03:16:51 <denkenz> sounds complicated
Sep 08 03:17:26 <denkenz> So most of the atoms already wait for internal sim_ready signal
Sep 08 03:18:20 <denkenz> We might be able to not register those interfaces until sim_ready is sent
Sep 08 03:21:22 <denkenz> Do you still want an ofono.Agent btw?
Sep 08 03:21:36 <denkenz> Since some of your todos in doc/ mention that is your preference
Sep 08 03:43:42 <holtmann> GLib-CRITICAL **: g_queue_peek_head: assertion `queue != NULL' failed
Sep 08 03:43:42 <holtmann> aborting...
Sep 08 03:43:50 <holtmann> Any idea how these happen?
Sep 08 03:44:32 <holtmann> denkenz: And yes, I do want a proper agent at some point, but for now it might be a little bit too much. Other details need to be sorted first.
Sep 08 03:49:32 <denkenz> holtmann: What are the circumstances?
Sep 08 03:49:50 <holtmann> Shutting down gatchat
Sep 08 03:50:47 <denkenz> hmm...
Sep 08 03:51:26 <holtmann> deliver data: [channel 1 with 31 bytes]
Sep 08 03:51:26 <holtmann> DEBUG: < \r\n+CGMR: "GSM: gsm_ac_gp_fd_pu_
Sep 08 03:51:26 <holtmann> deliver data: [channel 1 with 31 bytes]
Sep 08 03:51:26 <holtmann> DEBUG: < em_cph_ds_vc_cal35_ri_36_amd8_t
Sep 08 03:51:26 <holtmann> deliver data: [channel 1 with 12 bytes]
Sep 08 03:51:27 <holtmann> DEBUG: < s0-Moko11"\r\n
Sep 08 03:51:29 <holtmann> deliver data: [channel 1 with 6 bytes]
Sep 08 03:51:31 <holtmann> DEBUG: < \r\nOK\r\n
Sep 08 03:51:33 <holtmann> watch: prepare
Sep 08 03:51:35 <holtmann> watch: check
Sep 08 03:51:37 <holtmann> watch: dispatch
Sep 08 03:51:39 <holtmann> channel: read
Sep 08 03:51:41 <holtmann> DEBUG: < \r\n+CGMR: "GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko11"\r\n\r\nOK\r\n
Sep 08 03:51:43 <holtmann> channel: read
Sep 08 03:51:45 <holtmann> chat: callback [ok 1]
Sep 08 03:51:48 <holtmann> OK
Sep 08 03:51:50 <holtmann> (null)
Sep 08 03:51:52 <holtmann> GLib-CRITICAL **: g_queue_peek_head: assertion `queue != NULL' failed
Sep 08 03:51:54 <holtmann> aborting...
Sep 08 03:51:56 <holtmann> **
Sep 08 03:51:58 <holtmann> I open a mux, create a chat, issue CGMR, and in the callback I quite the mainloop.
Sep 08 03:53:31 <holtmann> Actually unref chat and then quit mainloop in the command callback.
Sep 08 03:53:42 <holtmann> But I do have seen this with some of plugins, too.
Sep 08 03:53:44 <denkenz> all shutdown does is cancel is the gsources
Sep 08 03:54:28 <denkenz> put a debug in g_at_chat_cleanup
Sep 08 03:54:32 <denkenz> does that one fire?
Sep 08 03:55:50 <denkenz> The only thing I can think of is that calling g_source_remove from within g_source is not valid
Sep 08 03:57:30 <holtmann> Yes. It calls g_at_chat_cleanup.
Sep 08 03:59:38 <holtmann> Putting the cleanup off with g_idle_add works.
Sep 08 04:00:18 <denkenz> ok
Sep 08 04:00:32 <denkenz> then the culprit is g_at_chat_finish_command
Sep 08 04:01:03 <denkenz> it does a bunch of cleanup after calling the callback
Sep 08 04:01:11 <denkenz> including a queue peek
Sep 08 04:02:32 <holtmann> So I do have the MUX working now. Hardcoded channel 1, but it seems to work fine.
Sep 08 04:03:14 <denkenz> try moving the following three lines:
Sep 08 04:03:16 <denkenz>         p->cmd_bytes_written = 0;
Sep 08 04:03:17 <denkenz>         if (g_queue_peek_head(p->command_queue))
Sep 08 04:03:19 <denkenz>                 g_at_chat_wakeup_writer(p);
Sep 08 04:03:25 <denkenz> up before if (cmd->callback) {
Sep 08 04:03:36 <denkenz> does unref from callback work then?
Sep 08 04:04:51 <denkenz> or simply ref,unref in that function
Sep 08 04:10:21 <holtmann> No idea. Have other problems now. Simple chat with mux works. ofonod doesn't.
Sep 08 04:10:30 <denkenz> heh
Sep 08 04:11:15 <denkenz> does it stall or crash?
Sep 08 04:13:42 <holtmann> It just spits out the warning.
Sep 08 04:15:33 <denkenz> hmm, ofono is totally broken...
Sep 08 04:22:09 <denkenz> holtmann: I pushed a fix that should allow unref from command callback
Sep 08 04:33:07 <holtmann> Do I need to know anything special about the ringbuffer?
Sep 08 04:33:23 <denkenz> maybe
Sep 08 04:33:33 <denkenz> are you using it in some way?
Sep 08 04:35:11 <denkenz> only the really low level stuff touches the ring buffer
Sep 08 04:37:24 <holtmann> If just using ring_buffer_write, ring_buffer_read and ring_buffer_len
Sep 08 04:37:40 <holtmann> I need that ringbuffer insider the muxer btw.
Sep 08 04:37:44 <holtmann> Not GAtChat.
Sep 08 04:38:20 <holtmann> So we do have some data copy going on here. Which is stupid.
Sep 08 04:38:34 <holtmann> Maybe that can be fixed.
Sep 08 04:38:46 <denkenz> not inside the ring buffer itself
Sep 08 04:39:11 <holtmann> mux->ringbuffer -> GIOChannel -> chat->ringbuffer :(
Sep 08 04:39:13 <denkenz> Check out how g_at_chat uses it, there's some trickiness when crossing the boundary
Sep 08 04:39:32 <holtmann> I assumed ring_buffer_read only returns until the boundary.
Sep 08 04:40:06 <denkenz> no, ring buffer read will return as much as you request
Sep 08 04:40:32 <denkenz> so if you're using the write ptr for read() syscall you have to be careful
Sep 08 04:41:35 <denkenz> ah ok, so mux / gatchat ring buffer copy is a bit nasty
Sep 08 04:43:12 <holtmann> ofonod[20615]: > AT+CFUN=1\r
Sep 08 04:43:12 <holtmann> write: [15 bytes, written 15 status 1
Sep 08 04:43:12 <holtmann> ofonod[20615]: > AT+CFUN=1\r
Sep 08 04:43:12 <holtmann> received data: condition 1
Sep 08 04:43:12 <holtmann> read: [4095 bytes, read 11 status 1]
Sep 08 04:43:13 <holtmann> deliver data: [channel 1 with 6 bytes]
Sep 08 04:43:15 <holtmann> ofonod[20615]: < \r\nOK\r\n
Sep 08 04:43:25 <holtmann> It stops after the AT+CFUN=1 on the muxed channel :(
Sep 08 04:44:03 <denkenz> Try running CFUN first, then running MUX
Sep 08 04:49:04 <denkenz> funny, gsm0710muxd sets cfun=0, then runs cmux
Sep 08 04:51:00 <holtmann> Same issue. So I assume my GAtMuxChannel is not signaling write ready.
Sep 08 04:51:20 <holtmann> ofonod[21734]: > AT+CFUN=1\r
Sep 08 04:51:20 <holtmann> received data: condition 1
Sep 08 04:51:20 <holtmann> read: [4095 bytes, read 11 status 1]
Sep 08 04:51:20 <holtmann> deliver data: [channel 1 with 6 bytes]
Sep 08 04:51:20 <holtmann> ofonod[21734]: < \r\nOK\r\n
Sep 08 04:51:26 <holtmann> I do get the okay part.
Sep 08 04:51:45 <denkenz> so its signaling the ready read, but not ready write?
Sep 08 04:52:25 <holtmann> It should.
Sep 08 04:55:05 <denkenz> All qtopia does is send CMUX in advanced mode with frame size of 644
Sep 08 04:55:07 <denkenz> err 64
Sep 08 04:55:35 <denkenz> e.g. AT+CMUX=1,0,115200,64
Sep 08 04:55:39 <denkenz> or something like that
Sep 08 04:56:11 <denkenz> So I suspect something is wrong in your glue between mux/atchat
Sep 08 04:57:26 <holtmann> deliver status: channel 1 with status 13
Sep 08 04:57:28 <holtmann> debug: received status line signal, sending response
Sep 08 04:57:29 <inz> denkenz, there was a commit message about blocking ATD, should this be supported now?
Sep 08 04:57:30 <holtmann> write: [9 bytes, written 9 status 1
Sep 08 04:57:32 <holtmann> check: 0x730730 watch cond 57 channel->cond 4
Sep 08 04:57:34 <holtmann> check: 0x72f070 watch cond 60 channel->cond 4
Sep 08 04:57:36 <holtmann> channel: write
Sep 08 04:57:38 <holtmann> ofonod[22266]: > AT+CFUN=1\r
Sep 08 04:57:40 <holtmann> write: [15 bytes, written 15 status 1
Sep 08 04:57:42 <holtmann> ofonod[22266]: > AT+CFUN=1\r
Sep 08 04:57:44 <holtmann> watch: 0x72f070 finalize
Sep 08 04:57:48 <holtmann> check: 0x730730 watch cond 57 channel->cond 4
Sep 08 04:57:50 <holtmann> check: 0x730730 watch cond 57 channel->cond 4
Sep 08 04:57:52 <holtmann> received data: condition 1
Sep 08 04:57:54 <holtmann> read: [4095 bytes, read 11 status 1]
Sep 08 04:57:56 <holtmann> deliver data: [channel 1 with 6 bytes]
Sep 08 04:57:58 <holtmann> ofonod[22266]: < \r\nOK\r\n
Sep 08 04:58:00 <holtmann>  So you remove the G_IO_OUT watch haver the writing. So we can signal whatever we want. oFono is not getting further.
Sep 08 04:58:03 <holtmann> * Disconnected (Connection reset by peer).
Sep 08 04:58:30 <denkenz> yah, but do you have commands pending?
Sep 08 04:58:45 <denkenz> oFono disconnects the write watcher since that one will keep firing constantly
Sep 08 04:58:56 <holtmann> I don't know. I am just using phonesim.
Sep 08 04:59:10 <denkenz> inz: blocking ATD has always been supported
Sep 08 04:59:15 <denkenz> inz: Not sure what you're asking
Sep 08 04:59:49 <inz> denkenz, at least when i last tried, the dial method returned only after atd diid
Sep 08 05:00:12 <denkenz> holtmann: So check what the command queue size is
Sep 08 05:00:21 <denkenz> holtmann: Maybe only that single CFUN is queued up?
Sep 08 05:00:38 <holtmann> How do I do that?
Sep 08 05:00:47 <denkenz> inz: g_queue_length?
Sep 08 05:00:51 <denkenz> err
Sep 08 05:00:59 <denkenz> holtmann: g_queue_length?
Sep 08 05:01:06 <denkenz> inz: That has always been the behavior on some modems
Sep 08 05:01:07 <holtmann> From not within gatchat.c
Sep 08 05:01:21 <denkenz> not possible
Sep 08 05:01:46 <holtmann> Crap. So that is useless now.
Sep 08 05:02:02 <inz> denkenz, ok, i thought such implementation detail would be hidden so that all modems acted alike
Sep 08 05:02:45 <denkenz> inz: possibly, the problem is those details belong at the driver level
Sep 08 05:02:58 <inz> sure they do
Sep 08 05:03:13 <denkenz> inz: So today some modems return from ATD immediately
Sep 08 05:03:15 <denkenz> some don't
Sep 08 05:03:20 <denkenz> oFono has no way of knowing
Sep 08 05:03:30 <inz> yeah
Sep 08 05:03:41 <denkenz> The best way is to simply make the driver implement the correct behavior
Sep 08 05:03:57 <denkenz> for instance, the calypso driver should probably return from ATD when it gets a CPI
Sep 08 05:04:12 <inz> i was just hoping for a reference solution ;)
Sep 08 05:04:22 <denkenz> In the driver or the core?
Sep 08 05:04:33 <inz> rdiver
Sep 08 05:05:06 <denkenz> So calypso driver will do this, it will synthesize atd return when CPI notification arrives
Sep 08 05:05:24 <inz> i guess ill just wait
Sep 08 05:05:49 <inz> i get my device to return from atd if i disable colp
Sep 08 05:05:51 <denkenz> otherwise, send a voicecall.c to the ML and I can suggest something
Sep 08 05:06:03 <inz> dont really know what i lose with that
Sep 08 05:06:16 <denkenz> But reference at driver cannot know, unfortunately
Sep 08 05:06:48 <denkenz> you'll lose connected party info
Sep 08 05:06:58 <denkenz> oFono synthesizes that if it doesn't receive it from the network
Sep 08 05:07:10 <denkenz> but ideally you want the updated version from the network
Sep 08 05:07:25 <inz> k
Sep 08 05:08:03 <inz> i guess ill just live with this and investigate further once the calypso does it
Sep 08 05:08:06 <denkenz> does your mode have vendor specific call progress indicators?
Sep 08 05:08:12 <denkenz> s/mode/modem
Sep 08 05:08:22 <inz> hmm, not sure
Sep 08 05:08:48 <inz> dont have the manual right now
Sep 08 05:09:21 <denkenz> most major vendors do, similar to PI on calypso
Sep 08 05:09:33 <denkenz> CPI
Sep 08 05:10:00 <denkenz> For proper voicecall integration you probably want to use those anyway
Sep 08 05:11:05 <inz> well, right now "it works" is nuff for me
Sep 08 05:11:35 <denkenz> holtmann: you probably want the g_io_channel_add_watch to integrate with mux watch somehow
Sep 08 05:12:07 <denkenz> holtmann: So that when write watcher is added, your main mux adds it too
Sep 08 05:12:10 <inz> the device will likely never see light, just the only modem i can do enough with
Sep 08 05:12:29 <denkenz> heh, nod
Sep 08 05:13:23 <denkenz> holtmann: But you want to do this anyway, since adding write watch permanently will never let you sleep
Sep 08 05:14:48 <denkenz> this reminds me I need to go into sleep mode myself
Sep 08 06:07:31 <holtmann> denkenz: So I have the multiplexer working. The G_IO_IN was missing due to the fucked up way how watch_prepare is a fast path.
Sep 08 06:09:12 <PaulFertser> denkenz: (gta01 modem) fyi there were some problem with communicating with calypso (the same device on both gta01 and gta02) because gta01's SoC has much smaller UART buffers and calypso firmware didn't properly support flow control until moko11.
Sep 08 06:10:22 <holtmann> Good that I have moko11 now on one of them.
Sep 08 06:11:29 <PaulFertser> holtmann: be careful upgrading those devices, in case you have a half-flashed modem you can't power it off unless you take out the battery and therefore you can access ROM BL again only once after real cold boot.
Sep 08 06:12:53 <PaulFertser> holtmann: btw, i'm surprised you folks still using that "shit hardware", i assumed you have access to much better devices with decent documentation ;)
Sep 08 06:13:04 <holtmann> Hah. Then I got lucky. Since I ended in half-flashed state and followed the documentation. And it works for me.
Sep 08 06:13:22 <holtmann> I need a GSM chip with AT+CMUX support.
Sep 08 06:13:31 <holtmann> Hard to come by these days.
Sep 08 06:14:55 <PaulFertser> holtmann: the documentation was prepared by us when we realised the only way to start BL on gta01 was to cold boot it and start fluid before turning the device on.
Sep 08 06:15:22 <holtmann> I followed that bit exactly. Worked fine for me.
Sep 08 06:15:43 <holtmann> I do have another GTA01 that I do wanna update, but I am short on time. Cost me a whole day. Including some fucked up distro install.
Sep 08 06:16:44 <PaulFertser> holtmann: these days it's easy, i just untarred the latest SHR unstable to my SD, flashed Qi and that was it. And btw you don't need any special distro to flash, any will do.
Sep 08 06:19:06 <PaulFertser> BTW, for many hackers gta02 will still be attractive comparing to N900 because of the astronomic prices and questionable openness of the latter. One can by a new FR for, like $200.
Sep 08 06:20:07 <holtmann> I ordered a FR for 200 EUR.
Sep 08 06:20:27 <holtmann> Hope it arrives before Friday. So I can take it with me to Portland.
Sep 08 06:21:12 <holtmann> I was looking into the FSO stuff and I hate it. Should look into SHR, but now I have a minimal system that just starts udev, networking and sshd.
Sep 08 06:21:48 <PaulFertser> holtmann: btw, are you planning to include some terminal emulator which will be able to access one of the MUX'd channels? FSO "shit" has a mini-terminal emulator that can just request a pty via "dbus nonsense" and that's it.
Sep 08 06:22:17 <PaulFertser> holtmann: SHR is just a distro that uses FSO underneath.
Sep 08 06:23:31 <holtmann> Then SHR is no use for me either. I have to build my own one. If I have time.
Sep 08 06:24:01 <holtmann> We will be locking into terminal access at some point. It is not that hard actually. Just have to map GIOChannel to a PTY.
Sep 08 06:24:37 <holtmann> I might just a config option that always creates an extra channel and maps it to a PTY.
Sep 08 06:24:54 <PaulFertser> holtmann: calypso is limeted to 4 channels btw
Sep 08 06:25:03 <holtmann> Yeah :(
Sep 08 06:25:29 <holtmann> Okay. I still have to solve the GIOChannel memcpy problem with have with my current code.
Sep 08 06:25:43 <PaulFertser> holtmann: you can debootstrap Debian on your SD and install anything you like on top of it. I'm told dpkg issues are fixed and debootstrap should work again.
Sep 08 06:25:49 <holtmann> Once that is gone, we have a pretty speedy implementation. Directly embedded into GAtChat :)
Sep 08 06:26:19 <holtmann> PaulFertser: Don't worry. I just build my own one with OE, but I need some free time for it.
Sep 08 06:27:10 <PaulFertser> holtmann: btw, do i understand it right that your idea of an ideal dbus api is almost direct mapping to end-user GUI elements? At least that was my impression after using bluez.
Sep 08 06:27:21 <PaulFertser> OE is a pain sometimes :-/
Sep 08 06:27:44 <holtmann> Yes. We are planning to model the D-Bus based on exactly what a UI and thus end user would need.
Sep 08 06:28:13 <holtmann> That way, we can achieve highest modem abstraction and make something like the Nokia PhoNet/ISI work the same way.
Sep 08 06:28:50 <PaulFertser> holtmann: but isn't it inherently limiting the UI by placing unnecessary assumptions about the UI architecture/ideas/etc?
Sep 08 06:29:04 <holtmann> Btw. I am also going to add a direct integration with BlueZ so that one terminal will be export as Bluetooth DUN ;)
Sep 08 06:29:56 <holtmann> We haven't really found them so far. And we tried really hard. I spend a lot of time with interaction designers and UI team.
Sep 08 06:29:57 <PaulFertser> DUN is sick :-/
Sep 08 06:30:07 <holtmann> But there would be your terminal ;)
Sep 08 06:30:34 <holtmann> The only limit we reached is when you need something hackish. And in that case we prefer to extend the daemon and not do it inside the UI.
Sep 08 06:31:20 <PaulFertser> holtmann: (ui team) i've never liked any UI of any conventional cellphone, so i don't trust the ui team. I'm afraid they're either filled or have to follow common templates to "meet user expectactions".
Sep 08 06:32:42 <PaulFertser> I meant their mind might be filled with templates and they lost flexibility and hacker imagination/attitude.
Sep 08 06:32:52 <holtmann> This is why you talk to interaction designers first :)
Sep 08 06:33:40 <PaulFertser> Do those guys "prefer nano over vim"? I guess that's of no use either then.
Sep 08 06:33:45 <holtmann> We go pretty hardcore with this. And our interaction designers have a deep technical knowledge how things work. And if it doesn't work out, we go back and kick them. Then they have to do it all over again.
Sep 08 06:34:34 <holtmann> BlueZ is just one evolution step further along, but we are getting there :)
Sep 08 06:35:59 <courmisch> mobile phones have the nasty property that standards and operators tend to require lots of stuff
Sep 08 06:36:16 <courmisch> so there is not so much for room for being innovative in terms or UI
Sep 08 06:36:28 <PaulFertser> For me bluez would be nice if there existed a simple and powerful commandline dbus introspection and interaction utility written in C (since i'm a console guy and i care about embedded too). dbus-send doesn't quite cut it, especially given it can't "stay on bus" that is required by some of bluez's API.
Sep 08 06:36:30 <courmisch> (still, there is some of course)
Sep 08 06:37:14 <PaulFertser> courmisch: you see the difference? No operator can require anything about freerunner's gui.
Sep 08 06:38:07 <holtmann> PaulFertser: I am working on that actually. Never got the time to finish it. We want bt for BlueZ D-Bus, cm for ConnMan D-Bus and one for oFono. Just have to come up with a shortcut ;)
Sep 08 06:43:24 <PaulFertser> holtmann: i tried emacs23 on freerunner and it looks like it can be the best platform to integrate much of the desired smartphone functionality. I bet your UI designers won't agree anyway :(
Sep 08 06:43:53 <courmisch> PaulFertser: that would be very cool if people bought their phone unlocked, but most dont
Sep 08 06:46:31 <PaulFertser> courmisch: to save additional $200? Well, those people i'm not caring about, they're probably not the ones i'm interested to talk with. One of the most attractive part of the GSM standard is that you can change your service provider easily. Simlock is a stupid measure to take that away. It's even harming market i guess.
Sep 08 06:49:01 <PaulFertser> Simlock is a very dirty trick in a bad sense.
Sep 08 06:50:01 <PaulFertser> Same as DVD regional locking. It's just unfair and anti-logical, i can't see how one can like it.
Sep 08 06:53:54 <holtmann> I am with you on that one. I hate SIM locks. Actually any kind of locking down of the phones is stupid. I would love to run oFono on my iPhone, but that is another story.
Sep 08 06:54:24 <PaulFertser> It's a funny feeling, all in all looks like you care about consumeristic "end-users" more than about "fellow hackers"...
Sep 08 06:54:33 <PaulFertser> (you==opensource developers)
Sep 08 06:55:05 <PaulFertser> Anyway, thanks for the interesting talk again, gtg. Happy coding :D
Sep 08 06:55:45 <holtmann> That is actually true since in the end it needs to be usable. And even UI programmers without deep GSM knowledge should be able to write own UIs for it.
Sep 08 06:56:16 <holtmann> So the goal is that writing a dialer application from scratch should not take longer than 2 days.
Sep 08 06:56:47 <PaulFertser> I never said there shouldn't be a high-level API (and yes, fso currently lacks that and many other things).
Sep 08 06:59:50 <PaulFertser> Heh, obviously your target is different: most hackers target "having fun along the way" and you target "usable UI". Well, that's life, i understand.
Sep 08 07:26:26 <holtmann> PaulFertser: We will see what we achieve.
Sep 08 07:28:14 <holtmann> denkenz: So I pushed the code for GAtMux now. It is by far from ready. Especially since it only supports one channel (kinda pointless I know). However it is starting point.
Sep 08 07:28:33 <holtmann> I also updated phonesim.c to allow using the multiplexer.
Sep 08 13:39:34 <holtmann> akiniemi: Some style issue ;)
Sep 08 13:39:36 <holtmann> +static const unsigned short portuguese_gsm[] =
Sep 08 13:39:37 <holtmann> +{
Sep 08 13:39:58 <holtmann> In these cases the { has to come after the =. Only for functions it goes on the next line. Minor detail.
Sep 08 14:38:15 <denkenz> holtmann: Do you sleep? :)
Sep 08 14:46:01 <holtmann> I did sleep. At least for a few hours ;)
Sep 08 14:46:28 <holtmann> I am jet-lagged and going back to the west coast on Staturday. So what is the point to adjust to this timezone.
Sep 08 14:46:42 <denkenz> heh
Sep 08 14:47:15 <holtmann> So GAtMux is in. Far from finished of course.
Sep 08 14:47:26 <denkenz> yeah looking at it now
Sep 08 14:47:33 <holtmann> And I am not sure how much time I have to get this ready.
Sep 08 14:48:06 <denkenz> you sure you wanna use g_io_channel_read_chars?
Sep 08 14:48:15 <denkenz> It does a bunch of useless crap
Sep 08 14:48:44 <holtmann> The GLib API says the other one is deprecated. I don't wanna use it. Just be a good citizen.
Sep 08 14:49:08 <holtmann> If you feel strongly we should use the other one, then fix it.
Sep 08 14:49:23 <denkenz> just that GAtChat uses plain _read
Sep 08 14:49:52 <holtmann> I know. And I did that too in the past, but read the GLib API docs. It says that one is deprecated.
Sep 08 14:50:09 <holtmann> Anyhow, I am fine either way. Really. Couldn't care less.
Sep 08 14:50:16 <denkenz> I know, but after looking at what _read_chars does, I ran away scared
Sep 08 14:50:49 <holtmann> Then lets use plain _read. I am fine that. Care to fix it?
Sep 08 14:51:16 <denkenz> yeah I can
Sep 08 14:51:41 <holtmann> So I have to work on getting actually two channel created and see how they work.
Sep 08 14:52:02 <holtmann> And the channel takedown is also missing. Same as the mux takedown. Currently I have power-cycle the mode.
Sep 08 14:52:27 <denkenz> heh
Sep 08 14:52:32 <holtmann> So we should put the netreg atom onto its own channel, right?
Sep 08 14:52:42 <holtmann> And maybe the SIM one, too.
Sep 08 14:52:57 <denkenz> I was thinking voicecalls get primary one
Sep 08 14:53:01 <denkenz> everything else on secondary
Sep 08 14:53:37 <denkenz> we can delay the period operator scan until we finish initializing
Sep 08 14:53:56 <holtmann> The moko hardware seems to support three. So first 1st voice, 2nd other stuff, 3rd PPP, 4th for Bluetooth DUN or something.
Sep 08 14:53:58 <denkenz> we can also use secondary mux from voicecalls to do outgoing call cancelation
Sep 08 14:54:15 <holtmann> s/three/four/
Sep 08 14:55:13 <denkenz> DUN is a bit tricky, but in the interim sounds fine
Sep 08 14:55:19 <holtmann> So either we update some atom with a second user_data param or a struct. Or you have to split atoms.
Sep 08 14:55:47 <holtmann> I am going to add a native Bluetooth DUN or SPP support into oFono. So avoid this weird data copy non-sense.
Sep 08 14:55:59 <holtmann> And yes, we want an AT command filter in front of it.
Sep 08 14:56:25 <denkenz> If we have that, then we can reuse the 4th mux
Sep 08 14:56:30 <denkenz> for something else
Sep 08 14:56:57 <holtmann> Not really. Since DUN might start PPP on it :(
Sep 08 14:57:12 <denkenz> And we have to think about two atchats part, easiest is to simply make up some struct
Sep 08 14:57:16 <holtmann> I just don't care right now. Just wanna demonstrate what is possible if you do it right.
Sep 08 14:57:52 <holtmann> Wanna create struct atmodem_data or so and share it between atom of atmodem driver?
Sep 08 14:58:30 <denkenz> Does GLib have a pair datastruct?
Sep 08 14:58:37 <denkenz> Or we can invent one
Sep 08 14:58:37 <holtmann> Nope.
Sep 08 14:59:06 <holtmann> Since we never will be needing more than two, I guess. Just having user_data1 and user_data2 might be fine, too.
Sep 08 14:59:23 <denkenz> famous last words :)
Sep 08 14:59:31 <holtmann> akiniemi: Your take on this? Since I assume isimodem never needs a second data parameter.
Sep 08 14:59:48 <holtmann> Seriously, for what does an atom wanna have three GAtChat?
Sep 08 15:00:35 <denkenz> I dunno, but I was thinking the same thing about 2 ~6 months ago ;)
Sep 08 15:00:36 <holtmann> We can also have some atom with only user_data1 and other have user_data1+user_data2.
Sep 08 15:00:58 <holtmann> So only the ones that would profit from it get two.
Sep 08 15:01:09 <denkenz> Nah, lets keep it consistent
Sep 08 15:01:21 <denkenz> Otherwise I go crazy
Sep 08 15:01:28 <holtmann> Your choice. Then we need an atmodem_data or atmodem_chat struct.
Sep 08 15:01:56 <holtmann> Or we can just create an GAtChatPair ;)
Sep 08 15:02:01 <holtmann> like socketpair ;)
Sep 08 15:02:17 <denkenz> lol
Sep 08 15:03:00 <denkenz> since we're already have shared headers (e.g. vendor.h) I don't really have a problem with that
Sep 08 15:03:08 <holtmann> Or GAtChatSet or GAtCollection or whatever.
Sep 08 15:03:29 <holtmann> Actually I now prefer to do that on GAtChat level.
Sep 08 15:03:55 <denkenz> do you wanna just pass the mux around instead of gatchat then?
Sep 08 15:03:57 <holtmann> I need the part for the read-only GAtChat anyway for the stupid Huawei.
Sep 08 15:04:14 <holtmann> No. Leave the mux out of it. Not all hardware has a mux.
Sep 08 15:04:25 <denkenz> with maybe some well-known names, like "primary", "secondary"
Sep 08 15:04:33 <denkenz> We can have mux drivers too btw
Sep 08 15:04:39 <denkenz> Simply secondary==primary
Sep 08 15:04:48 <denkenz> in case no hw support
Sep 08 15:05:05 <holtmann> Okay. That would work. If we just reference count it properly.
Sep 08 15:05:21 <holtmann> So something like g_at_mux_get_primary(syntax).
Sep 08 15:06:18 <denkenz> or g_at_mux_create(mux, "primary") in the driver
Sep 08 15:06:26 <denkenz> and g_at_mux_get(mux, "primary") in the atoms
Sep 08 15:07:02 <holtmann> We should auto-create them actually.
Sep 08 15:07:27 <holtmann> So g_at_mux_get_chat(mux, "primary", syntax) seems good enough to me.
Sep 08 15:07:28 <denkenz> someone has to tell the mux how many there are
Sep 08 15:07:59 <holtmann> And of course g_at_mux_get_channel(mux, "primary") would give you the IO Channel directly.
Sep 08 15:08:11 <denkenz> I'd rather have the driver set this up first
Sep 08 15:08:25 <denkenz> Since atoms should have no idea about the syntax
Sep 08 15:08:35 <denkenz> That is modem driver specific
Sep 08 15:08:36 <holtmann> So we need a g_at_mux_new(IOChannel, backend).
Sep 08 15:08:45 <denkenz> yes
Sep 08 15:09:05 <holtmann> Meaning I have to write GAtBackend first :(
Sep 08 15:09:27 <denkenz> You already have, just a few function pointers
Sep 08 15:09:48 <holtmann> libgatchat becomes the swiss army knife of GSM AT commands soon.
Sep 08 15:10:07 <denkenz> define 'soon' ;)
Sep 08 15:10:08 <holtmann> I am even thinking of GAtPPP integration with TUN/TAP and doing the whole PPP in user-space.
Sep 08 15:10:50 <denkenz> we have to do ppp in userspace, since we've no fd
Sep 08 15:11:05 <holtmann> We can get a fd, but not sure if it buys us anything.
Sep 08 15:11:06 <denkenz> So unless we use kernel userspace driver support of some sort...
Sep 08 15:11:26 <denkenz> Isn't ppp done in kernel?
Sep 08 15:11:34 <denkenz> E.g. ppp packets never reach userspace
Sep 08 15:11:49 <holtmann> We can create a PTY and then run ppp line discipline on it. Not sure if that is anybetter than doing the whole thing in userspace and then just copy it to the TUN/TAP device.
Sep 08 15:12:24 <denkenz> If we're going pty route, what makes us different from gsm0710muxd?
Sep 08 15:12:29 <holtmann> PPP packets never reach userspace, but they have to get from userspace to the kernel at least once. Unless the MUX is inside the kernel we loose one copy.
Sep 08 15:13:25 <holtmann> So I prefer instead of copy them to a PTY and then have the kernel PPP pick them up and turn them into ppp0. We do PPP in userspace and send them to a tun0.
Sep 08 15:14:26 <holtmann> The only downside with this is that ofonod then does PPP processing. However can't be that bad.
Sep 08 15:14:28 <denkenz> so we still do 1 extra copy, but without kernel mux its probably the best we can do
Sep 08 15:15:00 <denkenz> Well go find a ppp userspace implementation :)
Sep 08 15:15:36 <holtmann> We do the 1 copy at some point anyway. That is my point. However otherwise we involve PTY/TTY layer, line-discipline and network stack. Just not dealing with the TTY layer might be already a big win. Especially from a kernel locking point of view. TTY still use BKL a lot.
Sep 08 15:16:33 <denkenz> actually with pty you do more copies, no?
Sep 08 15:16:38 <holtmann> And at some point there was a userspace implementation of PAN profile btw. We might wanna do that for tethering again. So many things to play with.
Sep 08 15:16:39 <denkenz> 1 to the pty, 1 from pty to kernel
Sep 08 15:17:10 <denkenz> whereas userspace ppp, you only 1 to the kernel
Sep 08 15:17:16 <holtmann> For the AT command section yes, once the PPP line discipline is hooked into the PTY, it should only be one.
Sep 08 15:17:58 <denkenz> not sure how its going to get data from the main mux
Sep 08 15:18:14 <denkenz> you still have to feed it from mux fd -> pty
Sep 08 15:18:55 <holtmann> My point exactly. As long as the mux is in userspace, you have no win with doing PPP in the kernel.
Sep 08 15:19:44 <denkenz> It might be easier to simply write a kernel mux :P
Sep 08 15:20:36 <holtmann> If you think so. Go ahead. I mentioned that before. I have done one in my lifetime. I paid my dues to society.
Sep 08 15:20:45 <denkenz> hehe
Sep 08 15:21:10 <holtmann> And seriously. 3G devices with PPP for data connections are dead.
Sep 08 15:21:30 <holtmann> And for GPRS/EDGE, who cares, the network is not fast enough anyway.
Sep 08 15:21:49 <denkenz> true
Sep 08 15:22:10 <holtmann> If I would build a phone and my data path for HSPA is PPP based via a TTY (or even SPI), I would shot myself.
Sep 08 15:22:57 <holtmann> We just need to support it for these legacy ones and laptop data cards. Embedded world is not gonna do it.
Sep 08 15:23:35 <holtmann> And so for pure AT command stuff. userspace vs. kernel mux makes no difference (with our approach). Since the data has to be copied once anyway.
Sep 08 15:24:23 <holtmann> The FSO non-sense is a waste of resources, round-trips and context switches (even if they are cheap on LInux).
Sep 08 15:26:01 <denkenz> btw, I still don't understand how your G_IO_OUT stuff works
Sep 08 15:27:58 <denkenz> You never add a watch for G_IO_OUT...
Sep 08 15:48:20 <holtmann> That needs fixing btw.
Sep 08 15:48:35 <holtmann> It just does work since I assume the socket or fd is always writeable.
Sep 08 15:52:36 <holtmann> Remember this is just a proof of concept that it would work.
Sep 08 15:55:52 <denkenz> ok, btw, even your IO_IN stuff isn't quite correct
Sep 08 15:56:25 <denkenz> since you must check that what is on the main mux actually destined to your channel
Sep 08 16:11:15 <holtmann> As I said, one channel only at the moment.
Sep 08 16:11:31 <holtmann> I have to add support for multiple channels.
Sep 08 16:11:47 <holtmann> And hence multiple GAtMuxChannel + GAtMuxSource.
Sep 08 16:13:53 <holtmann> denkenz: The point here was to demonstrate the we can do it via GIOChannel without an extra fd or pipe in between.
Sep 08 16:14:07 <denkenz> we knew that anyway :)
Sep 08 16:14:30 <holtmann> I was a little bit afraid the GLib would cause problems.
Sep 08 16:15:02 <holtmann> Remember that you get a fake GIOChannel and can use it however you like.
Sep 08 16:15:17 <holtmann> It does behave properly.
Sep 08 16:15:25 <denkenz> point is, proper integration of multiple channels is where the trickiness is
Sep 08 16:15:47 <holtmann> Not really. I just need multiple channels and sources for that.
Sep 08 16:15:54 <holtmann> And store them.
Sep 08 16:17:17 <denkenz> Well, you'll probably need a GQueue of frames
Sep 08 16:17:46 <denkenz> And read properly handling full frame / partial frame reads
Sep 08 16:18:13 <denkenz> then proper IO_OUT / IO_IN handling
Sep 08 16:18:16 <holtmann> Most likely, but I leave that for someone else to implement.
Sep 08 16:19:15 <denkenz> then our definitions of tricky are a bit different :)
Sep 08 16:20:34 <holtmann> I think the bigger goal is to integrate a GAtBackend for the cards that do mux in firmware and offer multiple serial ports.
Sep 08 16:21:22 <holtmann> If we have an API that is transparent then that would be great. And it seems we are close.
Sep 08 16:23:47 <denkenz> So one thing I would suggest is to roll g_at_mux_start into g_at_mux_new
Sep 08 16:24:03 <denkenz> it doesn't seem to serve any purpose
Sep 08 16:24:19 <denkenz> also you might want to add g_at_mux_new_gsm0710
Sep 08 16:24:41 <denkenz> and g_at_mux_new_single_channel, or something like that
Sep 08 16:25:11 <denkenz> then g_at_mux_new_full with proper Backend driver ops
Sep 08 16:25:37 <holtmann> denkenz: It does serve a purpose. You might have to set some basic settings first before starting the muxer. Actually g_at_mux_start is option. We need to create the control channel automatically if needed.
Sep 08 16:26:06 <denkenz> which basic options?
Sep 08 16:26:16 <holtmann> Speed, frame size, mode.
Sep 08 16:26:39 <denkenz> isn't that up to the backend?
Sep 08 16:27:03 <holtmann> Could be. However I still don't wanna have the _new function causing IO.
Sep 08 16:27:03 <denkenz> They're not meaningful in the general case
Sep 08 16:27:16 <denkenz> ok fair enough
Sep 08 16:27:39 <holtmann> However we can just do that automatically when creating the first channel. The _start should only be there to give more control if needed.
Sep 08 16:28:02 <holtmann> Same goes for the shutdown. The the last channel closes. Then shut the mux down.
Sep 08 16:28:57 <denkenz> so what is the difference between start and create channel?
Sep 08 16:29:23 <holtmann> start create the main control channel, and create channel create a data channel. 1 control channel, n data channel.
Sep 08 16:29:43 <holtmann> Did you ever read GSM 07.10 ?
Sep 08 16:29:52 <denkenz> no :)
Sep 08 16:29:59 <holtmann> That explains it then ;)
Sep 08 16:30:48 <denkenz> Btw, how do you handle async events?
Sep 08 16:30:58 <holtmann> Meaning?
Sep 08 16:31:04 <denkenz> You're using atchat, and CMUX is not instanteneous
Sep 08 16:31:34 <denkenz> Neither is open_channel I imagine
Sep 08 16:32:20 <holtmann> Then you don't get G_IO_OUT for GAtChat.
Sep 08 16:32:41 <holtmann> And since you handle that properly, we have no problem :)
Sep 08 16:33:00 <denkenz> Yeah, but between mux_start and mux_channel, an error can happen
Sep 08 16:33:42 <holtmann> That needs to be figured out and we have to send G_IO_NVAL or something. That piece is missing.
Sep 08 16:36:03 <denkenz> I wonder if you can even send the open channel frame until you get the CMUX OK back
Sep 08 16:36:31 <holtmann> No you can't.
Sep 08 16:37:00 <holtmann> Actually you can not even send an open channel frame until the control channel has been opened.
Sep 08 16:37:24 <holtmann> DLCI 0 if you want the spec. terms.
Sep 08 16:39:19 <denkenz> so how does this work then:
Sep 08 16:39:22 <denkenz>         g_at_mux_start(mux);
Sep 08 16:39:23 <denkenz>         channel = g_at_mux_create_channel(mux);
Sep 08 16:39:25 <denkenz>         if (channel == NULL)
Sep 08 16:39:26 <denkenz>                 return NULL;
Sep 08 16:40:16 <holtmann> Magic and a forgiving mux implementation ;)
Sep 08 16:40:27 <denkenz> heh
Sep 08 16:40:41 <holtmann> Seriously. The gsm0710.c is a little bit stupid here.
Sep 08 16:40:42 <denkenz> point is, you probably need a started callback
Sep 08 16:40:53 <denkenz> Otherwise the API makes no sense
Sep 08 16:40:54 <holtmann> There is no way to do that with gsm0710.c
Sep 08 16:41:10 <holtmann> It does work fine in the end. Mainly because it is a full-duplex binary protocol.
Sep 08 16:41:15 <denkenz> well at least for the main cmux command
Sep 08 16:49:44 <denkenz> anyway, the reason it works is that you don't send the open_channel frame as part of g_at_mux_create_channel
Sep 08 16:49:47 <holtmann> denkenz: My proxy killed itself :(
Sep 08 16:49:56 <denkenz> So the API doesn't really reflect reality
Sep 08 16:50:19 <denkenz> I suggest we do a full async correct API
Sep 08 16:50:29 <holtmann> It will eventually. We are not yet done with it.
Sep 08 16:51:04 <holtmann> Btw. I like the idea of using GAtMux also for the modem card that come already with 3 TTYs.
Sep 08 16:51:38 <denkenz> nod, that is essentially the three backends we'll have
Sep 08 16:51:46 <denkenz> pre-mux, 0710 mux and null mux
Sep 08 16:52:12 <denkenz> maybe just send a list of devices to the pre-mux backend
Sep 08 16:52:24 <denkenz> e.g. /dev/ttyS0, /dev/ttyS1, etc
Sep 08 16:54:22 <holtmann> Something like that. Have to play with it a little bit. And I do have to cerate a GPS atom for the MBM hardware.
Sep 08 16:54:49 <denkenz> you're better off running gps on a pty and pointing gpsd onto it
Sep 08 16:54:58 <denkenz> I doubt we should handle this in oFono
Sep 08 16:55:04 <holtmann> The GPS on/off/rate control is done via AT command that can tell the hardware which TTY to post EMEA on.
Sep 08 16:55:21 <denkenz> yah, so have the mbm plugin do this
Sep 08 16:55:30 <holtmann> Not for the EMEA protocol itself. THat is gypsy job, but for the power control :(
Sep 08 16:55:57 <holtmann> I will. Just gonna write an atom for it since we have more hardware like this.
Sep 08 16:56:06 <holtmann> Option can do that, too. If you get the right firmware.
Sep 08 16:56:45 <holtmann> And we an extra control path for A-GPS anyway.
Sep 08 16:58:55 <denkenz> dunno, I'm a bit wary about doing GPS inside oFono
Sep 08 16:59:08 <denkenz> what is the atom going to do?
Sep 08 17:00:37 <holtmann> Provides D-Bus to switch GPS on/off.
Sep 08 17:00:41 <holtmann> For starters.
Sep 08 17:01:05 <holtmann> Then we can update gypsy to detect it. And have geoclue us it.
Sep 08 17:03:43 <denkenz> Powered I can understand to some extent
Sep 08 17:04:19 <denkenz> Are we going to simply provide 'device' property on it?
Sep 08 17:44:31 <holtmann> Something like that. Not 100% sure. We will see.
Sep 08 20:29:05 <akiniemi> denkenz: 23.038 says if the variant is unknown/unsupported, use default
Sep 08 20:29:17 <denkenz> yah, I know
Sep 08 20:29:24 <denkenz> check sms.c
Sep 08 20:30:04 <akiniemi> ah, it's in the second patch ;)
Sep 08 20:30:09 <akiniemi> looks good
Sep 08 20:30:43 <denkenz> yah, we need to figure out how to support dialects on encoding
Sep 08 20:31:58 <akiniemi> config option?
Sep 08 20:32:56 <denkenz> seems to be the most sane way
Sep 08 20:33:12 <denkenz> Though some would argue it could be a per-IMSI option, or we should simply try all dialects
Sep 08 20:33:29 <akiniemi> we really don't want to enable this, unless some regulators mandate it
Sep 08 20:34:14 <denkenz> I'm sure some Turkish hackers would say otherwise :)
Sep 08 20:34:29 <denkenz> for now I'm ok leaving it as is
Sep 08 20:34:46 <denkenz> we cross that bridge when we come to it
Sep 08 20:35:03 <akiniemi> Yeah, it could even check which dialect compresses best and use that... Uh.
Sep 08 20:35:26 <akiniemi> Do this per PDU even. Uh^2
Sep 08 20:35:33 <denkenz> er no :)
Sep 08 20:35:44 <denkenz> I doubt other implementations are as paranoid as ours
Sep 08 20:36:10 <akiniemi> I am happy with decode support only.
Sep 08 20:36:24 <akiniemi> It's compatible with the Jon Postel rule. ;)
Sep 08 20:36:40 <akiniemi> Liberal in what you receive, conservative in what you send
Sep 08 20:37:27 <denkenz> sure
Sep 08 20:38:54 <denkenz> btw, oFono does take care of mixed ucs2 / gsm encoded sms messages
Sep 08 20:39:24 <denkenz> But we don't handle improperly split ucs2 data
Sep 08 20:39:48 <denkenz> rather, we don't handle it 'nicely' 
Sep 08 20:42:13 <denkenz> I remember saying you noticed some implementations were actually not splitting ucs2 as per spec
Sep 08 20:42:26 <denkenz> s/saying/you saying
Sep 08 20:43:32 <akiniemi> yes, might even have been a low-end Nokia phone :)
Sep 08 20:43:53 <denkenz> so in those cases a few letters might get 'lost' ;)
Sep 08 20:44:19 <akiniemi> or you get garbage in between segments
Sep 08 20:44:53 <akiniemi> actually, maybe it was the 0x1b split I mentioned
Sep 08 20:45:09 <akiniemi> there were problems with that even
Sep 08 20:45:49 <akiniemi> and I don't wonder, it's a lowercase should, buried deep in the spec ;)
Sep 08 20:45:54 <denkenz> so that one is not as bad, since only a single char gets corrupted
Sep 08 20:46:14 <denkenz> ucs2 case is worse, since 2nd segment + gets totally corrupted
Sep 08 20:46:37 <akiniemi> right, anything after that split is lost
Sep 08 20:46:56 <akiniemi> that never happened, IIRC
Sep 08 20:47:10 <denkenz> ok good
Sep 08 20:47:43 <akiniemi> oh, and we probably want to add support for NBS
Sep 08 20:47:53 <denkenz> NBS?
Sep 08 20:48:03 <akiniemi> that's the pre-UDH port numbering and concatenation scheme
Sep 08 20:48:19 <akiniemi> smart messaging, WAP
Sep 08 20:48:28 <denkenz> never heard of it, its not in the core spec
Sep 08 20:48:37 <akiniemi> apparently some not so old phones send business cards using it
Sep 08 20:48:56 <akiniemi> the spec is from late 90s, but I have it
Sep 08 20:49:13 <akiniemi> I'll take a look at some point
Sep 08 20:49:29 <denkenz> ok, though ideally VCards should be sent using UDH
Sep 08 20:49:38 <akiniemi> NBS = Narrow Band Sockets
Sep 08 20:49:52 <akiniemi> yah, definitely, but again Jon Postel... ;)
Sep 08 20:50:08 <denkenz> Btw, I wouldn't mind some plugins that did VCards, VCal, Network Logos maybe
Sep 08 20:50:16 <denkenz> If you guys are bored :)
Sep 08 20:50:35 <akiniemi> heh, still some bits and pieces missing from isimodem
Sep 08 20:50:46 <akiniemi> Gotta get that in working condition, really
Sep 08 20:51:03 <denkenz> nod, no hurry
Sep 08 20:51:09 <akiniemi> The speed we're cranking out releases -- it'll be 1.0 real soon :)
Sep 08 20:51:26 <denkenz> nah, just look at BlueZ, they're up to .55 I think?
Sep 08 20:51:55 <denkenz> 95 more releases to go, easy :)
Sep 08 20:56:50 <holtmann> akiniemi: The 1.0 will be once we are not touching the D-Bus API anymore and declare that stable.
Sep 08 20:56:59 <holtmann> Everything else will be just another number.
Sep 08 20:57:19 <holtmann> connman-0.41 and bluez-4.52 :)
Sep 08 20:59:21 <holtmann> denkenz: And after 0.99, we have 0.100 and then 0.100. Who said this is a two digit thing ;)
Sep 08 20:59:39 <holtmann> s/0.100/0.101/ ...
Sep 08 20:59:46 <akiniemi> holtmann: yeah, I figured we'd have more than 6 months left of this project ;)
Sep 08 20:59:56 <denkenz> holtmann: I know that, I'm just kidding around ;)
Sep 08 21:00:11 <denkenz> holtmann: hopefully we get to 1.0 before resorting to .100
Sep 08 21:00:21 <holtmann> Actually with BlueZ I was close to give in and take the next major number. So far I didn't.
Sep 08 21:01:06 <denkenz> hehe, you still have ways to go though
Sep 08 21:02:48 <akiniemi> isimodem sim support is a little problematic
Sep 08 21:03:11 <denkenz> ?
Sep 08 21:03:15 <akiniemi> we've looked at it, and the low-level EF access is really tricky
Sep 08 21:04:23 <denkenz> explain
Sep 08 21:05:02 <akiniemi> well, what's there in the modem API is high-level stuff, like requests for SPN, HPLMN list, etc.
Sep 08 21:05:13 <akiniemi> that API we're also using currently
Sep 08 21:05:41 <akiniemi> so just like IMSI query, I'd rather see the plugin API at that level
Sep 08 21:05:53 <akiniemi> (mentioned this in passing in the ML too)
Sep 08 21:06:28 <denkenz> trouble is, the other half of the world uses low level EF access for EFspn
Sep 08 21:06:34 <denkenz> EFopl, etc
Sep 08 21:06:39 <akiniemi> true
Sep 08 21:07:09 <akiniemi> it would be bloat in the API to have both...
Sep 08 21:08:17 <akiniemi> still, there is that read_imsi already
Sep 08 21:09:27 <denkenz> yeah, that one is a special case
Sep 08 21:09:40 <denkenz> I was actually pondering changing that one to EFimsi too
Sep 08 21:10:09 <denkenz> But because it is so important I don't want to
Sep 08 21:10:15 <akiniemi> oh no, don't -- I have a patch where that's the only one working ;)
Sep 08 21:10:21 <denkenz> We can have a running stack without low level access, but we can't without imsi
Sep 08 21:11:04 <akiniemi> severely hampered, though. Missing the SPN will be visible all the way up in the UI even...
Sep 08 21:11:21 <denkenz> sure, but the SPN one is easy to intercept
Sep 08 21:11:52 <akiniemi> oh?
Sep 08 21:12:27 <denkenz> yeah, if file_id == EFspn, encode_spn(foo)
Sep 08 21:12:46 <denkenz> its always a 17 byte field
Sep 08 21:13:33 <denkenz> we can even put spn build utility inside smsutil.c
Sep 08 21:14:21 <akiniemi> that could work
Sep 08 21:14:36 <denkenz> record based files are considerably nastier
Sep 08 21:15:00 <denkenz> but anything that is transparent should be quite simple to do
Sep 08 21:48:14 <holtmann> akiniemi: This reminds me. The phonet modem detection didn't work out the last time I tried to test it :(
Sep 08 21:48:55 <denkenz> holtmann: any idea what is causing distcheck to fail?
Sep 08 21:48:57 <denkenz>   CCLD   unit/test-util
Sep 08 21:48:58 <denkenz>   CC     unit/test-sms.o
Sep 08 21:49:00 <denkenz>   CC     src/smsutil.o
Sep 08 21:49:01 <denkenz> ../src/smsutil.c:37:19: error: types.h: No such file or directory
Sep 08 21:49:03 <denkenz> cc1: warnings being treated as errors
Sep 08 21:49:23 <holtmann> Let me check.
Sep 08 21:50:09 <holtmann> Works fine here.
Sep 08 21:51:51 <denkenz> ok, this was caused by Andrew's patches
Sep 08 21:53:52 <holtmann> You non upstream patches ;)
Sep 08 21:55:01 <denkenz> no, I was making final distcheck and it was failing
Sep 08 21:55:11 <denkenz> I didn't see any new includes added, so was wondering wtf
Sep 08 21:55:34 <akiniemi> holtmann: how did you bring up the phonet interface?
Sep 08 21:56:18 <holtmann> I didn't.
Sep 08 21:56:24 <holtmann> Do I have to?
Sep 08 21:57:45 <akiniemi> yes
Sep 08 21:58:10 <holtmann> I did an ifconfig pnusb0 up (or whatever that interface name was).
Sep 08 22:02:09 <holtmann> 6: usbpn0: <POINTOPOINT,NOARP> mtu 65541 qdisc noop state DOWN qlen 3
Sep 08 22:02:09 <holtmann>     link/[820] 1b peer 00
Sep 08 22:03:10 <denkenz> akiniemi: So now we have sms fragment backup to disk, so we can receive long sms messages across reboots
Sep 08 22:03:35 <denkenz> akiniemi: Let me know if there's something else we need there
Sep 08 22:03:59 <akiniemi> holtmann: you're probably missing the ifup part where routes are set :(
Sep 08 22:04:13 <holtmann> I need routes?
Sep 08 22:04:18 <akiniemi> denkenz: yah, I noticed. Good stuff
Sep 08 22:04:47 <denkenz> We still need to discuss whether the current SMS api is good enough
Sep 08 22:04:53 <akiniemi> holtmann: courmisch can help you
Sep 08 22:04:54 <holtmann> akiniemi: Tell me more details. I think we really need the isidetect plugin to automate this.
Sep 08 22:05:03 <denkenz> But the internals should be pretty solid now
Sep 08 22:05:55 <akiniemi> holtmann: we have a couple of utilities now, but Remi is working to push that stuff to the kernel
Sep 08 22:06:16 <holtmann> That sounds like a better idea.
Sep 08 23:15:59 <Robot101> denkenz: is there an API to safely remove the cached fragments when they've been acknowledged by the upper layers?
Sep 09 00:00:37 <denkenz> Robot101: Its done automagically
Sep 09 00:03:17 <Robot101> howso?
Sep 09 00:03:48 <Robot101> (ie, when does ofono consider an SMS delivered and ack it to the network?)
Sep 09 00:08:30 <denkenz> as soon as its received
Sep 09 00:10:34 <denkenz> the acknowledge has to be sent within 1 sec or so with +CMT, and we don't bother with SIM store
Sep 09 00:11:02 <denkenz> There's no sense in user apps acking
Sep 09 00:25:11 <zhenhua> ping denis
Sep 09 00:25:16 <denkenz> yah
Sep 09 00:25:44 <zhenhua> does ofono has interface to watch signal comes from bluez?
Sep 09 00:25:59 <denkenz> nope
Sep 09 00:26:12 <denkenz> you can steal much of that code from connman
Sep 09 00:26:19 <denkenz> just look in connman/plugins/bluetooth.c
Sep 09 00:26:22 <zhenhua> yeah, :)
Sep 09 00:27:08 <zhenhua> i steal similiar code from bluez, but it uses low level api like dbus_bus_add_watch
Sep 09 00:27:31 <zhenhua> ok, i will check connman
Sep 09 00:27:52 <denkenz> well you can only use libdbus or libgdbus for this
Sep 09 00:28:19 <zhenhua> okay:)
Sep 09 00:28:58 <zhenhua> it uses dbus_connection_add_filter to add filter to watch signal, but I still debug it. looks it cann't receive my signal from bluez. :(
Sep 09 00:29:58 <zhenhua> and bluez already has telephony-ofono.c, do we really want ofonohandsfree.c or something like ofono-telephony.c? it's confusing I think.
Sep 09 00:30:27 <denkenz> make it ofonohfp.c for now
Sep 09 00:30:32 <denkenz> All of it is likely to change
Sep 09 00:30:58 <zhenhua> okay.
Sep 09 01:03:17 <Robot101> denkenz: I thought acking SMSes back to the network only after they had hit storage was a regulatory requirement?
Sep 09 01:03:51 <Robot101> so you at least need to store/cache/something until the user app says it has it, and then remove it
Sep 09 01:05:31 <Robot101> unless I'm mistaken and that requirement originated elsewhere and was just poorly communicated to us on some occasion :D
Sep 09 01:05:53 <Robot101> but, losing SMSes considered harmful, so some level of acknowldgement between steps would be good
Sep 09 01:46:59 <dilinger> i could see something similar to CMTI over the dbus api
Sep 09 01:49:33 <dilinger> rather than doing CMT, default to CMTI; when a message is received, send up the IncomingMessage signal w/ the message number.  add ReadMessage and DeleteMessage dbus methods to SmsManager that do CMGR and CMGD, respectively
Sep 09 01:59:28 <denkenz> wtf is the point of acking SMSes?
Sep 09 01:59:49 <denkenz> Besides, if you need something like this, simply extend the history plugin API
Sep 09 02:00:04 <denkenz> But having the application ack the PDUs is stupid
Sep 09 02:00:57 <denkenz> We're not going to depend on the application to do the right thing, since application writers have no clue
Sep 09 02:04:21 <denkenz> dilinger: Ain't gonna happen, we're not exposing SMS storage to the core
Sep 09 02:04:54 <denkenz> dilinger: Much less the fragmentation details
Sep 09 02:12:44 <dilinger> denkenz: well, for one thing.. if an SMS is received but nothing's listening for it, that message disappears off into the ether forever
Sep 09 02:13:09 <balrog-kun> Robot101: on ofono side there's only a warranty that the ack is sent after the dbus signal is sent, which is not much (or, after the fragment is stored on disk, but we don't do fsync())
Sep 09 02:14:05 <dilinger> denkenz: particularly because "application writers have no clue", if their app crashes that SMS disappears
Sep 09 02:14:19 <balrog-kun> there's probably more latency on the dbus bus across a single computer than there's between ofono and the modem and then the GSM network
Sep 09 02:15:22 <denkenz> Again, simply extend the history atom API
Sep 09 02:15:42 <denkenz> Then you can stuff the SMS into storage of your choice along
Sep 09 02:16:07 <denkenz> But acking the fragments over D-Bus is simply not going to happen
Sep 09 02:17:45 <denkenz> balrog-kun: The latency is questionable ;)
Sep 09 02:19:07 <dilinger> denkenz: so right now there are no users of the history stuff, and it's only used for calls, right?  (not counting example_history.c)
Sep 09 02:19:32 <denkenz> There are
Sep 09 02:19:39 <denkenz> just not in oFono tree yet
Sep 09 02:19:44 <dilinger> ah
Sep 09 02:19:51 <dilinger> do they create their own dbus api?
Sep 09 02:20:28 <dilinger> or do they not expose history via dbus
Sep 09 02:20:40 <denkenz> Plugins are free to do whatever they wish
Sep 09 02:20:50 <denkenz> But plugin won't be acking anything either
Sep 09 02:20:58 <dilinger> i'm asking what the existing users do
Sep 09 02:20:58 <denkenz> since the ack is not sms atom api
Sep 09 02:21:14 <denkenz> Existing users stuff information into EDS
Sep 09 02:22:01 <dilinger> ah
Sep 09 02:55:03 <zhenhua> ping denkenz
Sep 09 02:56:34 <zhenhua> denkenz: if bluez send disconnect signal to ofono, how can I close hfp modem? through out power down signal by itself?
**** ENDING LOGGING AT Wed Sep 09 02:59:56 2009

**** BEGIN LOGGING AT Wed Sep 09 03:00:02 2009
Sep 09 03:00:15 <denkenz> If its disconnected simply close the channel
Sep 09 03:00:41 <denkenz> And yes, inform oFono that the modem is powered = false
Sep 09 03:19:15 <zhenhua> ok
Sep 09 04:19:27 <holtmann> denkenz: Around?
Sep 09 04:19:32 <denkenz> yah
Sep 09 04:20:39 <holtmann> The MBM device has a /dev/cdc-wdm0 device which does accept AT commands when using cu. It is a pure char device. So with GAtChat only the first AT command succeeds.
Sep 09 04:21:35 <holtmann> Why only the first one works fine and then nothing else triggers sending the next one :(
Sep 09 04:22:11 <denkenz> So even the first one waits for G_IO_OUT
Sep 09 04:22:22 <denkenz> are you sure the parser is setup properly and the modem is replying?
Sep 09 04:22:52 <holtmann> Yes. Just open() and then GIOChannel.
Sep 09 04:23:26 <denkenz> yeah, but maybe the parser is confused?
Sep 09 04:25:23 <holtmann> MUX: > ATI\r
Sep 09 04:25:23 <holtmann> MUX: < ATI\r\r\nF3507g\r\n\r\nOK\r\n
Sep 09 04:26:21 <denkenz> so does your callback get called?
Sep 09 04:26:31 <holtmann> No callback set. Let me see.
Sep 09 04:28:12 <holtmann> No it didn't.
Sep 09 04:28:31 <denkenz> so what parser are you using?
Sep 09 04:28:43 <holtmann> Tried both.
Sep 09 04:29:19 <denkenz> hmm, the v1 parser should definitely pick this up
Sep 09 04:29:57 <holtmann> None of them picks it up.
Sep 09 04:34:02 <denkenz> try turning echo off?
Sep 09 04:35:44 <holtmann> I did already.
Sep 09 04:35:49 <holtmann> No difference.
Sep 09 04:36:25 <denkenz> what prefixes are you using?
Sep 09 04:36:33 <denkenz> Since I just eyeballed v1 parser, and it should work
Sep 09 04:37:16 <denkenz> you sure Atchat itself is getting the data?
Sep 09 04:39:13 <holtmann> The output is through the debug callback. So I assume it gets it.
Sep 09 04:41:26 <holtmann> MUX: > AT+CGMR\r
Sep 09 04:41:26 <holtmann> MUX: < \r\nR1B003\r\n\r\nOK\r\n
Sep 09 04:41:31 <holtmann> With ATE0.
Sep 09 04:41:52 <denkenz> I have no idea, it is valid and should be picked up just fine
Sep 09 04:43:11 <holtmann> 0000000 0a0d 3152 3042 3330 0a0d 0a0d 4b4f 0a0d
Sep 09 04:43:15 <holtmann> Return in hex.
Sep 09 04:43:33 <denkenz> seems fine
Sep 09 04:43:43 <denkenz> can you test what the feed is returning?
Sep 09 04:43:51 <denkenz> e.g. whenever syntax->feed is called
Sep 09 04:43:56 <holtmann> How?
Sep 09 04:44:03 <denkenz> insert some debugs
Sep 09 04:44:10 <holtmann> Which file.
Sep 09 04:44:16 <denkenz> gatchat.c
Sep 09 04:45:04 <denkenz> in new_bytes
Sep 09 04:47:27 <holtmann> That is not called at all.
Sep 09 04:47:39 <denkenz> so gatchat never gets it
Sep 09 04:49:19 <holtmann> It has read result 0 and read rbytes are 16.
Sep 09 04:50:04 <holtmann> Hah. We never leave the loop since it will always be IO_ERROR_NONE
Sep 09 04:50:22 <holtmann> The read() stays blocking :(
Sep 09 04:50:27 <denkenz> where?
Sep 09 04:51:12 <denkenz> the atchat assumes non-blocking sockets btw
Sep 09 04:51:20 <denkenz> so that might need to be changed
Sep 09 04:51:41 <holtmann> I did make it non-blocking.
Sep 09 04:51:49 <holtmann> Seems not to stick.
Sep 09 04:52:05 <holtmann> Doesn't _new sets the socket to non-blocking anyway.
Sep 09 04:52:16 <denkenz> it does
Sep 09 04:53:01 <denkenz> the reading part hasn't been touched since like March
Sep 09 04:53:02 <holtmann> G_IO_FLAG_NONBLOCK
Sep 09 04:53:16 <denkenz> I've never had it stuck in there before
Sep 09 04:54:02 <denkenz> is the read not returning EWOULDBLOCK?
Sep 09 04:56:46 <denkenz> also, feed seems to be returning UNRECOGNIZED for the entire result
Sep 09 04:56:57 <denkenz> which simply can't happen
Sep 09 04:57:02 <holtmann> Fuck. The driver doesn't handle O_NONBLOCK correctly :(
Sep 09 04:57:24 <holtmann> So it is stuck in that loop. Once I remove the while check it just works fine.
Sep 09 04:57:43 <denkenz> hmm
Sep 09 04:57:54 <denkenz> does the driver report bytes available somehow?
Sep 09 04:58:02 <denkenz> like using getsockopt or ioctl?
Sep 09 04:58:16 <holtmann> The read just blocks. And that is stupid. Really really stupid.
Sep 09 04:59:05 <denkenz> Yah, I don't want to compromise efficiency for such broken devices
Sep 09 04:59:18 <denkenz> since while (read != EWOULDBLOCK) is the better way
Sep 09 04:59:33 <denkenz> but perhaps we can quirk it :)
Sep 09 04:59:46 <holtmann> We don't get that error code from the GLib read, do we?
Sep 09 05:00:13 <holtmann> Can we add an option to set nonblocking vs. blocking.
Sep 09 05:01:28 <denkenz> its been a while, but I think GLib does set it
Sep 09 05:02:01 <denkenz> or returns 0 for bytes_read or something like that
Sep 09 05:02:37 <denkenz> we probably can
Sep 09 05:03:39 <denkenz> simply write a new received_data function for the blocking case
Sep 09 05:06:16 <holtmann> So I am thinking of adding g_at_chat_set_non_blocking(chat, gboolean);
Sep 09 05:06:31 <holtmann> And again read() will block if you call it.
Sep 09 05:08:29 <denkenz> yeah its really silly
Sep 09 05:08:42 <denkenz> I suggest you make it clear that it is a quirk for broken devices
Sep 09 05:08:53 <denkenz> perhaps re-introduce flags to g_at_chat_new
Sep 09 05:10:21 <holtmann> Yeah. Maybe that would be not that bad.
Sep 09 05:11:15 <holtmann> I want to use that device. Otherwise we gonna loose one on the MBM system. This way we have four. And one needs to be reserved for GPS.
Sep 09 05:11:34 <denkenz> nod, ideally the kernel driver should get fixed
Sep 09 05:11:48 <denkenz> but in the meantime we can depend on linux not to block us on the first read
Sep 09 05:11:50 <holtmann> It has another one of these cdc-wdm1 or PC SC stuff. Never tried it.
Sep 09 05:11:56 <holtmann> I mailed the author already.
Sep 09 05:12:24 <holtmann> Why did you do that anyway since we rely on being woken up via poll anyway?
Sep 09 05:13:13 <denkenz> shrug, that is simply what is recommended everywhere :)
Sep 09 05:13:15 <holtmann> I mean try reading even if poll() didn't tell us there is data.
Sep 09 05:13:22 <denkenz> I don't
Sep 09 05:13:34 <denkenz> we only read when read watch fires
Sep 09 05:13:45 <denkenz> however, we read as much as we can
Sep 09 05:13:45 <holtmann> Your while loop is doing that exactly. You assume read didn't give you all data.
Sep 09 05:14:08 <denkenz> which according to man 2 read is quite possible
Sep 09 05:14:15 <holtmann> And instead you could have let poll trigger the read again. You are using a ring buffer anyway.
Sep 09 05:14:33 <denkenz> yeah, but why do multiple polls and multiple event loop iterations?
Sep 09 05:15:04 <holtmann> Your assumption is that O_NONBLOCK actually works.
Sep 09 05:15:31 <denkenz> shrug, it works for everything I've tried :)
Sep 09 05:15:36 <holtmann> And the cases where read only returns a subset of the available data is limited by the way.
Sep 09 05:16:00 <denkenz> Again, I'm going by what man 2 read says
Sep 09 05:16:12 <denkenz> Strictly speaking it is the preferred way
Sep 09 05:17:36 <holtmann> It doesn't say that.
Sep 09 05:17:53 <holtmann> Actually strictly speaking you are blocking the mainloop with this.
Sep 09 05:18:06 <denkenz> no I'm not...
Sep 09 05:19:00 <holtmann> You are. At least theoretically. If for some reason you are getting a lot of data say 2 GB, just for fun. You will be reading all of it. Without returning to the mainloop and thus stalling the app.
Sep 09 05:19:09 <holtmann> Not that you ever get that much data anyway.
Sep 09 05:19:50 <denkenz> so you're advocating doing 2 GB / buffer size loop iterations?
Sep 09 05:19:54 <denkenz> both cases are wrong 
Sep 09 05:20:27 <holtmann> I mean that you need to trust the kernel.
Sep 09 05:20:50 <holtmann> If it gives you less data and lets you iterate once more through poll(), then that is for a reason.
Sep 09 05:21:07 <holtmann> And that can only happen if you get a signal in between.
Sep 09 05:21:30 <denkenz> Shrug
Sep 09 05:21:32 <holtmann> And that is what we actually want. Return to the mainloop and process the signal.
Sep 09 05:21:51 <holtmann> Really I don't see any other way we read() might return less than what is available.
Sep 09 05:21:57 <holtmann> s/we/why/
Sep 09 05:22:24 <denkenz> feel free to change it
Sep 09 05:22:34 <holtmann> I think I will. And I will fix the kernel driver, too.
Sep 09 05:23:09 <holtmann> System calls are cheap, but in the end you alway have to call read() twice. Second time to confirm there is no data left in the kernel buffer.
Sep 09 05:23:42 <denkenz> we're splitting hairs, you just worked up because it doesn't work on a broken driver
Sep 09 05:24:27 <holtmann> Don't get me wrong. I will have that driver fixed. Lying to userspace that O_NONBLOCK is set and it isn't is just wrong. I double checked by re-reading it. And it says it is set.
Sep 09 05:25:21 <holtmann> I do run some extra tests and see in which cases we do actually need to call read twice. Especially with the fact of a GIOChannel from the muxer.
Sep 09 05:26:00 <denkenz> btw, nonblock is also for being more paranoid
Sep 09 05:26:18 <denkenz> e.g. broken devices that might actually block and wait for all the data
Sep 09 05:26:25 <denkenz> which is worse
Sep 09 05:26:46 <holtmann> We do wanna use nonblock. No questions about that.
Sep 09 05:27:15 <holtmann> This is more about just trusting poll() and read() to do the right thing. And then it happens to handle blocking devices, too.
Sep 09 05:28:43 <denkenz> I trust poll just fine, but read should drain as much data as possible
Sep 09 05:28:50 <denkenz> going through the event loop is freaking expensive
Sep 09 05:29:16 <holtmann> This is what I am going to check. If read really gives us all data. I have a bunch of devices here that I can check against.
Sep 09 05:32:02 <denkenz> Also, I've no idea how load / etc comes into play here
Sep 09 05:32:39 <denkenz> it might be worth to test
Sep 09 05:32:45 <holtmann> We can always go back to this way. It is not that the code is lost.
Sep 09 05:34:04 <denkenz> btw I don't mind if you change this, just pointint out there were reasons for it being this way ;)
Sep 09 05:35:34 <holtmann> I will. Still wanna check if it impacts us.
Sep 09 05:35:45 <holtmann> At least now, I know what is going on here.
Sep 09 05:38:31 <denkenz> nod
Sep 09 05:38:38 <denkenz> anyway I'm off for a while
Sep 09 07:58:31 <holtmann> denkenz: Oliver send a patch for the cdc-wdm driver. Works fine now. Since this is not upstream, we are still in kinda weird situation here.
Sep 09 11:53:29 <holtmann> Program received signal SIGILL, Illegal instruction.
Sep 09 11:53:29 <holtmann> 0x1006e660 in ?? ()
Sep 09 11:53:29 <holtmann> (gdb) bt
Sep 09 11:53:29 <holtmann> #0  0x1006e660 in ?? ()
Sep 09 11:53:29 <holtmann> #1  0x1000bb54 in g_isi_request_make (cl=0x10078a00, buf=0xffb0fc0e, len=2, timeout=5, cb=0x1000e0d0 <manufacturer_resp_cb>, 
Sep 09 11:53:31 <holtmann>     opaque=0x1007a0a8) at gisi/client.c:229
Sep 09 11:53:35 <holtmann> #2  0x1000dafc in isi_query_manufacturer (info=<value optimized out>, cb=0x10027a00 <query_manufacturer_cb>, data=0x10078908)
Sep 09 11:53:38 <holtmann>     at drivers/isimodem/devinfo.c:166
Sep 09 11:53:40 <holtmann> #3  0x10026580 in ofono_devinfo_register (info=<value optimized out>) at src/modem.c:803
Sep 09 11:53:41 <holtmann> #4  0x1000e300 in isi_devinfo_register (user=<value optimized out>) at drivers/isimodem/devinfo.c:368
Sep 09 11:53:44 <holtmann> #5  0x0ff1e9a4 in ?? () from /usr/lib/libglib-2.0.so.0
Sep 09 11:53:45 <holtmann> #6  0x0ff2166c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
Sep 09 11:53:48 <holtmann> #7  0x0ff25e38 in ?? () from /usr/lib/libglib-2.0.so.0
Sep 09 11:53:49 <holtmann> #8  0x0ff26574 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
Sep 09 11:53:51 <holtmann> #9  0x1002569c in main (argc=1, argv=0xffb100a4) at src/main.c:148
Sep 09 11:53:54 <holtmann> courmisch, akiniemi: This is running on PowerPC. Do you guys have some x86 magic in that code.
Sep 09 11:54:27 <holtmann> And just by starting ofonod.
Sep 09 11:55:00 <holtmann> I would expect this only happens when powering on the modem and not starting it.
Sep 09 11:56:59 <holtmann> If I do ifup usbpn0 after starting ofonod it doesn't crash. Also it doesn't show the modem manufacturer details either.
Sep 09 13:25:37 <akiniemi> holtmann: well there is some clever 32bit alignment magic in there... courmisch?
Sep 09 13:27:17 <courmisch> holtmann: SIGILL? ! shouldnt it be SIGBUS?
Sep 09 13:27:34 <holtmann> I am just the messenger here.
Sep 09 13:29:49 <courmisch> sounds like a crash in the debug_func
Sep 09 13:29:54 <courmisch> which is an addition of aki...
Sep 09 13:30:25 <courmisch> probably it is not initialized
Sep 09 13:36:56 <courmisch> holtmann: fix on the mll (untested)
Sep 09 15:30:08 <denkenz> holtmann: I leave it up to you, I still would prefer a quirk that replaced received_data with a function that didn't do while(read)
Sep 09 16:19:18 <dilinger> denkenz: now that i'm more awake.. i'd like to point out that i have no interest in exposing the SMS storage to ofono clients
Sep 09 16:20:06 <denkenz> dilinger: no worries
Sep 09 16:21:29 <dilinger> denkenz: storing SMS's somewhere via history plugin means finding storage for them.  changing the SmsManager API to support storage means that modems that don't support CMTI would have to figure out disk storage; modems that do support CMTI could skip the /var/spool code and just read directly off SMS storage
Sep 09 16:22:15 <denkenz> Do you guys even know what you're asking for?
Sep 09 16:22:29 <denkenz> So far you're all talking nonsense, give me more background
Sep 09 16:23:48 <Robot101> denkenz: ok, so a SMS arrives. ofono emits a dbus signal, and acks it to the network. then the device crashes
Sep 09 16:23:57 <Robot101> denkenz: you just lost an SMS
Sep 09 16:24:25 <Robot101> user cries and returns the device to the vendor, who says telepathy is shit, and burns collabora ... :P
Sep 09 16:24:53 <denkenz> umm, so you extend history with file system storage and dump the SMS in there
Sep 09 16:24:56 <Robot101> what I'm asking for isn't history - telepathy already does that
Sep 09 16:25:25 <Robot101> its just that ofono persists a SMS until a higher-level component acknowledges that it's synced it
Sep 09 16:25:38 <Robot101> for instance, the telepathy logger can say, yes I've logged it, then yafono can clear it from ofono
Sep 09 16:26:00 <denkenz> How is this different from history?
Sep 09 16:26:08 <denkenz> Since if oFono crashes the SMS is still lost
Sep 09 16:26:23 <denkenz> And we're not going to delay deleteing from SMS store or not sending the ack
Sep 09 16:26:27 <denkenz> Its just not going to happen
Sep 09 16:27:09 <Robot101> get SMS, save it, send ack. something higher up acknowledges, then you delete the SMS from disk/spool/whatever.
Sep 09 16:27:32 <denkenz> Guys, this is what I'm saying, extend history plugin with SMS stuff
Sep 09 16:27:39 <denkenz> Then your history implementation can do that
Sep 09 16:28:00 <Robot101> does that actually give us a way to delay the acking to the network until the message is sync()'d to disk?
Sep 09 16:28:37 <denkenz> no, we're not doing it this way
Sep 09 16:28:53 <Robot101> why not? this means you can lose SMSes
Sep 09 16:29:41 <denkenz> Because then we have to expose fragmentation details up to history
Sep 09 16:29:58 <denkenz> Which we already take care of in oFono
Sep 09 16:30:08 <Robot101> maybe an indication that hand-waving this away to the history plugin is a bad idea?
Sep 09 16:30:19 <Robot101> if you already have a way to persist fragments
Sep 09 16:30:29 <denkenz> We persist fragments, not SMSes
Sep 09 16:30:51 <denkenz> persisting SMS messages is job of history
Sep 09 16:31:48 <Robot101> you can persist one-fragment messages in the same place and keep them until history or some other thing has actually stored them safely
Sep 09 16:32:52 <denkenz> Dude, for 1 fragment messages history can do fsync
Sep 09 16:33:02 <denkenz> For n fragment messages history can do fsync
Sep 09 16:33:22 <denkenz> But history won't get the SMS until it is complete
Sep 09 16:33:37 <denkenz> and we're not exposing the ack details to the core
Sep 09 16:33:44 <Robot101> but you won't delay the ack of the 1-fragment message / last fragment, because....?
Sep 09 16:33:52 <Robot101> I don't see why the architecture is already so rigid that it's a good idea to design in data-loss from the outset
Sep 09 16:34:13 <Robot101> we get enough crap from Nokia about IMs being lost when they unplug an access point from the ethernet and the N900s don't drop off-line immediately
Sep 09 16:34:26 <Robot101> but that's the best we can do with XMPP
Sep 09 16:35:05 <denkenz> shrug, as soon as pdu arrives and is a fragment, its written to disk
Sep 09 16:35:17 <denkenz> If you feel strongly about it submit a patch to do fsync right then
Sep 09 16:35:27 <denkenz> Once pdu is defragmented its sent to dbus / history
Sep 09 16:35:39 <denkenz> history can do wtf it wants with it
Sep 09 16:35:42 <Robot101> I feel strongly about non-fragmented messages too
Sep 09 16:36:03 <denkenz> so put it out to disk and fsync
Sep 09 16:36:24 <Robot101> but you've already acked it by then, so there's still an un-necessary window in which you can lose data
Sep 09 16:36:46 <denkenz> message is not acked until after delivery
Sep 09 16:37:02 <denkenz> how about you check the source?
Sep 09 16:38:20 <Robot101> well - I hadn't though about the history plugin doing this until now. if that does let us sync the messages before they're acked, great. thanks for explaining.
Sep 09 16:38:41 <Robot101> I was just worried about receive -> emit d-bus signal -> ack -> while shit is happening, power loss/crash/etc.
Sep 09 16:40:33 <denkenz> no worries
Sep 09 16:50:29 <dilinger> denkenz: where is the code that handles persistence of sms frags?
Sep 09 16:50:43 <denkenz> smsutil.c inside sms_assembly
Sep 09 16:52:14 <dilinger> denkenz: i see the sms_assembly stuff; i'm not seeing any disk storage stuff, just memory storage
Sep 09 16:52:28 <denkenz> git pull, it was pushed yesterday
Sep 09 16:53:09 <dilinger> ah!
Sep 09 16:54:35 <dilinger> denkenz: thanks
Sep 09 20:26:07 <holtmann> ofonod[4027]: drivers/isimodem/devinfo.c:manufacturer_resp_cb() ISI client error: -110
Sep 09 20:26:08 <holtmann> ofonod[4027]: drivers/isimodem/devinfo.c:model_resp_cb() ISI client error: -110
Sep 09 20:26:08 <holtmann> ofonod[4027]: drivers/isimodem/devinfo.c:revision_resp_cb() ISI client error: -110
Sep 09 20:26:08 <holtmann> ofonod[4027]: drivers/isimodem/devinfo.c:serial_resp_cb() ISI client error: -110
Sep 09 20:26:23 <holtmann> courmisch: Patch makes it not crash, but everything else times out.
Sep 09 20:36:44 <courmisch> and this is what device?
Sep 09 20:36:49 <courmisch> did you ifconfig up ?
Sep 09 20:37:21 <holtmann> Yes, I did. Nokia 6500 connected via USB.
Sep 09 20:38:21 <courmisch> I suspect some tweaks will be needed to gisi_netlink still
Sep 09 20:38:40 <courmisch> and then I have no idea about 6500 compatibility
Sep 09 20:39:08 <courmisch> I think Aki and Ismo are mostly testing against N900 and/or N95
Sep 09 20:39:33 <courmisch> Oh well, I'll check tomorrow
Sep 09 20:39:36 <courmisch> good night
Sep 09 20:42:43 <holtmann> Don't have a N900 yet and never owned a N95 or similar.
Sep 09 20:42:54 <holtmann> Nokia 6500 is the newest that I have :(
Sep 09 20:51:49 <denkenz> man, CBS spec guys drinking even more heavily-spiked coolaid than even the SMS spec guys
Sep 10 01:30:08 <zhenhua> denkenz: looks like g_at_chat_set_disconnect_function is not fully implemented yet. I want to watch GAtChat that create from rfcomm0, so Ofono could disable modem when rfcomm was closed exceptionally.
Sep 10 01:30:34 <denkenz> It works, but it might not work on rfcomm devices
Sep 10 01:31:28 <denkenz> Can you double check with a socket?
Sep 10 01:43:10 <zhenhua> i think it should work with socket. I will doube check that
Sep 10 01:43:25 <denkenz> I'm pretty sure it does
Sep 10 01:43:34 <denkenz> Problem is the RFCOMM device is 'special' ;)
Sep 10 01:43:47 <denkenz> We need to get holtmann to fix that if it does turn out to be the case
Sep 10 01:43:51 <zhenhua> yeah...that's my problem I need to fix it
Sep 10 01:44:38 <zhenhua> we have g_at_chat_new_from_tty but channel is not expose to upper level
Sep 10 01:45:10 <zhenhua> sorry, looks i am wrong. we still can do it
Sep 10 01:45:51 <zhenhua> i also have question about exception handling
Sep 10 01:46:02 <denkenz> yep?
Sep 10 01:46:10 <zhenhua> if ofono is quit, do we need inform bluez to clean up rfcomm
Sep 10 01:46:22 <zhenhua> or keep rfcomm there. and reload rfcomm when restart ofono
Sep 10 01:46:48 <denkenz> Let oFono do that
Sep 10 01:47:01 <denkenz> oFono guarantees that it will call powered = false for each modem before going down cleanly
Sep 10 01:47:45 <zhenhua> what if process was killed or something else
Sep 10 01:48:00 <denkenz> Only if oFono crashes
Sep 10 01:48:02 <zhenhua> do we need bluez to watch ofono status
Sep 10 01:48:05 <denkenz> Lets assume that never happens :)
Sep 10 01:48:13 <zhenhua> okay:)
Sep 10 01:48:56 <denkenz> We'll probably have to do some cleanup, but those details are not in scope for now
Sep 10 01:49:24 <zhenhua> yeah, maybe i worry about such issues too much. 
Sep 10 01:49:42 <denkenz> yeah, get it working first
Sep 10 01:49:47 <denkenz> Then make it work better
Sep 10 01:49:52 <zhenhua> sure
**** ENDING LOGGING AT Thu Sep 10 02:59:57 2009

**** BEGIN LOGGING AT Thu Sep 10 02:59:57 2009
Sep 10 07:55:43 <akiniemi> holtmann: this might be the netlink problem Remi mentioned with the 6500
Sep 10 07:56:19 <akiniemi> holtmann: II've so far tested with E61, N95, N90, and they work
Sep 10 07:57:41 <akiniemi> holtmann: we should have a 6500 somewhere, too. I'll check. 
Sep 10 07:58:11 <akiniemi> holtmann: generally the phone info queries should work across all modem versions
Sep 10 07:58:30 <akiniemi> s/N90/N900
Sep 10 08:46:49 <admiral0> hello
Sep 10 08:47:08 <admiral0> does ofono support Freerunner's modem?
Sep 10 08:47:53 <admiral0> and what's ofono status? does it make calls and send sms?
Sep 10 08:57:12 <inz> admiral, yes, in development, yes and yes
Sep 10 09:08:50 <admiral0> inz, where can i find the api?
Sep 10 09:11:19 <inz> admiral0, read the source or D-Bus introspect
Sep 10 09:12:01 <admiral0> ok
Sep 10 09:12:26 <admiral0> thanks, but you definetely need a api.ofono.org
Sep 10 09:12:27 <admiral0> :)
Sep 10 09:13:51 <inz> Ohh, actually the documentation in doc/ (in git) seems better than last time I read
Sep 10 09:14:44 <inz> But it isn't quite up-to-date.
Sep 10 09:15:34 <admiral0> so it's better if i use dbus introspect
Sep 10 09:16:16 <inz> Yes and no; you don't see the property names with D-Bus introspect.
Sep 10 09:18:26 <admiral0> ok, it's enough for me, i'll PKGBUILD it for archmobile :)
Sep 10 09:43:20 <inz> admiral, you do want the property names; they're quite essential. Of course you can just call GetProperties for all objects you find and dump the response
Sep 10 10:14:29 <akiniemi> d-feet is also quite useful to play around with interfaces
Sep 10 13:23:48 <holtmann> inz: We are accepting patches for doc/ too ;)
Sep 10 13:49:20 <holtmann> akiniemi: Do you guys wanna debug the Nokia 6500 details or don't we care right now?
Sep 10 13:51:08 <courmisch> holtmann: could you retry with the bleeding edge ofono git?
Sep 10 13:51:17 <holtmann> Sure.
Sep 10 13:53:16 <courmisch> I assume you have the netdev patches too
Sep 10 13:53:54 <holtmann> Yep. net-next-2.6 with your patches.
Sep 10 13:57:52 <holtmann> courmisch: Btw. I am running on PowerPC big endian, 64-bit kernel, 32-bit userspace.
Sep 10 13:58:33 <holtmann> I know it is mean, but it should work there, too ;)
Sep 10 14:00:15 <courmisch> I have no 64-bits system at hand
Sep 10 14:04:12 <holtmann> courmisch: So the ifup and Powered value doesn't really match.
Sep 10 14:04:29 <holtmann> I have Powered=1, but ifdown.
Sep 10 14:05:03 <courmisch> uh
Sep 10 14:05:12 <courmisch> maybe some race in the ifconfig code
Sep 10 14:09:34 <courmisch> hmm kernel patch is slightly broken. not sending netlink events
Sep 10 14:28:28 * akiniemi *facepalm*
Sep 10 14:32:07 <akiniemi> ;)
Sep 10 16:14:42 <holtmann> usbpn0    Link encap:UNSPEC  HWaddr 1B-CD-FF-00-00-00-48-00-00-00-00-00-00-00-00-00
Sep 10 16:14:56 <holtmann> courmisch: The -CD- value keeps changing on every call. Is that expected?
Sep 10 16:16:11 <holtmann> usbpn0    Link encap:UNSPEC  HWaddr 1B-9D-FF-00-00-00-48-00-00-00-00-00-00-00-00-00  
Sep 10 16:16:12 <holtmann> usbpn0    Link encap:UNSPEC  HWaddr 1B-DB-FF-00-00-00-48-00-00-00-00-00-00-00-00-00  
Sep 10 16:16:12 <holtmann> usbpn0    Link encap:UNSPEC  HWaddr 1B-20-FF-00-00-00-48-00-00-00-00-00-00-00-00-00  
Sep 10 16:16:12 <holtmann> usbpn0    Link encap:UNSPEC  HWaddr 1B-4C-FF-00-00-00-48-00-00-00-00-00-00-00-00-00  
Sep 10 16:16:12 <holtmann> usbpn0    Link encap:UNSPEC  HWaddr 1B-31-FF-00-00-00-48-00-00-00-00-00-00-00-00-00  
Sep 10 16:16:12 <holtmann> usbpn0    Link encap:UNSPEC  HWaddr 1B-5B-FF-00-00-00-48-00-00-00-00-00-00-00-00-00  
Sep 10 16:16:14 <holtmann> usbpn0    Link encap:UNSPEC  HWaddr 1B-67-FF-00-00-00-48-00-00-00-00-00-00-00-00-00  
Sep 10 16:16:16 <holtmann> Like this.
Sep 10 16:17:15 <holtmann> ofonod[4995]: drivers/isimodem/devinfo.c:manufacturer_resp_cb() ISI client error: -110
Sep 10 16:17:15 <holtmann> ofonod[4995]: drivers/isimodem/devinfo.c:model_resp_cb() ISI client error: -110
Sep 10 16:17:15 <holtmann> ofonod[4995]: drivers/isimodem/devinfo.c:revision_resp_cb() ISI client error: -110
Sep 10 16:17:15 <holtmann> ofonod[4995]: drivers/isimodem/devinfo.c:serial_resp_cb() ISI client error: -110
Sep 10 16:17:18 <holtmann> And still :(
Sep 10 16:19:14 <holtmann> akiniemi: So runtime detection of modem fails. I have to start ofonod after plugging in the device.
Sep 10 16:19:41 <holtmann> ofonod[5138]: drivers/isimodem/devinfo.c:decode_sb_and_report() <Nokia>
Sep 10 16:19:41 <holtmann> ofonod[5138]: drivers/isimodem/devinfo.c:decode_sb_and_report() <Nokia 6500c>
Sep 10 16:19:41 <holtmann> ofonod[5138]: drivers/isimodem/devinfo.c:decode_sb_and_report() <V 03.21
Sep 10 16:19:41 <holtmann> 31-08-07
Sep 10 16:19:41 <holtmann> RM-265
Sep 10 16:19:42 <holtmann> (c) Nokia            >
Sep 10 16:19:44 <holtmann> ofonod[5138]: drivers/isimodem/devinfo.c:decode_sb_and_report() <358666013403510>
Sep 10 16:19:47 <holtmann> Finally :) No idea what I changed though.
Sep 10 16:22:22 <holtmann> denkenz: I do have on error for you, too.
Sep 10 16:22:29 <holtmann> holtmann@quadfive:/data/devel/ofono/test$ ./test-network-registration default
Sep 10 16:22:29 <holtmann> Status is: 'unknown', Operator is: ''
Sep 10 16:22:29 <holtmann> Unable to register/deregister:  org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Sep 10 16:22:29 <holtmann> holtmann@quadfive:/data/devel/ofono/test$ ./test-network-registration default
Sep 10 16:22:30 <holtmann> Status is: 'unknown', Operator is: ''
Sep 10 16:22:32 <holtmann> Unable to register/deregister:  org.ofono.Error.InProgress: Operation already in progress
Sep 10 16:23:00 <holtmann> If D-Bus times out, we still keep the that operation in progress.
Sep 10 16:50:56 <denkenz> Actually its the modem that keeps that operation in progress
Sep 10 16:56:02 <holtmann> Okay.
Sep 10 18:33:18 <courmisch> holtmann: ifconfig not memsetting properly
Sep 10 18:33:49 <holtmann> Sweet.
Sep 10 18:34:02 <courmisch> there is a bug in the netdev patch
Sep 10 18:34:14 <courmisch> I will post the fixed version when I get to the office tomorrow
Sep 10 18:34:25 <holtmann> Okay.
Sep 10 18:34:38 <courmisch> so yeah, you need to start ofonod after plugging in in the mean time
Sep 10 18:34:51 <holtmann> I wait until you fixed it properly ;)
Sep 10 18:35:28 <holtmann> Also starting by Saturday, I will loose the access to my PPC system again since I am traveling. So no more nasty bug reports from me until November ;)
**** ENDING LOGGING AT Fri Sep 11 03:00:00 2009

**** BEGIN LOGGING AT Fri Sep 11 03:00:00 2009
Sep 11 08:29:48 <holtmann>         {
Sep 11 08:29:48 <holtmann>                 DECLARE_FAILURE(e);
Sep 11 08:29:48 <holtmann>                 cb(&e, NULL, cbd->data);
Sep 11 08:29:48 <holtmann>         }
Sep 11 08:29:56 <holtmann> denkenz: What the fuck is this?
Sep 11 08:30:37 <holtmann> Can you not just have a proper macro for the error reporting that does everything in one call with a clear name. where you just give the callback and then the data.
Sep 11 13:57:39 <denkenz> holtmann: no, because different callbacks have different arguments
Sep 11 13:58:54 <holtmann> And so? .../va_arg is an option.
Sep 11 13:59:30 <denkenz> and the cast?
Sep 11 14:00:58 <holtmann> I must be missing something really obvious here. Since you do always DECLARE_FAILURE; cb(); anyway. Why is this separate and not combined. No matter what the callback arguments are?
Sep 11 14:01:24 <denkenz> because callback has different type
Sep 11 14:01:42 <denkenz> you cannot do this generically, easily anyway
Sep 11 14:02:12 <holtmann> Okay. I think it could be done, but I also have no time to actually try.
Sep 11 14:03:06 <denkenz> it probably could, but DECLARE_FAILURE is also used outside the call function, but also in the callback
Sep 11 14:03:32 <holtmann> This is too complicated for me right now. So never mind ;)
Sep 11 14:12:35 <denkenz> holtmann: I take a look at that later today, probably the 90% case can be taken care of with a single macro
Sep 11 17:40:09 <denkenz> holtmann: You should be happy now
**** ENDING LOGGING AT Sat Sep 12 02:59:56 2009

**** BEGIN LOGGING AT Sat Sep 12 02:59:56 2009
Sep 12 06:37:02 <holtmann>   CC     src/network.o
Sep 12 06:37:02 <holtmann> cc1: warnings being treated as errors
Sep 12 06:37:02 <holtmann> src/network.c: In function ‘__ofono_netreg_remove_status_watch’:
Sep 12 06:37:02 <holtmann> src/network.c:935: error: control reaches end of non-void function
Sep 12 11:01:17 <mgwpub> hi together. i have a problem, that the object path for the modem from modems.conf is not present, i cant see it via d-feet
Sep 12 11:02:12 <mgwpub> some days ago it was no problem and i am not sure what is different now
Sep 12 11:02:40 <mgwpub> i tried some different ofono versions, but without success
Sep 12 11:03:23 <mgwpub> do you have a hint for me what i should check?
Sep 12 11:07:07 <mgwpub> ok, i found my mistake
Sep 12 11:20:58 <mgwpub> problem is, that i used the configure parameter described in README, but ofonod does not recognize my modem.conf in /etc/ofonod/ where it is installed via make. ofonod tries to open the file in /usr/local... and there is no such file.
Sep 12 15:16:19 <denkenz> holtmann: Thanks for fixing that one
Sep 12 16:36:47 <akiniemi> Pushed a few patches in
Sep 12 16:37:31 <akiniemi> Now scanning, registration, etc. should work with Nokia modems
Sep 12 16:37:35 <akiniemi> In theory ;)
Sep 12 18:11:42 <denkenz> akiniemi: Looks good
Sep 12 18:17:35 <denkenz> akiniemi: Please observe the 80 char limit though, parts of netreg go way beyond it
Sep 12 18:18:18 <akiniemi> denkenz: sure
Sep 12 18:18:41 <akiniemi> denkenz: I'll be reworking that code anyway, like moving that iterator perhaps to gisi
Sep 12 18:19:25 <denkenz> akiniemi: Also, reg_status_get_resp_cb: the int lac line is not indented properly
Sep 12 18:19:34 <denkenz> spaces
Sep 12 18:20:42 <denkenz> akiniemi: Btw, your modems report operator names in UCS2?
Sep 12 18:21:53 <denkenz> akiniemi: or does that include some EONS magic behind the scenes?
Sep 12 18:40:33 <akiniemi> denkenz: the modem is UCS-2 everywhere
Sep 12 18:41:57 <akiniemi> denkenz: the names in scan list and current operator are latin only, though
Sep 12 18:45:24 <akiniemi> denkenz: style issues pushed, thanks for a quick review ;)
Sep 12 18:55:35 <denkenz> akiniemi: Ok that makes sense
Sep 12 21:36:44 <holtmann> denkenz: We should be using UTF-8 for everything inside the API. That is D-Bus standard. And conforms nicely with all Linux distros these days.
Sep 12 21:38:05 <Robot101> you'd have to use an ay otherwise, and then everyone would hate you and look at you weirdly
Sep 12 21:58:08 <denkenz> holtmann: We already do
Sep 12 21:58:21 <denkenz> holtmann: Everything going up from driver -> core is assumed to be utf8
Sep 12 21:58:35 <denkenz> holtmann: Only exception is binary pdus which we decode accordingly
Sep 12 21:59:45 <denkenz> holtmann: I was mostly curious since at commands do not allow ucs2 characters in operator names
**** ENDING LOGGING AT Sun Sep 13 02:59:56 2009

**** BEGIN LOGGING AT Sun Sep 13 02:59:56 2009
**** ENDING LOGGING AT Mon Sep 14 02:59:57 2009

**** BEGIN LOGGING AT Mon Sep 14 02:59:57 2009
Sep 14 17:23:46 <denkenz> zhenhua1: Are you sure the socket is connected?  Since I've used rfcomm ttys with socket fds obtained from accept
Sep 14 19:04:26 <denkenz> balrog-kun: So the spec is totally screwed.  EFlp/EFli share the same EFid but different formats
Sep 14 19:04:47 <denkenz> and there isn't even any way to determine the phase of the SIM
Sep 14 19:05:48 <denkenz> Do we really want to even bother reading EFlp/li? Otherwise we need additional checks that ISO code is valid
Sep 14 21:05:41 <ekuo> has anyone run into this error when building ofono?
Sep 14 21:05:46 <ekuo>   GEN    src/ofono.exp
Sep 14 21:05:46 <ekuo> /bin/sh: gdbus/mainloop.o: Permission denied
Sep 14 21:05:46 <ekuo> make[1]: *** [src/ofono.exp] Error 1
Sep 14 21:07:09 <holtmann> Building as root and also not as root. Make sure you get your local file system permission sorted out.
Sep 14 21:07:54 <ekuo> I am building as non root, and have read access to all the files
Sep 14 21:08:30 <holtmann>   CC     drivers/isimodem/phonebook.o
Sep 14 21:08:30 <holtmann> cc1: warnings being treated as errors
Sep 14 21:08:30 <holtmann> drivers/isimodem/phonebook.c: In function ‘decode_read_response’:
Sep 14 21:08:30 <holtmann> drivers/isimodem/phonebook.c:190: error: format ‘%u’ expects type ‘unsigned int’, but argument 5 has type ‘size_t’
Sep 14 21:08:41 <holtmann> akiniemi: Seriously guys. Please buy a 64-bit machine,
Sep 14 21:11:05 <akiniemi> holtmann: aw, crap. that gets me every time...
Sep 14 21:12:25 <holtmann> Fixed it already :)
Sep 14 21:16:34 <akiniemi> holtmann: thanks ;)
Sep 14 21:16:51 <holtmann> No problem, but you guys really need a 64-bit machine ;)
Sep 14 21:29:54 <tmzt> holtmann: if you are still looking for a cmux device, the treo 680's broadcom chip uses that
Sep 14 21:30:02 <tmzt> don't know of a usb device though
Sep 14 21:33:27 <balrog-kun> denkenz: it looks like the language codes in CB DCS coding are only in 0 - 16, 32 - 36 ranges
Sep 14 21:34:06 <denkenz> balrog-kun: yeah, basically
Sep 14 21:34:20 <balrog-kun> we could unambiguously decide which format is used.. but then the preference between EFli/EFlp and EFpl is also inverted between the specs
Sep 14 21:34:58 <balrog-kun> on my card only EFpl is used anyway
Sep 14 21:35:35 <denkenz> trouble is there are plenty of these 2G or 2G+ cards around
Sep 14 21:35:46 <denkenz> But what about 3G cards that follow newer specs?
Sep 14 21:36:14 <balrog-kun> let's do the check then and support both
Sep 14 21:37:01 <denkenz> ok
Sep 14 21:37:35 <denkenz> Though its tricky if it is a 2G sim, our logic will be backwards
Sep 14 21:38:48 <denkenz> See if you can make it work per 51.011 if 2G/2G+ is used, and 31.102 if 3G is used
Sep 14 21:39:18 <denkenz> akiniemi: what format does isi accept for cell broadcast language ids?
Sep 14 21:39:31 <denkenz> akiniemi: Is it same as the dcs in 27.007?
Sep 14 21:44:23 <denkenz> balrog-kun: Also can you make the patch apply against head?  I still need to comment on the PIN stuff
Sep 14 21:48:02 <balrog-kun> denkenz: ok, i have a rebased PIN patch too
Sep 14 21:48:25 <balrog-kun> denkenz: can you lock the card using AT once it's unlocked with PIN? you mentioned locking and unlocking in a mail
Sep 14 21:48:55 <denkenz> balrog-kun: Afaik yes you can
Sep 14 21:49:17 <denkenz> +CLCK
Sep 14 21:50:16 <denkenz> Btw, I'm pretty sure no sane SIM will allow IMSI to be read before PIN check
Sep 14 21:50:31 <denkenz> Are you sure your modem wasn't caching IMSI somehow?
Sep 14 21:52:15 <akiniemi> denkenz: don't have the specs here handy
Sep 14 21:53:21 <akiniemi> denkenz: but I think it's an array of bytes, enumerated
Sep 14 21:53:36 <balrog-kun> denkenz: hmm, true about +CLCK, i had associated it with the call barring locks - i'll rename SendPIN to Unlock and add a Lock
Sep 14 21:53:45 <denkenz> akiniemi: So a predefined set of languages?
Sep 14 21:54:08 <balrog-kun> i'll re-check it about reading IMSI before PIN
Sep 14 21:54:48 <akiniemi> denkenz: looks like it
Sep 14 21:55:17 <denkenz> balrog-kun: Yeah, we need Unlock for PINs, something different for PUKs (requires 2 passwords)
Sep 14 21:55:39 <denkenz> balrog-kun: And probably a Lock for PIN
Sep 14 21:56:04 <denkenz> balrog-kun: And we should make the whole thing context-aware, e.g. if PUK required calling unlock is wrong
Sep 14 21:57:05 <denkenz> akiniemi: That is something that just bugs me about CBS spec, the language part is absolutely stupid
Sep 14 21:59:39 <denkenz> Btw, if anyone is in a country with CBS, let me know if the oFono implementation works ;)
Sep 14 22:08:44 <balrog-kun> i was getting the cell name in a CBS last time i tested CBS with openmoko's gsmd
Sep 14 22:08:56 <balrog-kun> i'll try it later
Sep 14 22:09:25 <balrog-kun> it was sent on every reconnect and every 10 or so minutes later
Sep 14 22:11:51 <denkenz> you might have to add it to the calypso driver
**** ENDING LOGGING AT Tue Sep 15 02:59:57 2009

**** BEGIN LOGGING AT Tue Sep 15 02:59:57 2009
Sep 16 00:31:32 <zhenhua> ping denkenz
Sep 16 00:52:49 <denkenz> zhenhua: pong
Sep 16 01:05:50 <zhenhua> hi denis
Sep 16 01:06:11 <zhenhua> the BT spec feature like remote volume control
Sep 16 01:06:25 <zhenhua> requires interface to the end user 
Sep 16 01:06:57 <zhenhua> so i am now creating src/bluetooth.c include/bluetooth.h to include them
Sep 16 01:07:12 <zhenhua> i have one table like this:
Sep 16 01:07:13 <zhenhua> static GDBusMethodTable manager_methods[] = {
Sep 16 01:07:13 <zhenhua> 	{ "GetProperties",	"",	"a{sv}",	get_properties },
Sep 16 01:07:13 <zhenhua> 	{ "DisableNREC",		"",	"",		disable_nrec,
Sep 16 01:07:13 <zhenhua> 							G_DBUS_METHOD_FLAG_ASYNC },	
Sep 16 01:07:14 <zhenhua> 	{ "VoiceRecognition",	"d",	"",		voice_recognition,
Sep 16 01:07:16 <zhenhua> 							G_DBUS_METHOD_FLAG_ASYNC },
Sep 16 01:07:18 <zhenhua> 	{ "AttachVoiceTag",	"",	"s",		attach_voicetag,
Sep 16 01:07:20 <zhenhua> 							G_DBUS_METHOD_FLAG_ASYNC },
Sep 16 01:07:22 <zhenhua> 	{ "VolumeSync",		"",	"",		volume_sync,
Sep 16 01:07:24 <zhenhua> 							G_DBUS_METHOD_FLAG_ASYNC },
Sep 16 01:07:26 <zhenhua> 	{ "ResponseHold",		"",	"",		response_hold,
Sep 16 01:07:28 <zhenhua> 							G_DBUS_METHOD_FLAG_ASYNC },
Sep 16 01:07:30 <zhenhua> 	{ "SubscriberNumber",	"",	"",		subscriber_number,
Sep 16 01:07:32 <zhenhua> 							G_DBUS_METHOD_FLAG_ASYNC },
Sep 16 01:07:34 <zhenhua> 	{ }
Sep 16 01:07:36 <zhenhua> };
Sep 16 01:08:26 <zhenhua> the problem is only that two layer implementation create lots of code but the functionality is actually simple.
Sep 16 01:08:48 <zhenhua> one layer is src/bluetooth.c, the at layer is driver/hfp/bluetooth.c
Sep 16 01:09:03 <zhenhua> any comments on that
Sep 16 01:20:04 <denkenz> Lets figure out the voice recognition stuff later
Sep 16 01:20:21 <denkenz> For now, can you create a simple CallVolume interface, for speaker / mic volume
Sep 16 01:20:42 <denkenz> ResponseHold is also a CDMA feature, it will eventually get put on VoiceCallManager
Sep 16 01:20:50 <denkenz> so leave that one out
Sep 16 01:21:13 <denkenz> SubscriberNumber is already on SimManager, so we'll have to figure something out there
Sep 16 01:21:58 <zhenhua> How about DisableNREC
Sep 16 01:22:14 <zhenhua> And AttachVoiceTag
Sep 16 01:22:51 <zhenhua> you mean we can spread those interface into different drivers. right? It looks fine to me
Sep 16 01:23:13 <zhenhua> and it can save my work
Sep 16 01:23:42 <zhenhua> But CallVolume staff is for bluetooth feature only
Sep 16 01:23:57 <denkenz> Just don't worry about NREC/VoiceTag, that is all a bit advanced, we need to figure it out yet
Sep 16 01:24:08 <denkenz> Call Volume can actually be used by other devices
Sep 16 01:24:10 <zhenhua> okay
Sep 16 01:24:52 <zhenhua> yes. i think audiomanager need to listen propertychanged signal from ofono for that
Sep 16 01:25:11 <denkenz> Yeah, and we can reuse it in generic driver to use +CLVL or +CMUT
Sep 16 01:27:54 <zhenhua> VGM and VGS are controlling HF side volume according to my understanding. how to use CLVL, that is for atmodem
Sep 16 01:28:22 <denkenz> From an app point of view its all the same though
Sep 16 01:28:42 <denkenz> And not all modems might provide this interface anyway
Sep 16 01:28:49 <zhenhua> yes
Sep 16 01:29:34 <zhenhua> i still not sure your idea about reusing CLVL. can you explain more
Sep 16 01:30:24 <zhenhua> you mean we don't need provide bluetooth interface, but reuse interface in atmodem, right?
Sep 16 01:31:07 <denkenz> simply create a call-volume atom that exports SpeakerVolume, MicrophoneVolume attributes
Sep 16 01:31:09 <denkenz> make them percentages
Sep 16 01:31:23 <denkenz> Then the HFP driver can use vgm / vgs, while the generic at driver can use CLVL
Sep 16 01:31:33 <zhenhua> okay
Sep 16 01:31:50 <zhenhua> i will do that
Sep 16 01:34:42 <zhenhua> if you don't disagree,still need src/bluetooth.c to create this new atom. 
Sep 16 01:35:21 <denkenz> call it src/call-volume
Sep 16 01:35:28 <zhenhua> okay
Sep 16 01:35:37 <denkenz> and org.ofono.CallVolume for the interface
Sep 16 01:35:50 <zhenhua> sure
Sep 16 01:36:33 <zhenhua> yes. it saves me lots of works :-)
Sep 16 01:46:00 <balrog-k1n> denkenz: on the sim manager interface, Unlock and EnterPIN would be separate calls, right?
Sep 16 01:46:38 <denkenz> what does EnterPIN do?
Sep 16 01:46:59 <balrog-k1n> send a PIN to the MT if it's waiting for a PIN,
Sep 16 01:47:13 <balrog-k1n> Unlock in turn would disable the PIN authentication for MT startup
Sep 16 01:47:36 <holtmann> Unlock is the wrong term for this.
Sep 16 01:48:07 <denkenz> Perhaps we simply need a PIN attribute?
Sep 16 01:48:23 <denkenz> PIN empty -> no lock, PIN with something -> locked
Sep 16 01:48:59 <denkenz> Then Unlock can actually be used for entering the PIN at startup
Sep 16 01:49:24 <denkenz> Then we need something like UnlockAndReset for PUK entry
Sep 16 01:49:29 <holtmann> We might have to with the an agent callback here. Since an PIN entering should always involve the UI.
Sep 16 01:50:11 <denkenz> Yeah I want an Agent here in the first place actually
Sep 16 01:50:41 <denkenz> But its probably a good idea to make it work first... :)
Sep 16 01:50:44 <holtmann> I would to shortcut it, but with having to power on the hardware to see the SIM PIN status doesn't give us much choice.
Sep 16 01:50:46 <balrog-k1n> denkenz: that was my thinking yesterday, about Unlock
Sep 16 01:51:42 <balrog-k1n> but we wouldn't have a "Lock" then, I can't find a way to go to the "MT is waiting for a password" state once it's unlocked
Sep 16 01:52:08 <denkenz> Lock just sets the PIN for next time
Sep 16 01:52:15 <denkenz> So lets just make it this way:
Sep 16 01:52:37 <denkenz> Property 'Pin', empty -> unlocked, value -> Locked
Sep 16 01:52:52 <denkenz> Method 'Unlock' -> provides a PIN
Sep 16 01:52:55 <holtmann> Nope. We can not have the PIN as a property.
Sep 16 01:53:09 <denkenz> Method 'UnlockAndReset' -> Provide puk & new pin
Sep 16 01:53:10 <balrog-k1n> what value would it have when Locked?
Sep 16 01:53:17 <denkenz> '1234' or something
Sep 16 01:53:38 <balrog-k1n> so we would expose the PIN for everyone to read?
Sep 16 01:53:45 <denkenz> holtmann: Then GetLocked() SetLocked() perhaps?
Sep 16 01:53:59 <holtmann> Nope. We just have to for the agent.
Sep 16 01:54:23 <denkenz> We still need a way to Lock the PIN
Sep 16 01:54:27 <holtmann> I don't see any other way to sort this out. Especially since the modem startup is blocked with this.
Sep 16 01:54:54 <holtmann> It can return the PIN from the agent via a return value. It is uni-directional messaging.
Sep 16 01:55:10 <denkenz> no no, you're not getting it
Sep 16 01:55:19 <denkenz> There's a way to set a PIN on an unlocked SIM
Sep 16 01:55:42 <denkenz> so that next time the modem should do the whole CPIN crap
Sep 16 01:55:57 <holtmann> You mean that one. I call that ChangePIN() and if previous set, it ask via agent for the current PIN, if not, it just goes ahead and sets it.
Sep 16 01:56:25 <holtmann> Same goes for RemovePIN() or similar wording.
Sep 16 01:56:29 <denkenz> So just make that an attribute :)
Sep 16 01:56:35 <holtmann> Or ChangePIN("").
Sep 16 01:56:50 <denkenz> Cleaner in my opinion
Sep 16 01:56:57 <holtmann> Not really. An attribute should be also readable. The PIN should not be readable.
Sep 16 01:57:03 <balrog-k1n> ChangePIN requires old pin too
Sep 16 01:57:27 <holtmann> As I said, I could request the old PIN via the agent. Same agent that we use to request it on startup.
Sep 16 01:57:54 <holtmann> denkenz: Neverless, time for dinner.
Sep 16 01:58:11 <denkenz> Then lets make it SetPin and make proper agents
Sep 16 01:58:18 <denkenz> holtmann: yep, heading out now
Sep 16 02:01:44 <balrog-k1n> what's the difference betwen requesting something from an agent and say, sending a signal and waiting for something to be called on a dbus interface?  i may be missing the terminology
**** ENDING LOGGING AT Wed Sep 16 02:59:57 2009

**** BEGIN LOGGING AT Wed Sep 16 02:59:57 2009
Sep 16 11:06:16 <Sage> How the modem loading should work currently? I see that the .at.Manger.Create is gone and /etc/ofono/modem.conf has replaced it. So should [gt225]\nDriver=hso\nDevice=/dev/ttyHS0 in the modem.conf do the trick? I can see the modem in when sending GetProperties but it says Powered: false and Interfaces is empty.
Sep 16 11:07:41 <Sage> I'm using git version from earlier today.
Sep 16 11:50:24 <inz> Sage, use SetProperty to set powered to true
Sep 16 12:02:50 <Sage> That helped. However the device 0af0:6971 Option that I tested returns "Operation Failed" when trying to turn on the power with hso driver. atgen driver works.
Sep 16 14:47:14 <holtmann> Sage: Option HSO modems via USB should be auto-detected.
Sep 16 17:08:34 <denkenz> balrog-k1n: To answer the question about agents, two main advantages:
Sep 16 17:09:12 <denkenz> They target the specific application that should be providing this information (e.g. the UI), which means no extra apps get woken up / conflicts
Sep 16 17:09:31 <denkenz> They also offer a bit of extra flexibility in terms of asking / reporting information
Sep 16 17:09:52 <denkenz> E.g. on our Agent interface we can have two methods:
Sep 16 17:10:02 <denkenz> s ProvidePin()
Sep 16 17:10:07 <denkenz> s,s ProvidePuk()
Sep 16 17:11:51 <denkenz> So in the case of PIN entry on startup, we simply call the agent if registered, if we're trying to change the Pin, we do the same
Sep 16 17:12:02 <denkenz> Keeps things simple for the app
Sep 16 17:17:14 <denkenz> holtmann: btw, there's one case where the Agent falls down
Sep 16 17:17:19 <denkenz> 22.030 defines the following:
Sep 16 17:17:29 <denkenz> The following procedure permits the user to change the PIN or PIN2 in the SIM/USIM:    	PIN:	**04*OLD_PIN*NEW_PIN*NEW_PIN#  	PIN2:	**042*OLD-PIN2*NEW_PIN2*NEW_PIN2# Note that the SEND function is not used in these procedures.     
Sep 16 18:37:08 <akiniemi> denkenz: are the agents registered at run-time, or install time?
Sep 16 18:38:37 <akiniemi> denkenz: btw, SMSs to certain application ports could use an agent interface, too
Sep 16 18:39:07 <denkenz> akiniemi: Run time
Sep 16 18:39:14 <denkenz> akiniemi: For app ports we use a plugin
Sep 16 18:39:43 <denkenz> akiniemi: Once you guys contribute VCard reception we figure out the details :)
Sep 16 18:44:12 <akiniemi> denkenz: IMO, install time is nicer for things like pin query dialog
Sep 16 18:44:31 <denkenz> akiniemi: Yeah, that one is tricky I agree
Sep 16 18:44:50 <akiniemi> denkenz: by install time I mean putting a config file under /usr/share/ofono/agents or something
Sep 16 18:45:00 <denkenz> akiniemi: however, the UI must be up for PIN entry anyway
Sep 16 18:45:08 <denkenz> akiniemi: So install time doesn't buy us much
Sep 16 18:45:35 <akiniemi> Well, the pin query dialog doesn't need to run all the time
Sep 16 18:45:54 <akiniemi> D-Bus can kick it, provided we use install time registration
Sep 16 18:46:26 <akiniemi> Otherwise, you need some script in the boot sequence, just to dbus-send this registration
Sep 16 18:46:26 <denkenz> akiniemi: I'm not the expert on agents btw, holtmann is
Sep 16 18:46:29 <akiniemi> yuck
Sep 16 18:46:45 <denkenz> akiniemi: But from everything I've seen, they use a TSR UI element
Sep 16 18:47:25 <denkenz> akiniemi: dbus-send the registration? The UI does that part
Sep 16 18:47:58 <akiniemi> denkenz: right, but only if the UI runs
Sep 16 18:48:16 <denkenz> akiniemi: If the UI is not running we can't do jack :)
Sep 16 18:48:23 <denkenz> akiniemi: Who will provide the PIN?
Sep 16 18:49:15 <akiniemi> denkenz: you'd have a config file that says which object to call
Sep 16 18:49:32 <denkenz> akiniemi: again, I'm not the expert here, but dbus-session activation is probably not something you want to depend on either
Sep 16 18:49:37 <akiniemi> denkenz: then another .service file, by which D-Bus knows whom to start
Sep 16 18:49:54 <akiniemi> denkenz: we do it all the time ;)
Sep 16 18:49:57 <denkenz> akiniemi: What if X isn't even up? or the dbus session bus?
Sep 16 18:50:29 <courmisch> you won't run ofonod on the sesion bus anyway
Sep 16 18:50:55 <denkenz> no, but if I remember dbus correctly only the session bus supports activation
Sep 16 18:51:15 <denkenz> again, IMO too complicated, but holtmann is the expert here
Sep 16 18:51:15 <akiniemi> denkenz: You don't need the PIN that early anyway
Sep 16 18:51:31 <akiniemi> denkenz: what if a call comes in and you have no X, session bus yet?
Sep 16 18:51:45 <denkenz> actually you can't even register to the network without the PIN
Sep 16 18:51:51 <inz> denkenz, system bus does activation too
Sep 16 18:52:14 <denkenz> inz: Ok, didn't know that :)
Sep 16 18:52:14 <inz> denkenz, it is not too nice to launch UI programs there though
Sep 16 18:52:37 <inz> denkenz, ls /usr/share/dbus-1/system-services/ ;)
Sep 16 18:52:57 <denkenz> I still think all of that is too evil :)
Sep 16 18:53:10 <denkenz> simply start the UI as part of the session
Sep 16 18:53:24 <holtmann> akiniemi, denkenz: Don't worry guys, I take care of the agent stuff.
Sep 16 18:53:51 <inz> holtmann, "Trust me, I know what I'm doing"?
Sep 16 18:53:54 <holtmann> It really takes care of all this nicely. So don't bother here ;)
Sep 16 18:54:14 <holtmann> Trust me, we have done it before and it worked out.
Sep 16 18:54:31 <denkenz> holtmann: We need the agent for SIM pin stuff
Sep 16 18:54:35 <denkenz> holtmann: Lets figure this out today
Sep 16 18:56:06 <akiniemi> holtmann: any pointers?
Sep 16 18:56:10 <denkenz> inz: Btw, I do trust holtmann here since he's done this in connman & bluez ;)
Sep 16 18:59:10 <holtmann> akiniemi: Yes, BlueZ in big detail and ConnMan just started to use agents.
Sep 16 19:15:59 <akiniemi> holtmann: I don't disagree with the agent concept
Sep 16 19:17:48 <akiniemi> holtmann: just that I would prefer install-time registration of agents instead of run-time
Sep 16 19:20:05 <akiniemi> holtmann: especially for PIN query, as there is always going to be just that one agent
Sep 16 19:20:25 <akiniemi> holtmann: I could imagine run-time registration for other things though
Sep 16 19:51:26 <holtmann> akiniemi: Actually you can still do that. The agents are in theory stackable. However for the PIN stuff, you do need the UI up and running. Otherwise how you ask the user.
Sep 16 19:51:56 <holtmann> For non interactive systems, using the PIN facility at all makes no sense. Unless you have an encrypted and secure system where the PIN can not leak.
Sep 16 19:56:06 <denkenz> Lets document the proposed agent API
Sep 16 19:56:18 <akiniemi> holtmann: I was suggesting using D-Bus autostart
Sep 16 19:56:49 <denkenz> akiniemi: Personally I don'tget what it buys you, and thus against it ;)
Sep 16 19:57:04 <holtmann> akiniemi: Not really needed and actually a bad idea.
Sep 16 19:57:54 <akiniemi> denkenz, holtmann: you're bound to use D-Bus autostart in any Äcase
Sep 16 19:58:08 <denkenz> how?
Sep 16 19:58:18 <holtmann> So we actually want the UI to register their agents. Main reason here is that ofonod, then knows that the UI is up and running and it can use the agent to ask for the PIN for example.
Sep 16 19:58:30 <akiniemi> like at boot time, register agent, and after the PIN query, exit
Sep 16 19:59:00 <holtmann> akiniemi: I see, you are having a little bit different view point is. Let me try to explain.
Sep 16 19:59:17 <holtmann> D-Bus autostart is not going to solve this. It is really not.
Sep 16 19:59:18 <denkenz> The agent is actually used after boot up too, e.g. if the user changes the PIN
Sep 16 19:59:47 <akiniemi> denkenz: Sure, and D-Bus can start it up
Sep 16 20:00:04 <holtmann> akiniemi: So what happens you wanna start ofonod at some point. In case of the mobile phone or any kind of device with static hardware components you just start it via init/upstart.
Sep 16 20:00:06 <holtmann> Plain and simple.
Sep 16 20:00:47 <denkenz> he's talking about autostart for the agent
Sep 16 20:00:49 <holtmann> In case of desktop system or similar, you are using udev to start it once you attach hardware that is supported by oFono.
Sep 16 20:00:50 <akiniemi> holtmann: and?
Sep 16 20:00:52 <denkenz> not for ofonod
Sep 16 20:01:29 <holtmann> This is not D-Bus autostart, this is udev based stating the system daemon on-demand. Actually BlueZ does it already this way nowadays.
Sep 16 20:01:48 <akiniemi> I'm not talking about starting ofonod
Sep 16 20:01:59 <holtmann> Hold on, getting to it.
Sep 16 20:02:47 <holtmann> So when ofonod starts it will start and init the hardware it finds. So in case of no PIN SIMs it can just go ahead and do all the work. No need to wait for the UI or anything.
Sep 16 20:03:08 <holtmann> In case a PIN is required, it has to wait until the UI is up and can use it to actually ask the user.
Sep 16 20:03:39 <holtmann> Only the UI knows when it is up and running and ready to ask user input. We from an oFono system point of view have no clue. And devices might be different.
Sep 16 20:04:44 <akiniemi> I think you might be arguing for a voicecall agent, in fact
Sep 16 20:04:45 <holtmann> So the UI starts up and start the dialer or phone UI or whatever. This phone UI contains the oFono agent in it. This now registers this agent with ofonod and pronto we know that we can process with the SIM PIN stuff.
Sep 16 20:04:57 <akiniemi> ofonod should not ready cellular, if there is no UI to handle calls
Sep 16 20:05:12 <holtmann> ofonod now asks the PIN to the agent, the agent replies, puts it in and there we go.
Sep 16 20:05:15 <denkenz> why not? the UI can startup and do GetProperties
Sep 16 20:05:35 <denkenz> all calls will be reflected there, if your UI takes more time than call timeout you're in trouble anyway
Sep 16 20:06:05 <holtmann> akiniemi: Actually I have no real problem with moving the call accept to an agent.
Sep 16 20:06:47 <holtmann> akiniemi: Remember one thing. We do have other devices than only mobile phone where we wanna make oFono work. Some of them might no have a UI and we need to be flexible.
Sep 16 20:07:38 <denkenz> I don't necessarily like the Accept call being in an Agent, but perhaps I can be convinced
Sep 16 20:08:19 <denkenz> Trouble is really the warped GSM logic of what you can/cannot do while in Waiting state
Sep 16 20:08:53 <akiniemi> holtmann: hmm.. so I guess for PIN query runÃ-time registration only actually makes sense.
Sep 16 20:09:11 <akiniemi> holtmann: since this is typically done at boot time only
Sep 16 20:09:42 <holtmann> I guess Johan can explain why better how it works in BlueZ and how we do it. It is kinda hard concept to explain over IRC without drawing graphics.
Sep 16 20:10:48 <akiniemi> holtmann: I know how it works, we use similar stuff elsewhere
Sep 16 20:11:15 <akiniemi> holtmann: my point was that for things that happen very rarely, it is silly to require run-time registration
Sep 16 20:11:40 <denkenz> Wouldn't the homescreen app always be running?
Sep 16 20:11:55 <denkenz> Otherwise who takes care of signal strength updates, etc?
Sep 16 20:12:04 <akiniemi> denkenz: as an example, WAP push handling
Sep 16 20:12:31 <holtmann> You have the UI app that show the signal strength. So just add the agent piece there.
Sep 16 20:12:45 <holtmann> We have no dedicated agent for BlueZ or ConnMan. We just integrate into the applet.
Sep 16 20:12:54 <denkenz> Yeah but that one we can do as a plugin that can even write them directly to the database
Sep 16 20:13:01 <denkenz> Or use any other sort of notification mechanism
Sep 16 20:13:12 <akiniemi> for signal strength, you'd probably want agent, but for entirely different reasons
Sep 16 20:13:14 <holtmann> We can do WAP push or MMS trigger via the agent, too. It is not limited to PIN handling.
Sep 16 20:13:32 <akiniemi> like ofonod being able to stop polling when no agent is registered
Sep 16 20:13:43 <denkenz> stop polling?
Sep 16 20:13:52 <holtmann> For signal strength the notification via D-Bus signal is fine. We do the agent for PIN stuff etc. So we know when it is present since we expect a response.
Sep 16 20:13:54 <denkenz> We don't poll :)
Sep 16 20:14:03 <akiniemi> denkenz: if you did ;)
Sep 16 20:14:11 <denkenz> Yah, _if_ ;)
Sep 16 20:14:40 <holtmann> And yes, if agent registered and you have hardware where you need to poll, we could use that as an indication.
Sep 16 20:15:07 <denkenz> No real hardware needs to be polled for that though
Sep 16 20:15:16 <denkenz> I think we can safely ignore this problem
Sep 16 20:15:32 <akiniemi> holtmann: indeed, and for that wap push type thingies, installing a config file makes more sense than requiring registration via D-Bus
Sep 16 20:15:44 <akiniemi> holtmann: I mean, how often do you get MMSs? ;)
Sep 16 20:17:23 <akiniemi> denkenz: and who's to say modem APIs don't have a way to pass this "not interested" signal on?
Sep 16 20:18:00 <denkenz> akiniemi: I just don't get why anyone would want to do this
Sep 16 20:18:15 <denkenz> akiniemi: If you don't have the homescreen up, you should perhaps power down the modem
Sep 16 20:18:30 <denkenz> akiniemi: Lets not make things complicated
Sep 16 20:18:31 <akiniemi> denkenz: you serious?
Sep 16 20:19:03 <denkenz> akiniemi: What possible reason do you need to turn off signal strength notifications?  I can only think of one case: suspend/resume
Sep 16 20:20:24 <akiniemi> denkenz: if your screen is blank, why wake up ofonod and everything listening on its signals?
Sep 16 20:20:33 <akiniemi> denkenz: less wakeups, less power drain
Sep 16 20:20:49 <denkenz> akiniemi: If your screen is blank you're probably in suspend mode anyway
Sep 16 20:21:09 <akiniemi> denkenz: suspend != modem poweroff
Sep 16 20:21:17 <denkenz> akiniemi: I didn't say it was...
Sep 16 20:21:42 <denkenz> akiniemi: We will add suspend/resume callbacks to each driver once we start implementing power management
Sep 16 20:22:07 <denkenz> akiniemi: But explicitly turning signal strength notifications if no agent is present is too silly IMO
Sep 16 20:23:48 <akiniemi> denkenz: so what would drive the core to call a driver to suspend?
Sep 16 20:24:14 <denkenz> akiniemi: We need to figure that out, my best idea so far is explicit PowerSave property
Sep 16 20:24:30 <denkenz> akiniemi: Which will call each atom's suspend/resume method
Sep 16 20:24:50 <denkenz> But I doubt its as simple as that
Sep 16 20:25:23 <denkenz> the suspend / resume can actually turn off creg notifications, signal strength, gprs reg, etc
Sep 16 20:25:53 <denkenz> There's actually a lot of stuff to turn off than signal strength ;)
Sep 16 20:26:11 <akiniemi> denkenz: of course
Sep 16 20:26:39 <akiniemi> denkenz: cell ID for instance is known to change a lot sometimes even for stationary devices
Sep 16 20:27:02 <denkenz> hence creg ;)
Sep 16 20:27:17 <akiniemi> denkenz: how would you know when to disable it, though
Sep 16 20:27:26 <denkenz> Again, we need to discuss proper power save mode infrastructure
Sep 16 20:27:44 <denkenz> I suspect a simple timeout might work, but only the UI actually knows this properly
Sep 16 20:28:35 <denkenz> E.g. the iPhone simply turns everything off after x minutes going into suspend mode
Sep 16 20:28:45 <denkenz> Unless something like Google Maps is active
Sep 16 20:29:26 <akiniemi> denkenz: I suspect platform dependant powersave plugins would be the best way forward
Sep 16 20:29:52 <denkenz> Sure, and I honestly haven't thought about it until I see proper power save requirements
Sep 16 20:30:08 <denkenz> But we need to do this properly, not expose the core to a bunch of useless crap
Sep 16 20:31:05 <akiniemi> denkenz: yeah, this is really not that simple at all
Sep 16 20:31:27 <akiniemi> for instance, let's say you suspend creg
Sep 16 20:31:49 <akiniemi> then syncing state after resume is going to draw more power
Sep 16 20:32:54 <denkenz> so I suspect the plugin would have to send the creg notification itself
Sep 16 20:33:15 <denkenz> The core should not do anything after suspend / resume
Sep 16 20:33:19 <denkenz> It simply doesn't care 
Sep 16 20:33:36 <denkenz> I could be wrong though...
Sep 16 20:34:24 <denkenz> The power management on all of these devices is so convoluted and different across the board, that I prefer to keep oFono simple and ignorant
Sep 16 20:34:53 <akiniemi> ignorance is bliss ;)
Sep 16 20:35:15 <denkenz> Yep, but in our case its actually the only way to handle all of these devices
Sep 16 23:05:56 <denkenz> balrog-k1n: so after much back and forth between me & holtmann we finally reached a consensus on the SIM Lock API
Sep 16 23:06:13 <denkenz> balrog-k1n: Its basically the original approach suggested by you.  Take a look at doc/sim-api.txt
Sep 16 23:55:06 <denkenz> holtmann: One thing I'm still thinking we should do is put the locking bit onto the Modem interface instead of SimManager
Sep 16 23:55:47 <denkenz> holtmann: Since we shouldn't even populate the atoms until the SIM unlock is done
Sep 16 23:56:30 <denkenz> holtmann: This would also take care of the sim inserted / removed case
Sep 17 02:32:44 <holtmann> denkenz: Putting it on the modem interface looks fine to me.
Sep 17 02:33:34 <denkenz> holtmann: let me see how far we get with pre_sim / post_sim idea, maybe we simply keep it on the SimManager interface
**** ENDING LOGGING AT Thu Sep 17 02:59:57 2009

**** BEGIN LOGGING AT Thu Sep 17 02:59:57 2009
Sep 17 04:01:47 <tmzt> might not be an issue for you at this point, but not all devices (cdma for instance) even have sim
Sep 17 05:20:14 <denkenz> tmzt: Yeah we know, we figure that part out eventually
Sep 17 05:21:17 <tmzt> you are working on msm driver?
Sep 17 05:22:04 <denkenz> nope
Sep 17 05:22:25 <tmzt> do you remember who was? (g1 driver I mean)
Sep 17 05:22:33 <denkenz> dilinger
Sep 17 05:23:39 <tmzt> thank you
Sep 17 05:30:48 <dilinger> hm?
Sep 17 05:34:07 * dilinger sleeps
Sep 17 06:19:07 <Sage> holtmann: Well this Pption iCon 225 (Bus 003 Device 003: ID 0af0:6971 Option) is not detected automatically by ofonod. After starting the ofonod .Manager.GetProperties does not show any modems. Another thing is that I cannot power the modem on with hso driver but with atgen driver I can.
Sep 17 12:09:12 <balrog-k1n> denkenz: thanks, the doc looks sane but there'll be an issue with implementing ChangePin(string type, string oldpin, string newpin) on top of AT,
Sep 17 12:10:04 <balrog-k1n> ChangePin("pin", "1234", "") would disable pin authentication and leave the PIN unchanged on the sim,
Sep 17 12:11:06 <balrog-k1n> so if you want to re-enable PIN authentication next, you'll still need the old pin
Sep 17 12:11:45 <balrog-k1n> e.g. ChangePin("pin", "", "4321") won't work
Sep 17 12:24:56 <balrog-k1n> do we want to write PIN in capitals?  since pin as an initialism and as a word have different meanings
Sep 17 15:33:16 <denkenz> balrog-k1n: So are you sure that AT+CLCK="PS",0,oldpin won't do it?
Sep 17 15:37:27 <denkenz> balrog-k1n: as far as SIM/PIN being in caps.  I generally hate how ugly that looks in camel cased APIs.  So for now the convention is to drop to lower case chars anyway.  E.g. SimManager, CbsManager, etc
Sep 17 15:51:52 <denkenz> balrog-k1n: Worst case make up some pin like '0000' to act as the unlocked case
Sep 17 16:05:39 <dilinger> inz: let me know if you didn't get my messages
Sep 17 16:27:12 <dilinger> has the phonesim stuff been released into the public yet?
**** ENDING LOGGING AT Fri Sep 18 02:59:56 2009

**** BEGIN LOGGING AT Fri Sep 18 02:59:56 2009
Sep 18 17:56:30 <ccbbaa> hello
Sep 18 17:56:47 <ccbbaa> what ofono release goes with what libc and kernel ?
Sep 18 18:19:21 <holtmann> ccbbaa: Any recent distro should be fine. I am testing it on Fedora 11 for example.
Sep 18 18:19:57 <ccbbaa> holtmann: thanks. what is your glibc version ?
Sep 18 18:20:22 <holtmann> glibc-2.10.1-5.x86_64
Sep 18 18:21:55 <ccbbaa> holtmann: whoa i have 2.3.6
Sep 18 18:22:11 <ccbbaa> looks like upgrade time real soon now [tm]
Sep 18 18:22:25 <holtmann> That might a little bit old. However where does it fail?
Sep 18 18:22:42 <ccbbaa> *nux is a firehose, i have to go back to more relaxed bsd
Sep 18 18:22:44 <ccbbaa> holtmann: several functions are missing
Sep 18 18:22:48 <ccbbaa> don't worry about it
Sep 18 18:22:54 <ccbbaa> it's debian oldstable
Sep 18 18:23:01 <ccbbaa> etch
Sep 18 18:37:27 <denkenz> holtmann: Test the new improved gatchat fix
**** ENDING LOGGING AT Sat Sep 19 02:59:58 2009

**** BEGIN LOGGING AT Sat Sep 19 02:59:59 2009
**** ENDING LOGGING AT Sun Sep 20 02:59:57 2009

**** BEGIN LOGGING AT Sun Sep 20 02:59:57 2009
**** ENDING LOGGING AT Mon Sep 21 02:59:56 2009

**** BEGIN LOGGING AT Mon Sep 21 02:59:56 2009
Sep 21 21:24:58 <dilinger> so yeah, anyone?  was the phone sim stuff ever released?
**** ENDING LOGGING AT Tue Sep 22 02:59:57 2009

**** BEGIN LOGGING AT Tue Sep 22 02:59:57 2009
Sep 22 16:02:11 <denkenz> dilinger: We release phonesim once Plumbers is over
Sep 22 16:04:20 <dilinger> denkenz: ok, thanks.  Robot101 and i will be there to remind you ;)
Sep 23 00:21:24 <zhenhua> denkenz: hi denis, have you got my patch?
Sep 23 00:21:49 <denkenz> zhenhua: Yes, but I've had no time to look at it, I do it sometime next week
Sep 23 00:22:02 <zhenhua> sure. no problem. 
Sep 23 00:22:26 <zhenhua> I just want to let you see the progress and feel free to let me know your comments
Sep 23 00:23:12 <zhenhua> maybe you could have chance to discuss it with Marcel.
Sep 23 00:23:13 <denkenz> Sure, this week is just bad since the entire week is taken up by LinuxCon + PlumbersConf
Sep 23 00:23:34 <zhenhua> That's great conf I think.
Sep 23 00:24:15 <zhenhua> one thing is that we will have a long national holiday from Oct 1st to Oct 8th in China.
Sep 23 00:24:50 <zhenhua> so I could not give you back until Oct 9th.
Sep 23 00:26:55 <denkenz> sok, worst case I simply pull the code and fix it :)
Sep 23 00:28:08 <zhenhua> wow, i would be very very happy to see that happen.:)
Sep 23 00:28:52 <zhenhua> will you give some speech in LinuxCon;-)
Sep 23 00:37:50 <holtmann> denkenz: I have a problem with g_at_chat and ATD.
Sep 23 00:37:57 <denkenz> ?
Sep 23 00:38:12 <holtmann> I get the first PPP frames before the CONNECT and then the callback from the command is not called.
Sep 23 00:38:37 <denkenz> wtf, how is that even possible?
Sep 23 00:38:37 <holtmann> > AT+CGDCONT=1,"IP","isp.cingular"\r
Sep 23 00:38:38 <holtmann> < \r\nOK\r\n
Sep 23 00:38:38 <holtmann> > ATD*99***1#\r
Sep 23 00:38:38 <holtmann> < ~\777}#\700!}!}!} }9}#}%\702#}%}(}"}'}"}"}&} } } } }%}&\731WI}36$~
Sep 23 00:38:38 <holtmann> < \r\nCONNECT\r\n
Sep 23 00:38:39 <holtmann> < ~\777}#\700!}!}"} }9}#}%\702#}%}(}"}'}"}"}&} } } } }%}&\731WI}3\772\711~
Sep 23 00:39:11 <holtmann> I can ignore the first frame since it will be send again anyway. However I like to get the callback when CONNECT is send.
Sep 23 00:40:42 <denkenz> Strange, you should get the callback
Sep 23 00:42:17 <denkenz> what parser are you using? v1?
Sep 23 00:42:46 <denkenz> The garbage state in that one will not work it seems...
Sep 23 00:46:04 <holtmann> Let me try permissive.
Sep 23 00:46:34 <holtmann> So with permissive it does work.
Sep 23 00:47:31 <holtmann> Stupid modem. Why can't it wait with the PPP frames until after the CONNECT.
Sep 23 00:47:47 <denkenz> exactly, that is stupid
Sep 23 00:48:26 <holtmann> Now I have to write the PPP parser. Lets see how far I get with that one.
**** ENDING LOGGING AT Wed Sep 23 02:59:58 2009

**** BEGIN LOGGING AT Wed Sep 23 02:59:58 2009
Sep 23 05:48:22 <tmzt> msm again?
Sep 23 06:04:59 <denkenz> yes, its another ericsson device
Sep 23 06:05:18 <denkenz> I really want the shit they're smoking
Sep 23 06:14:02 <tmzt> ericsson using qualcomm chip?
Sep 23 06:16:03 <tmzt> what glib framework are you using for this ppp/hdlc work?
**** ENDING LOGGING AT Thu Sep 24 02:59:58 2009

**** BEGIN LOGGING AT Thu Sep 24 02:59:58 2009
**** BEGIN LOGGING AT Thu Sep 24 09:12:04 2009
**** ENDING LOGGING AT Fri Sep 25 02:59:58 2009

**** BEGIN LOGGING AT Fri Sep 25 02:59:58 2009
Sep 25 05:37:22 <denkenz> holtmann: Are there any special udev rules I need to get the 3g dongle working?
Sep 25 13:06:10 <holtmann> denkenz: Yes. They are in plugins/ofono.rules.
**** ENDING LOGGING AT Sat Sep 26 02:59:57 2009

**** BEGIN LOGGING AT Sat Sep 26 02:59:58 2009
Sep 27 01:32:59 <zhenhua> holtmann: hi Marcel
Sep 27 02:54:01 <holtmann> zhenhua: Hi.
**** ENDING LOGGING AT Sun Sep 27 02:59:56 2009

**** BEGIN LOGGING AT Sun Sep 27 02:59:56 2009
Sep 27 03:11:20 <zhenhua> holtmann: just let you know i am revising my patch and will send you a new one. :)
Sep 27 03:12:35 <holtmann> Great.
Sep 27 03:12:56 <holtmann> I still needs to be reviewed by Denis, but these where the obvious issues.
Sep 27 03:15:19 <zhenhua> one thing like g_drivers = g_slist_remove(g_drivers, (void *)d);
Sep 27 03:15:52 <zhenhua> i take reference from other code. There's no space between (void *) and variable 'd'
Sep 27 03:16:02 <zhenhua> but it's a small thing
Sep 27 03:17:03 <holtmann> That is a wrong coding style in the other files as well.
Sep 27 03:17:14 <holtmann> Between a cast and a variable we do a space.
Sep 27 03:18:17 <zhenhua> okay. i just fix it in my code.
Sep 27 03:19:07 <zhenhua> and I found some interface like NETWORK_OPERATOR_INTERFACE is defined in .c file while some is defined in include/dbus.h
Sep 27 03:19:23 <zhenhua> like OFONO_CALL_SETTINGS_INTERFACE. 
Sep 27 03:20:20 <zhenhua> my interface is in call-volume.c and use your suggested code style now
Sep 27 03:20:55 <holtmann> I am fine either way, but at some point it needs to cleaned up.
Sep 27 03:22:40 <zhenhua> ok. got you.
**** ENDING LOGGING AT Mon Sep 28 02:59:57 2009

**** BEGIN LOGGING AT Mon Sep 28 02:59:57 2009
Sep 28 17:37:18 <denkenz> holtmann: See if you can detect a slight 'problem' in the following response from Ericsson F3607
Sep 28 17:37:21 <denkenz> \r\n+COPS: (2,"AT&T","","310410"),0),(1,"T-Mobile","
Sep 28 17:37:23 <denkenz> T-Mobile","31026",0)\r\n\r\nOK\r\n
Sep 28 17:38:03 <holtmann> Nice )
Sep 28 17:38:09 <holtmann> Where does that come from?
Sep 28 17:38:27 <denkenz> From the extra special one I have :)
Sep 28 17:38:39 <denkenz> Sounds like yet another quirk time
Sep 28 17:39:10 <holtmann> I don't think that mine does that, but AT&T doesn't like me roam on Rogers in BC at all.
Sep 28 17:39:32 <denkenz> hehe, double check, it actually parses the ATT one fine
Sep 28 17:40:23 <denkenz> fine as in it ignores the tech field
Sep 28 17:42:11 <denkenz> also, I need to change plugins/udev.c to handle the description being returned by this card
Sep 28 17:42:17 <denkenz> it is slighly different than your X200
Sep 28 17:42:53 <holtmann> How so? It shouldn't be different.
Sep 28 17:43:13 <holtmann> AT+COPS=?
Sep 28 17:43:13 <holtmann> +COPS: (1,"Rogers Wireless","Rogers","302720",2),(1,"","","302880",2),(1,"Rogers Wireless","Rogers","302720",0)
Sep 28 17:43:13 <holtmann> OK
Sep 28 17:43:38 <holtmann> That is what mine is doing.
Sep 28 17:43:57 <denkenz> yours looks fine
Sep 28 17:44:09 <denkenz> Here's what mine reports on lsusb:
Sep 28 17:44:19 <holtmann> Maybe the & in the network name screws it up.
Sep 28 17:44:58 <denkenz> F3607gw Mobile Broadband Data Modem
Sep 28 17:45:25 <denkenz> (2,"AT&T","","310410"),0)
Sep 28 17:45:43 <denkenz> the next-to-last paren shouldn't be there
Sep 28 17:46:03 <holtmann> Mine is a Ericsson F3507g. So they might have screwed up the firmware.
Sep 28 17:46:26 <denkenz> Yah, but udev.c checks for Minicard Data Modem
Sep 28 17:46:32 <denkenz> mine reports Broadband Data Modem
Sep 28 17:47:36 <holtmann> cat /sys/class/tty/ttyACM*/device/interface
Sep 28 17:47:51 <holtmann> cat /sys/class/net/usb*/device/interface
Sep 28 17:48:00 <denkenz> F3607gw Mobile Broadband Data Modem
Sep 28 17:48:01 <denkenz> F3607gw Mobile Broadband Modem
Sep 28 17:48:03 <denkenz> F3607gw Mobile Broadband GPS Port
Sep 28 17:48:05 <denkenz> I fixed it in my tree btw
Sep 28 17:48:08 <holtmann> cat /sys/class/usb/cdc-wdm*/device/interface
Sep 28 17:48:35 <denkenz> F3607gw Mobile Broadband Network Adapter
Sep 28 17:48:49 <denkenz> F3607gw Mobile Broadband Device Management
Sep 28 17:48:50 <denkenz> F3607gw Mobile Broadband USIM Port
Sep 28 17:48:54 <holtmann> Hah. So the left the Minicard part out of it.
Sep 28 17:49:47 <holtmann> Ericsson F3507g Mobile Broadband Minicard Modem
Sep 28 17:49:47 <holtmann> Ericsson F3507g Mobile Broadband Minicard Data Modem
Sep 28 17:49:47 <holtmann> Ericsson F3507g Mobile Broadband Minicard GPS Port
Sep 28 17:49:54 <holtmann> Ericsson F3507g Mobile Broadband Minicard Network Adapter
Sep 28 17:49:58 <holtmann> Ericsson F3507g Mobile Broadband Minicard Device Management
Sep 28 17:49:58 <holtmann> Ericsson F3507g Mobile Broadband Minicard PC SC Port
Sep 28 17:50:03 <holtmann> These are mine.
Sep 28 17:50:08 <denkenz> heh
Sep 28 17:50:24 <denkenz> my fix just uses Minicard * and Broadband * 
Sep 28 17:50:40 <holtmann> That is fine to me.
Sep 28 17:53:07 <denkenz> pushed
Sep 28 17:53:27 <denkenz> Btw, running the 2.6.30 kernel I get no issues, just works out of the box
Sep 28 17:53:51 <denkenz> Though I did have to modify cdc-ether to whitelist the card
Sep 28 17:53:58 <denkenz> is .31 the one that is borked?
Sep 28 17:56:09 <holtmann> That what I am thinking. Try at least 2.6.32-rc1.
**** ENDING LOGGING AT Tue Sep 29 02:59:58 2009

**** BEGIN LOGGING AT Tue Sep 29 02:59:58 2009
Sep 29 04:27:11 <zhenhua> denkenz: the voicecall might need big changes if we use CIEV indicator. Do you really want this? or continue enhance current voicecall?
Sep 29 04:42:54 <denkenz> zhenhua: Do it properly per HFP spec
Sep 29 04:43:11 <denkenz> zhenhua: I already expected the HFP voicecall to be utterly different
Sep 29 04:45:44 <denkenz> zhenhua: Btw, the only hard part is when enhanced call notifications are absent, the rest is actually easier than what is in atmodem driver
Sep 29 04:57:31 <zhenhua> ok
Sep 29 20:46:31 <denkenz> holtmann: Does the mbm hardware expose multiple network adapters by any chance?
Sep 29 20:46:38 <denkenz> holtmann: lsusb shows at least 3
Sep 29 20:46:55 <holtmann> Are you sure these are network adapters?
Sep 29 20:47:08 <denkenz> denkenz@dkenzior-MOBL1 ~/devel/glib/glib $ sudo lsusb -v | grep Network
Sep 29 20:47:10 <denkenz> Bus 001 Device 009: ID 0bdb:1906 Ericsson Business Mobile Networks BV 
Sep 29 20:47:11 <denkenz>   idVendor           0x0bdb Ericsson Business Mobile Networks BV
Sep 29 20:47:12 <holtmann> Does /proc/bus/usb/devices shows unused endpoints.
Sep 29 20:47:13 <denkenz>       iInterface             11 F3607gw Mobile Broadband Network Adapter
Sep 29 20:47:14 <denkenz>       iInterface             13 F3607gw Mobile Broadband Network Adapter
Sep 29 20:47:16 <denkenz>       iInterface             14 F3607gw Mobile Broadband Network Adapter
Sep 29 20:47:17 <denkenz>       iInterface             15 F3607gw Mobile Broadband Network Adapter
Sep 29 20:47:19 <denkenz>       iInterface             11 F3607gw Mobile Broadband Network Adapter
Sep 29 20:47:20 <denkenz>       iInterface             13 F3607gw Mobile Broadband Network Adapter
Sep 29 20:47:22 <denkenz>       iInterface             14 F3607gw Mobile Broadband Network Adapter
Sep 29 20:47:23 <denkenz>       iInterface             15 F3607gw Mobile Broadband Network Adapter
Sep 29 20:47:52 <denkenz> how do I tell?
Sep 29 20:48:11 <holtmann> Check /proc/bus/usb/devices.
Sep 29 20:48:31 <denkenz> S:  Product=F3607gw
Sep 29 20:48:33 <denkenz> S:  SerialNumber=0044017003234010
Sep 29 20:48:34 <denkenz> C:* #Ifs=11 Cfg#= 1 Atr=e0 MxPwr= 20mA
Sep 29 20:48:36 <denkenz> I:* If#= 0 Alt= 0 #EPs= 0 Cls=02(comm.) Sub=08 Prot=00 Driver=(none)
Sep 29 20:48:37 <denkenz> I:* If#= 1 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
Sep 29 20:48:39 <denkenz> E:  Ad=8a(I) Atr=03(Int.) MxPS=  16 Ivl=16ms
Sep 29 20:48:40 <denkenz> I:* If#= 2 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
Sep 29 20:48:42 <denkenz> E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:48:43 <denkenz> E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:48:45 <denkenz> I:* If#= 3 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
Sep 29 20:48:46 <denkenz> E:  Ad=89(I) Atr=03(Int.) MxPS=  16 Ivl=16ms
Sep 29 20:48:48 <denkenz> I:* If#= 4 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
Sep 29 20:48:50 <denkenz> E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:48:52 <denkenz> E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:48:54 <denkenz> I:* If#= 5 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=09 Prot=01 Driver=cdc_wdm
Sep 29 20:48:58 <denkenz> E:  Ad=88(I) Atr=03(Int.) MxPS=  16 Ivl=16ms
Sep 29 20:49:00 <denkenz> I:* If#= 6 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0a Prot=00 Driver=cdc_ether
Sep 29 20:49:02 <denkenz> E:  Ad=86(I) Atr=03(Int.) MxPS=   8 Ivl=8ms
Sep 29 20:49:06 <denkenz> I:  If#= 7 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
Sep 29 20:49:08 <denkenz> I:* If#= 7 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
Sep 29 20:49:12 <denkenz> E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:49:14 <denkenz> E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:49:16 <denkenz> I:  If#= 7 Alt= 2 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ee Driver=cdc_ether
Sep 29 20:49:20 <denkenz> E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:49:22 <denkenz> E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:49:24 <denkenz> I:* If#= 8 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=09 Prot=01 Driver=cdc_wdm
Sep 29 20:49:26 <denkenz> E:  Ad=87(I) Atr=03(Int.) MxPS=  16 Ivl=16ms
Sep 29 20:49:28 <denkenz> I:* If#= 9 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
Sep 29 20:49:30 <denkenz> E:  Ad=84(I) Atr=03(Int.) MxPS=  16 Ivl=16ms
Sep 29 20:49:32 <denkenz> I:* If#=10 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
Sep 29 20:49:34 <denkenz> E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:49:36 <denkenz> E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:49:38 <denkenz> C:  #Ifs= 9 Cfg#= 2 Atr=e0 MxPwr= 20mA
Sep 29 20:49:40 <denkenz> I:  If#= 0 Alt= 0 #EPs= 0 Cls=02(comm.) Sub=08 Prot=00 Driver=
Sep 29 20:49:42 <denkenz> I:  If#= 1 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=
Sep 29 20:49:44 <denkenz> E:  Ad=8a(I) Atr=03(Int.) MxPS=  16 Ivl=16ms
Sep 29 20:49:46 <denkenz> I:  If#= 2 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=
Sep 29 20:49:48 <denkenz> E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:49:50 <denkenz> E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:49:52 <denkenz> I:  If#= 3 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=
Sep 29 20:49:54 <denkenz> E:  Ad=89(I) Atr=03(Int.) MxPS=  16 Ivl=16ms
Sep 29 20:49:56 <denkenz> I:  If#= 4 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=
Sep 29 20:49:58 <denkenz> E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:50:02 <denkenz> E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:50:08 <denkenz> I:  If#= 5 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=09 Prot=01 Driver=
Sep 29 20:50:10 <denkenz> E:  Ad=88(I) Atr=03(Int.) MxPS=  16 Ivl=16ms
Sep 29 20:50:12 <denkenz> I:  If#= 6 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0a Prot=00 Driver=
Sep 29 20:50:14 <denkenz> E:  Ad=86(I) Atr=03(Int.) MxPS=   8 Ivl=8ms
Sep 29 20:50:16 <denkenz> I:  If#= 7 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=
Sep 29 20:50:18 <denkenz> I:  If#= 7 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=
Sep 29 20:50:20 <denkenz> E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:50:22 <denkenz> E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:50:24 <denkenz> I:  If#= 7 Alt= 2 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ee Driver=
Sep 29 20:50:26 <denkenz> E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:50:28 <denkenz> E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Sep 29 20:50:30 <denkenz> I:  If#= 8 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=09 Prot=01 Driver=
Sep 29 20:50:32 <denkenz> E:  Ad=87(I) Atr=03(Int.) MxPS=  16 Ivl=16ms
Sep 29 20:50:34 <denkenz> I assume so :)
Sep 29 20:56:30 <denkenz> cdc_ether is showing up on interface 6 & 7, which seems consistent with lsusb output
Sep 29 20:56:47 <denkenz> But I've no idea how to interpret any of this, just thought it was interesting
Sep 29 20:59:16 <holtmann> Bus 002 Device 006: ID 0bdb:1900 Ericsson Business Mobile Networks BV 
Sep 29 20:59:16 <holtmann>   idVendor           0x0bdb Ericsson Business Mobile Networks BV
Sep 29 20:59:16 <holtmann>       iInterface             12 Ericsson F3507g Mobile Broadband Minicard Network Adapter
Sep 29 20:59:16 <holtmann>       iInterface             14 Ericsson F3507g Mobile Broadband Minicard Network Adapter
Sep 29 20:59:16 <holtmann>       iInterface             12 Ericsson F3507g Mobile Broadband Minicard Network Adapter
Sep 29 20:59:17 <holtmann>       iInterface             14 Ericsson F3507g Mobile Broadband Minicard Network Adapter
Sep 29 20:59:40 <holtmann> Could be that your card has more high-speed interfaces that need to be hooked up.
Sep 29 20:59:57 <holtmann> Wouldn't surprise me actually.
Sep 29 21:00:16 <denkenz> any idea what I can try?
Sep 29 21:04:49 <holtmann> Mail it to linux-usb@vger.kernel.org. They might know.
Sep 29 23:09:40 <tmzt> holtmann: have you looked at lsusb -v -v ?
Sep 29 23:09:45 <tmzt> that seems to be missing something
**** ENDING LOGGING AT Wed Sep 30 02:59:57 2009

**** BEGIN LOGGING AT Wed Sep 30 02:59:57 2009
Sep 30 03:34:30 <dilinger> hm.  so the g1 plugin started crashing at some point, and i suspect it has something to do w/ the fact that it's doing something different from every other plugin wrt chat handling
Sep 30 03:48:51 <denkenz> There was one patch submitted which fixed reference counting inside gatchat from_tty
Sep 30 04:05:57 <denkenz> applied and pushed
Sep 30 04:17:23 <dilinger> thanks
Sep 30 11:29:33 <inz> There was discussion earlier about the international dialing code of the current network; is there any advances on this?
Sep 30 11:29:46 <inz> (or is it "patches accepted" feature?)
Sep 30 15:35:57 <denkenz> inz: Right now we have much bigger fish to fry, besides we need a good database for that first
Sep 30 16:15:43 <inz> k
**** ENDING LOGGING AT Thu Oct 01 02:59:56 2009

**** BEGIN LOGGING AT Thu Oct 01 02:59:56 2009
Oct 01 05:04:45 <denkenz> God I love the freerunner, even with latest firmware I get three different behaviors with three different SIMs :)
Oct 01 15:54:01 <istaz> hi
Oct 01 15:59:14 <denkenz> istaz: hi
Oct 02 01:24:56 <holtmann>   CC     gatchat/gattty.o
Oct 02 01:24:57 <holtmann> cc1: warnings being treated as errors
Oct 02 01:24:57 <holtmann> gatchat/gattty.c: In function ‘g_at_tty_open’:
Oct 02 01:24:57 <holtmann> gatchat/gattty.c:231: error: implicit declaration of function ‘close’
Oct 02 01:26:36 <holtmann>  CC     plugins/calypso.o
Oct 02 01:26:37 <holtmann> cc1: warnings being treated as errors
Oct 02 01:26:37 <holtmann> plugins/calypso.c: In function ‘modem_initialize’:
Oct 02 01:26:37 <holtmann> plugins/calypso.c:182: error: unused variable ‘ti’
Oct 02 01:26:37 <holtmann> plugins/calypso.c:181: error: unused variable ‘sk’
Oct 02 01:27:28 <holtmann> denkenz: Your compiler is utterly broken :(
Oct 02 02:21:11 <denkenz> holtmann: Ah crap :(
**** ENDING LOGGING AT Fri Oct 02 02:59:56 2009

**** BEGIN LOGGING AT Fri Oct 02 02:59:56 2009
Oct 02 16:56:03 <holtmann> denkenz: Around?
Oct 02 16:56:10 <denkenz> holtmann: nod
Oct 02 16:56:30 <holtmann> kristen, denkenz: Lets talk about GAtChat and HDLC/PPP.
Oct 02 16:56:40 <denkenz> sure
Oct 02 16:57:03 <kristen> ok
Oct 02 16:57:08 <holtmann> kristen: So the dongle with the AT&T should be arriving at your place today or tomorrow.
Oct 02 16:57:18 <kristen> holtmann: got it.
Oct 02 16:57:42 <holtmann> Opening /dev/ttyUSB3 or /dev/ttyUSB4 gives you the AT command port where we also have to run PPP on it.
Oct 02 16:58:07 <holtmann> So you need RFC1661 and RFC1662.
Oct 02 16:58:17 <holtmann> One is PPP and the other is HDLC framing for PPP.
Oct 02 16:59:11 <kristen> holtmann: were you wanting to implement the entire ppp protocol, or just pieces of it?
Oct 02 16:59:47 <holtmann> So we need to extend GAtChat with a differentiation between command mode and online mode. Command mode meaning we can issue AT commands, online mode meaning we are connected and doing HDLC/PPP.
Oct 02 17:00:30 <holtmann> For PPP we only need pieces since half of it is not used within 3G anyway. For example PPP is only spoken between the host and the modem firmware. It is _NOT_ send over the air.
Oct 02 17:00:53 <kristen> holtmann: is there a list somewhere of the pieces you need?
Oct 02 17:01:33 <holtmann> It depends a little bit on the modem, but mainly we just need LCP part and then the actual IP data transmission.
Oct 02 17:01:52 <holtmann> Most likely we can ignore all of the weird options for compression etc.
Oct 02 17:02:00 <kristen> I suppose I can start with that and you can let me know what needs to be added later.
Oct 02 17:02:30 <holtmann> That is the plan. Don't implement anything we don't need.
Oct 02 17:02:43 <kristen> originally you told me you wanted the ppp functionality to be a separate library from GAtChat - that still true?
Oct 02 17:02:59 <holtmann> No. We want it directly in GAtChat.
Oct 02 17:03:00 <holtmann> denkenz: So how do you want the command mode/online mode switch.
Oct 02 17:03:25 <denkenz> That one is tricky since the parser must be switched out
Oct 02 17:03:46 <kristen> holtmann: ok.  will it need to have an external interface?  i.e. will anything besides the GAtChat library need to use it?
Oct 02 17:03:47 <holtmann> I already added set_syntax() ;)
Oct 02 17:03:50 <denkenz> But I imagine the app should control this, so once it receives a CONNECT it can say treat the rest as data
Oct 02 17:04:03 <denkenz> yeah, set_syntax is dangerous actually
Oct 02 17:04:25 <holtmann> So we can switch between permissive and v1 parser. For the MBM I can use v1 parser except for ATD ;)
Oct 02 17:04:28 <denkenz> Since you've no idea whether there's still more in the buffer :)
Oct 02 17:04:46 <denkenz> yeah, but the fact that this works is pure luck :)
Oct 02 17:05:00 <holtmann> I know that it is dangerous and we might need a flush command to flush the buffer.
Oct 02 17:05:25 <holtmann> It works, because I know that that that command got send. I switch it in the callback.
Oct 02 17:05:34 <holtmann> Also we can just make it fail if buffer is not empty.
Oct 02 17:05:40 <denkenz> really the app should just set data mode, at which point we treat everything afterwards as raw data
Oct 02 17:06:01 <holtmann> Works fine for me. I just wanted to play with permissive vs. v1 parser.
Oct 02 17:06:20 <denkenz> nod, they're pretty similar actually
Oct 02 17:06:39 <holtmann> kristen: So in theory when switching from command mode into online/data mode, then it should return a tun/tap device.
Oct 02 17:06:40 <denkenz> Just the weird first packet thing isn't handled, but that's just a dumb modem problem
Oct 02 17:07:30 <holtmann> And then everything can be handled internally. Only exception is the retrieval of the IP address, gateway and DNS settings.
Oct 02 17:08:01 <denkenz> We might want to install a simple binary handler into gatchat
Oct 02 17:08:08 <denkenz> No sense in assuming we'll always talk ppp
Oct 02 17:08:19 <holtmann> I know. It could also be RLP.
Oct 02 17:08:23 <holtmann> or something else.
Oct 02 17:09:14 <kristen> holtmann: so, packets come to library from ttyUSB3/4, get ppp stripped off, then sent onto tun device.  Then packets are received from tun device, ppp is stuck onto it by library, and then we write it out to ttyUSB3/4
Oct 02 17:10:35 <holtmann> In simple terms yes.
Oct 02 17:11:06 <holtmann> So you do setup with AT commands. And the ATD*99***1# magic command and after that you end up in data/online mode.
Oct 02 17:11:26 <holtmann> From there on you have HDLC framing. Inside you have PPP frames, and in these IP packets.
Oct 02 17:12:36 <kristen> I'm still looking at the ofono code to see how it works.  The user of the GATChat library is a driver, right?  so this driver will know whether it needs to strip/encode ppp stuff and will call the appropriate routines, or will we be trying to make this transparent to the driver, and have them only work at IP level?
Oct 02 17:13:49 <denkenz> the driver knows
Oct 02 17:14:18 <denkenz> The idea is that the driver will setup the gatchat according to the hardware
Oct 02 17:14:34 <denkenz> Potentially there might be some variation between the modems
Oct 02 17:15:31 <kristen> ok - so I need to expose ppp functionality to driver so they can decide how to use it.
Oct 02 17:15:50 <denkenz> Some devices won't even use gatchat for ppp, they come with kernel drivers, etc
Oct 02 17:16:00 <denkenz> yep
Oct 02 17:16:34 <kristen> what about setting up the tun device?  Is that something that is to be done inside the GAtChat library, or do we assume someone else has done it, and we just look for it?
Oct 02 17:17:33 <denkenz> If I were doing it I'd make a binary handler similar to how GAtSyntax is done
Oct 02 17:17:44 <denkenz> Then we can have one for ppp->tun/tap
Oct 02 17:17:52 <denkenz> And others for other protocols
Oct 02 17:17:57 <kristen> I'll take a look at that.
Oct 02 17:20:57 <holtmann> But yes, the TUN/TAP devices needs to be setup by GAtChat if we use one and do all the PPP frame processing.
Oct 02 17:21:03 <kristen> holtmann: is the modem you sent me then one that uses ppp/hdlc?  Is there a datasheet for it somewhere that would let me see the details on how it works?
Oct 02 17:21:49 <holtmann> No datasheet. Try Google. It does support HDLC/PPP. As I said. Use /dev/ttyUSB3.
Oct 02 17:22:09 <holtmann> You have to set the APN for AT&T. It is "isp.cingular".
Oct 02 17:23:08 <holtmann> AT+CGDCONT=1,"IP","isp.cingular" to be precise.
Oct 02 17:23:39 <holtmann> ATD*99***1# to actually establish the PDP context with that APN.
Oct 02 17:30:20 <denkenz> actually we won't be using ATD*99 in real drivers, but that works for now
Oct 02 17:31:03 <holtmann> I know, but that is fine. It makes no difference in the end.
Oct 02 17:34:45 <holtmann> kristen, denkenz: I have to leave now. Please figure something out or draft the API for data/online mode.
Oct 02 17:35:18 <kristen> holtmann: ok.
Oct 02 17:35:59 <kristen> denkenz: sounds like you are are suggesting that the driver decides whether to go into data/online mode.
Oct 02 17:36:23 <kristen> so we are talking about adding some api like set_online_mode() or something.
Oct 02 17:36:35 <kristen> that the driver would call when it was ready.
Oct 02 17:36:53 <denkenz> That is what I'm thinking.  Generally the online state is known when a 'CONNECT' final response is received
Oct 02 17:36:55 <kristen> this would give the driver access to the tun device for sending/receiving IP packets?
Oct 02 17:37:31 <denkenz> Well here's one scenario:
Oct 02 17:37:33 <kristen> then the driver would use whatever packet data it got and decide whether it needs to call any of the ppp stuff.
Oct 02 17:37:44 <denkenz> ATD*99....
Oct 02 17:37:48 <denkenz> CONNECT
Oct 02 17:37:59 <denkenz> the driver at this point creates tun/tap device, sets the binary handler
Oct 02 17:38:10 <denkenz> tells gatchat to enter online mode
Oct 02 17:38:34 <denkenz> All binary data is now sent to the binary handler, which in this particular case knows how to handle hdlc/ppp/tun
Oct 02 17:40:43 <kristen> shall I stub some stuff out and send to you via email so we can discuss in real detail?
Oct 02 17:41:04 <denkenz> sure, feel free to paste here or use pastebin too
Oct 02 17:41:16 <denkenz> we basically own this channel ;)
Oct 02 17:41:33 <kristen> it will take me a few days probably since I'm really unfamiliar with the code still.
Oct 02 17:41:52 <kristen> what timezone are you in?
Oct 02 17:42:22 <denkenz> CST
Oct 02 17:42:27 * kristen just wonders when to expect a living denkenz on the channel
Oct 02 17:43:06 <denkenz> Usually around 8-4 PST or so
Oct 02 17:44:06 <kristen> ok - let me take a crack at how I imagine this will work and get back to you.
Oct 02 17:44:22 <denkenz> sounds good
Oct 02 23:51:28 <denkenz> mbm uses udev now, not modemconf
Oct 02 23:54:09 <dilinger> oh?
Oct 02 23:54:28 <denkenz> yah, hasn't been using modemconf for about 3+ weeks I think
Oct 02 23:54:57 <dilinger> how is that supposed to work then?
Oct 02 23:55:29 <denkenz> udev sends us an event, and we look for the special string there
Oct 02 23:55:37 <denkenz> make sure you install udev.rules from ofono/plugins
Oct 02 23:55:39 <dilinger> what if udev's already sent an event?
Oct 02 23:55:41 <dilinger> ahh
Oct 02 23:55:49 <dilinger> that might be the missing part
Oct 02 23:55:54 <denkenz> or ofono.rules rather
Oct 02 23:57:52 <dilinger> also
Oct 02 23:57:57 <dilinger> http://git.collabora.co.uk/?p=user/sjoerd/ofono.git;a=commitdiff;h=e457a55999f0d52393e048ff68763fc3b2fd1f44
Oct 02 23:59:18 <denkenz> submit that one
Oct 03 00:03:15 <dilinger> denkenz: what happens if ofono is started after udev sends the event?
Oct 03 00:03:28 <denkenz> it still works
Oct 03 00:03:38 <denkenz> I think we enumerate udev on startup
Oct 03 00:03:54 <dilinger> ok.  doesn't seem to be working for him; hopefully he'll join the channel and i can stop playing telephone :)
Oct 03 00:04:05 <denkenz> works for me ;)
Oct 03 00:04:50 <denkenz> I've been plugging an mbm device in / out all week
Oct 03 00:06:36 <denkenz> That won't work, make a proper git format-patch submission
Oct 03 00:06:45 <denkenz> the commit message is all messed up
Oct 03 00:06:49 <dilinger> that is a git format-patch submission
Oct 03 00:06:58 <dilinger> oh, nm
Oct 03 00:06:59 <dilinger> i lied
Oct 03 00:11:48 <dilinger> ok, sent
Oct 03 00:14:41 <denkenz> sigh, I fix this myself :P
Oct 03 00:14:56 <denkenz> commit is still borked
Oct 03 00:16:16 <dilinger> maybe gmane is mangling it?
Oct 03 00:18:04 <dilinger> guess i'll send directly to the list next time
Oct 03 00:23:17 <denkenz> don't worry, I fixed it now
Oct 03 00:23:46 <dilinger> thanks
**** ENDING LOGGING AT Sat Oct 03 02:59:57 2009

**** BEGIN LOGGING AT Sat Oct 03 02:59:57 2009
Oct 03 17:26:17 <droid001> //my
**** ENDING LOGGING AT Sun Oct 04 02:59:56 2009

**** BEGIN LOGGING AT Sun Oct 04 02:59:56 2009
Oct 04 10:52:46 <holtmann>   CC     src/simutil.o
Oct 04 10:52:48 <holtmann> ../src/simutil.c: In function ‘sim_ef_db_lookup’:
Oct 04 10:52:50 <holtmann> ../src/simutil.c:571: warning: cast to pointer from integer of different size
Oct 04 11:34:17 <holtmann> Fixed and released ofono-0.7 now.
Oct 04 21:44:19 <istaz> is the format used by ofono for time always RFC2822 ?
Oct 04 21:45:25 <Robot101> hrm, why not use a 64-bit int for time?
Oct 04 21:47:52 <istaz> or a more parsing friendly format like ISO6801 at least
**** ENDING LOGGING AT Mon Oct 05 02:59:57 2009

**** BEGIN LOGGING AT Mon Oct 05 02:59:57 2009
Oct 05 05:54:13 <tmzt> holtmann: do you think gatchat would be usable as a standalone ppp stack?
Oct 05 05:55:18 <holtmann> tmzt: That is our plan.
Oct 05 05:55:38 <tmzt> ok
Oct 05 05:55:54 <holtmann> However a PPP stack where the target is 3G cards right now. So maybe only a limited subset of what PPP is capable of.
Oct 05 05:56:47 <holtmann> Once we have GAtPPP we still need to do performance tests. Maybe it won't work out at all. However just from the counting of context switches and data copying, I think MUX and PPP both in userspace is a big win.
Oct 05 05:57:38 <holtmann> However HDLC framing for PPP is our biggest problem. There is no efficient way in doing it without looking at every byte. The kernel has essentially the same problem.
Oct 05 05:58:56 <tmzt> you intend to use tun/tap for the network interface?
Oct 05 05:59:35 <holtmann> Yes.
Oct 05 05:59:58 <holtmann> We have no other choice since we need an IP address and routing for it :)
Oct 05 06:01:45 <holtmann> The only other solution is to have the MUX support inside the kernel. Right we don't have an upstream muxer and extending it with all the crazy transports like SPI and USB might be even more complex than what we are trying right now.
Oct 05 06:02:41 <holtmann> It is a learning exercise and the GAtMuxChannel wrapping seems to have potential.
Oct 05 06:03:18 <holtmann> And in theory we can hide a kernel muxer behind GAtMux if we really want to.
Oct 05 06:03:43 <holtmann> Same applies for PPP btw.
Oct 05 06:04:25 <tmzt> this seems it could help on bluetooth as well, eliminating the ldisc on rfcomms?
Oct 05 06:04:56 <holtmann> It could.
Oct 05 06:05:21 <holtmann> We will see. There is still a lot of work to do here.
Oct 05 06:06:26 <tmzt> since it's a network based stack I mean, you would have GAt* on a rfcomm socket rather than tty?
Oct 05 06:10:02 <holtmann> Yes. That would help. However we could also make the kernel PPP aware of RFCOMM. Something like rfcomm-ppp.
Oct 05 06:10:22 <holtmann> Same as we do for the TTYs. Except nobody has bothered writing that code.
Oct 05 06:12:38 <tmzt> I see the architecture overview, are the dbus apis not finalized or are they just not on the site?
Oct 05 06:26:20 <tmzt> how much of gatchat will be pluggable?
Oct 05 06:32:29 <holtmann> GAtChat will be pluggable as much as we need it and as much as it makes sense. So we will see.
Oct 05 06:32:54 <holtmann> D-Bus API are not final until 1.0, but we don't expect massive changes.
Oct 05 08:22:22 <tmzt> this might be relevant to the earlier discussion: http://audidude.com/blog/?p=342 
Oct 05 11:25:49 <istaz> tmzt: yes but why stuck with deprecated rfc2822?
Oct 05 11:32:49 <tmzt> sorry? I wasn't the one arguing that
Oct 05 11:33:04 <tmzt> this might be a solution since it fits the glib design
Oct 05 11:33:34 <tmzt> it should be able to parse and be converted to all those formats
Oct 05 11:33:44 <tmzt> internally it's 64bit seconds from the unix epoch I think
Oct 05 11:36:25 <istaz> tmzt: well it may be indeed a solution from the client pov but I was wondering why not send the timestamp directly instead of encoding it in the deamon and then having the client parse it
Oct 05 11:37:28 <tmzt> I guess since the properties api seems to be json-like, or compatible with other scripting languages
Oct 05 11:56:58 <istaz> and they don't support numeric timestamp?
Oct 05 12:20:39 <tmzt> I mean they might not have a way to identify that a number in a nested array or map or whatever was a timestamp
Oct 05 14:48:00 <denkenz> istaz, tmzt: I welcome suggestions on the timestamp, oFono is a string-based D-Bus API, so using a long int is not preferable
Oct 05 14:49:38 <denkenz> holtmann: My compiler isn't reporting that on 64 bit, strange
Oct 05 14:52:15 <istaz> denkenz: well then using a format like iso8601 (2009-10-05T12:11Z) may be easier to parser and better supported by lib like glib
Oct 05 14:53:13 <denkenz> The reason RFC 822 was chosen is that it can be pretty-printed directly
Oct 05 14:54:38 <denkenz> Besides, you should be able to use strptime to convert back
Oct 05 14:55:01 <denkenz> Again, if this is too painful in GLib, send an RFC patch and lets get feedback on the ML
Oct 05 14:56:02 <istaz> denkenz: if you are on a english local maybe but other locale would have to translate it anyway and it maybe a bit long to display on mobile screen device anyway
Oct 05 14:56:49 <istaz> and for stuff like timeStart you would want to display the duration of the call anyway
Oct 05 14:57:01 <istaz> ok will do that
Oct 05 14:57:19 <denkenz> Sure, but if you're doing a proper UI, parsing RFC 822 is the least of your worries
Oct 05 15:01:32 <lindi-> denkenz: unless you want more precision than seconds
Oct 05 15:02:08 <denkenz> valid point, can you think of a use case?
Oct 05 15:03:18 <lindi-> denkenz: not right now, i'm just frustrated that gnuplot can't handle more precision because of this architectural limitation :)
Oct 05 15:04:05 <denkenz> heh, note that you get access to raw data in the call history plugin already
Oct 05 15:04:26 <denkenz> So if you _truly_ need full precision, you have it
Oct 05 15:08:56 <daf> denkenz: D-Bus has types other than string for a reason :P
Oct 05 15:09:32 <daf> it's not like any D-Bus bindings are restricted to only using strings
Oct 05 15:10:39 <denkenz> daf: Sure, and we use them when it makes sense, but using an int64 for time is not enough last I checked
Oct 05 15:10:58 <daf> oh, how so?
Oct 05 15:11:16 <denkenz> Time zone becomes a bit ambiguous
Oct 05 15:11:32 <denkenz> Remember, oFono doesn't only report local time
Oct 05 15:12:09 <daf> why can't it just use UTC?
Oct 05 15:12:16 <daf> and report the offset when it needs to
Oct 05 15:12:43 <denkenz> At that point why not just use a proper string format?
Oct 05 15:12:51 <daf> "proper"
Oct 05 15:12:56 <daf> strings are not structured data
Oct 05 15:13:26 <denkenz> Neither is an int64, and we're not going down the path of D-Bus structures
Oct 05 15:14:17 <daf> ...
Oct 05 15:14:30 <daf> D-Bus has data structures to make your life easier
Oct 05 15:14:34 <daf> denkenz: http://jcalderone.livejournal.com/47071.html
Oct 05 15:16:37 <denkenz> Nah, I've been down that hell before, using data-structures in D-Bus becomes royal pain
Oct 05 15:16:59 <daf> only if your D-Bus library sucks
Oct 05 15:17:02 <denkenz> They just look 'nice' on paper, once you use them as a client, you curse the designers
Oct 05 15:17:23 <denkenz> Trust me, I wrote a few D-Bus libraries in my time, structures suck ;)
Oct 05 15:18:12 <denkenz> Otherwise you get into telepathy-glib, telepathy-qt hell, not again :)
Oct 05 15:18:46 <daf> I don't see the problem
Oct 05 15:24:55 <daf> denkenz: if you have to use a string, I would advocate using ISO 8601
Oct 05 15:27:06 <denkenz> See my earlier comment, post an RFC patch to the ML and lets go from there.
Oct 05 15:35:03 <dilinger> how goes the phonesim release?
Oct 05 15:53:21 <holtmann> denkenz: That was on 32-bit ;)
Oct 05 15:54:37 <holtmann> dilinger: I am stuck and the Bluetooth UnPlugFest. So the release of the source code will be delayed a little bit.
Oct 05 15:56:29 <denkenz> holtmann: It shouldn't matter, the size is different
Oct 05 15:57:42 <holtmann> GUINT_TO_POINTER is some pointer magic. So that use case is actually a problem. I would prefer if we didn't do it that way.
Oct 05 15:57:51 <holtmann> However I see that bsearch is kinda limited in what options we have.
Oct 05 15:58:11 <denkenz> Yeah, frankly bsearch might be too big of a hammer for that one
Oct 05 15:58:18 <denkenz> I'm too lazy to run benchmarks though
Oct 05 15:59:19 <denkenz> btw, are there known F3507/3607 USB dongles.  I want Andrew to get one
Oct 05 16:01:02 <holtmann> I was hoping there are, but seems they are not. Only mini-PCI with adapter card.
Oct 05 16:08:15 <denkenz> Is novatel or option cards as nice to use?
Oct 05 16:10:07 <holtmann> Option HSO, yes, Novatel is PPP.
Oct 05 16:12:31 <holtmann> Plain old Option (non HSO) are also PPP.
Oct 05 16:15:54 <denkenz> What about Sony MD300?
Oct 05 16:25:37 <holtmann> No idea. What is that. Link please.
Oct 05 16:27:12 <dilinger> holtmann: d'oh, okay
Oct 05 16:28:18 <denkenz> http://www.amazon.com/dp/B001AUHD3Q/ref=asc_df_B001AUHD3Q928415?smid=ATVPDKIKX0DER&tag=googlecom09c9-20&linkCode=asn&creative=380341&creativeASIN=B001AUHD3Q
Oct 05 16:28:59 <denkenz> http://www.amazon.co.uk/Sony-Ericsson-MD-300-USB-Modem/dp/B001W7VZEK/ref=sr_1_1?ie=UTF8&s=electronics&qid=1254760120&sr=8-1
Oct 05 16:29:46 <denkenz> According to dcbw's log it should be the F3507
Oct 05 16:31:43 <holtmann> Then I have to buy one of these.
Oct 05 16:36:58 <holtmann> denkenz: Ordered myself one from the UK now.
Oct 05 16:37:26 <denkenz> Nod, tell me whether it is indeed the F3507
Oct 05 16:38:21 <holtmann> I will, but earliest 18th of Oct. Will not be home before then.
Oct 05 18:51:08 <dilinger> sigh
Oct 05 18:51:18 <dilinger> ofonod[947]: plugins/g1.c:g1_debug() > AT+CGSN\r
Oct 05 18:51:18 <dilinger> ofonod[947]: src/voicecall.c:ecc_read_cb() 0
Oct 05 18:51:18 <dilinger> Segmentation fault
Oct 05 18:54:17 <denkenz> uh oh
Oct 05 18:54:40 <denkenz> stacktrace please
Oct 05 19:43:18 <dilinger> i'm utterly failing at that.  i don't know why this is working on i386 but not arm, but something's very screwy here
Oct 05 19:45:16 <denkenz> question is, is it failing in ecc_read_cb or elsewhere
Oct 05 19:45:53 <denkenz> there's very little that can go wrong in that one :)
Oct 05 21:06:24 <dilinger> denkenz: http://paste.debian.net/48219/
Oct 05 21:17:21 <denkenz> rm -rf /var/lib/ofono/*
Oct 05 21:17:27 <denkenz> Tell me if that still happens
Oct 05 21:18:53 <dilinger> it no longer crashes
Oct 05 21:19:36 <denkenz> Ok, as I suspected, but why was it crashing there
Oct 05 21:20:22 <denkenz> Ah idiot
Oct 05 21:21:48 <denkenz> Fixed
Oct 05 21:23:18 <denkenz> And this is why I hate GSM spec
Oct 05 21:23:36 <denkenz> Between 2G & 3G they changed the structure of the EFecc
Oct 05 21:25:50 <denkenz> Anyway, thanks for that one
Oct 05 21:26:07 <dilinger> np
Oct 05 21:48:22 <istaz> is the ml moderated? I don't see the mail I sent a few hours ago
Oct 05 21:54:00 <denkenz> it isn't, but people using git-send-email have had issues
Oct 05 21:54:23 <denkenz> not moderated for subscribers anyway
Oct 05 21:55:31 <istaz> ok maybe it's just a bit slow (or an error from my server)
Oct 05 23:10:59 <dilinger> hm
Oct 05 23:11:13 <dilinger> denkenz: you have a device that uses the mbm driver, right?
Oct 05 23:12:42 <dilinger> sjoerd's mbm device never signals PropertyChanged for SubscriberNumber.  however, i have AT debug logs here that clearly show a CRSM response w/ his phone number encoded in it
Oct 05 23:12:54 <dilinger> however, the string has quotes around it
Oct 05 23:13:01 <dilinger> i'm wondering if that's screwing up the parsing
Oct 05 23:13:33 <dilinger> ofonod[4904]: < \r\n+CRSM: 144,0,"4C494E452031FFFFFFFFFFFFFFFFFFFF0791445760050000FFFFFFFFFFFF"\r\n\r\nOK\r\n
Oct 05 23:15:40 <dilinger> for a number like 7506500000
Oct 05 23:16:05 <dilinger> or is there something else that might be causing it to not report the number?
Oct 05 23:22:28 <dilinger> hm, no, g_at_result_iter_next_hexstring appears to skip over quoted hex strings..
Oct 05 23:24:51 <denkenz> I fixed that
Oct 05 23:25:49 <denkenz> Are you running the latest pull, since this seems to work with my 3G SIMs on mbm
Oct 05 23:26:09 <dilinger> this was on 0.7
Oct 05 23:26:44 <dilinger> so no, latest commit (60118757b25) is not included
Oct 05 23:27:10 <denkenz> It should be this one: 7e82686e70157b16878e97b0c3c1174c3e2b96c8
Oct 05 23:27:36 <dilinger> that's in 0.7, so yes
Oct 05 23:29:48 <dilinger> well, when he's back online i can have him try again w/ some additional debugging info so i can see how far it's getting when parsing that
Oct 05 23:30:02 <denkenz> Can you put a break point at at_crsm_read_cb and tell me whether it really fails to get anything out of next_hexstring?
Oct 05 23:31:02 <dilinger> i think he's gone to sleep, unfortunately.  i'll find out in the morning
Oct 05 23:36:11 <denkenz> Btw, just tested head on mbm, I get subscriber numbers, voicemail numbers, etc just fine
Oct 05 23:36:56 <denkenz> format is the same, e.g. ofonod[7544]: Response line: +CRSM: 144,0,"130014FA00FDE702"
Oct 05 23:37:16 <dilinger> *nod*
**** ENDING LOGGING AT Tue Oct 06 02:59:58 2009