**** BEGIN LOGGING AT Fri Mar 19 02:59:56 2010 Mar 19 05:16:42 denkenz, holtmann I find that at MBM 5540 the operator gotten from oFono is 0 so the network name of ConnMan is 0, as a result, the 3G service name can not be displayed at Carrick. Mar 19 05:17:40 holtmann, denkenz, Can I set a default name if I can not get proper operator name? Or let UI to handle the issue? Mar 19 05:19:19 Why don't you get an operator name. That should not happen. Unless this is old card and a brand new network. Mar 19 05:19:48 In case the name is not available, we should be automatically falling back to MMC:MNC display. However that should be done by oFono. And not inside ConnMan. Mar 19 06:19:33 holtmann, I can get operator name from 5530 and HSO card. But 5540 card is wired and return "\0" to me. So what your mean is that should be fixed at oFono side and ConnMan need not handle it? Mar 19 06:21:22 holtmann, denkenz, but today my HSO card can not work properly. it can not attached or sometimes timeout on power on. I will send the AT connmand log to you. Mar 19 10:08:27 asd Mar 19 10:08:50 sorry bout that Mar 19 13:39:29 Hi, does anyone have a more detailed list of message id & subblock ids to communicate with ISI modems than what's currently in ofono? Mar 19 13:40:05 i found a few more reversing n900's csd plugins... but i was wondering if anybody had a complete list Mar 19 14:35:31 martin_lab: It sounds like the modem doesn't have enough time to register, nothing fishy in the log Mar 19 14:52:41 tchouky: just out of curiosity: what are you doing? :) Mar 19 14:53:21 hi, id like to code my own field test mode Mar 19 14:53:28 to detect rogue bts Mar 19 14:53:56 *currently digging in symbian's code to find out phonet's api * Mar 19 14:53:58 :) Mar 19 14:54:10 not a lot of information available out there Mar 19 14:56:55 aah i think i read of you before here :) Mar 19 14:57:17 yeah i came here a few days ago Mar 19 14:57:42 ofono's a great help Mar 19 14:57:56 cause i get working code to communicate directly with the modem Mar 19 14:58:11 at first i was afraid id have to inject my code into the csd process ;) Mar 19 14:58:32 hi denkenz Mar 19 14:58:47 thank you for your answer but I have some doubts Mar 19 14:59:10 how can I use the history plugin? Mar 19 14:59:55 i don't find any document in the source repository (or maybe I'm not searching well ;) ) Mar 19 15:00:16 is there any DBus interface to access history data? Mar 19 15:01:22 Djdas: History is kept abstract for a reason, so you can integrate it with EDS/MySQL/Postgres/Kontact/whatever Mar 19 15:02:08 The documentation is lacking, but the interface is pretty simple, just look at include/history.h Mar 19 15:02:37 yes denkenz, this is clear, but I don't understand HOW I am able to integrate with my app Mar 19 15:02:43 uhm ok please let me read the file Mar 19 15:05:13 so IIUC I have to include history.h and the provide the callbacks to the members of the ofono_history_driver struct which I can use in my app? Mar 19 15:05:30 s/the provide/then provide/ Mar 19 15:06:47 The idea is that you create a history driver where you open up a database of your choice Mar 19 15:06:57 Whenever an event happens you store it directly there Mar 19 15:07:10 great, this answer the first question Mar 19 15:07:18 And depending on how your DB is setup, generate an event to an external application Mar 19 15:08:34 what I'm missing is: the plugin will be part of ofonod not of my app, is it correct? Mar 19 15:09:19 so I solve the second question because I'll always sure the history will be notified of incoming messages and it will store data somewhere Mar 19 15:09:42 then I could provide a dbus interface to it so it can retrieve informations for my app Mar 19 15:11:24 Correct, plugin is part of oFono Mar 19 15:11:31 So it always gets the info Mar 19 15:12:12 Your app can simply re-read the database at startup and keep an internal cache afterwards Mar 19 15:12:19 ok, I'm interested in writing a plugin which will support sqlite to store informations, do you think this could be useful for you? Mar 19 15:12:56 If so cna you please point me at coding guides you prefer to achieve this? Mar 19 15:13:04 s/cna/can/ Mar 19 15:13:14 Sure, I think many people would be, and I have no issues pushing it upstream if it works out well Mar 19 15:13:34 For coding style: kernel coding style, but also follow existing oFono code Mar 19 15:13:51 It is pretty consistent Mar 19 15:13:59 great (indent with style linux?) Mar 19 15:14:10 Yes, tabs not spaces, etc Mar 19 15:14:13 ok Mar 19 15:14:51 another one question: am I free to desing the db or do you have some structure/desing to follow? Mar 19 15:15:14 I stay out of that one :) Mar 19 15:15:21 eheh ok Mar 19 15:15:30 However, you can always solicit feedback here on the list Mar 19 15:15:37 There are people who are doing similar things Mar 19 15:15:43 so I'll try to put down something and then post on the list beofre writing code Mar 19 15:16:26 I'll design a sample db to store sms info and put the schema on the list Mar 19 15:17:14 of course there will be a libsqlite dependency, this could be a problem for you? Mar 19 15:34:32 Djdas: We have to see, probably not a big deal as it is a plugin Mar 19 15:34:42 Djdas: People can always --disable it Mar 19 15:34:59 OK, just sent an email to the list, thank you very much Mar 19 15:44:39 i was getting a make error with current phonesim, something like "QT_V_MOC references itself (eventually)" and the same error for QT_V_UIC Mar 19 17:39:02 balrog-k1n: Strange, I had no issues lately Mar 19 17:39:13 balrog-k1n: Try make distclean & remake Mar 19 20:40:45 denkenz: the network status module that just has been merged into e17: http://jprvita.wordpress.com/2010/03/19/ofono-e17-module/ Mar 19 21:03:35 jprvita: Nice, looks good :) Mar 19 21:05:42 I may add some notification when new sms arrives and integrate with a dialog to send messages Mar 19 21:06:17 but in the future Mar 20 01:19:47 denkenz: Please don't add these default: break; statement to internals enums. They are not needed. If we extend the enum and forget this line, the compiler will warn us. Mar 20 01:20:41 And I want the compiler to warn us that we forgot to look at this code. All these default: statements make the code just compile. Not necessary work correctly. Mar 20 01:21:50 The only time when these default: statements are needed is when the data comes from a wire protocol. Because that can change without us knowing. Internally, we have control all the way. Mar 20 01:23:26 CC src/common.o Mar 20 01:23:26 cc1: warnings being treated as errors Mar 20 01:23:26 src/common.c: In function ‘is_valid_pin’: Mar 20 01:23:26 src/common.c:595: error: enumeration value ‘PIN_TYPE_X’ not handled in switch Mar 20 01:23:26 make[1]: *** [src/common.o] Error 1 Mar 20 01:23:39 This would be the example here. And I want the compiler to tell us exactly this. Mar 20 01:25:49 denkenz: Also why are we assigning numbers to pin_type enum. This is purely internal. So who cares. Mar 20 01:26:09 denkenz: And another nitpick here. The { for the switch(...) is on the same line. Not the next one ;) Mar 20 02:10:23 holtmann: Sorry the switch { part I totally missed Mar 20 02:10:50 holtmann: The default you have a point, but the case there is to simply fail, so if someone tests it it will still break Mar 20 02:11:22 Yeah, but it is internal only. And I want them to fall flat on their face if they do something stupid. **** ENDING LOGGING AT Sat Mar 20 02:59:58 2010