replacement for wl1251-cal
I have written a clone of the Nokia wl1251-cal package (used for setting regulatory domain, NVS and MAC address for N900 wl1251 WiFi chip) Source is available here: http://www.cncmods.net/files/wl1251-cal_1.0-1.tar.gz To compile you need libcal-dev and libnl-dev installed. No .deb file posted because its not intended for people to install this, its intended for this code to go into CSSU and other things. Like my bt-cal work, its intended that this be used for CSSU and also for Meego/Mer/Nemo/etc. Its also been written so that someone can modify this in some way so that it only uses standard kernel things, thus allowing the removal of the non-standard Nokia netlink interfaces. Note that on MeeGo/Mer/Nemo/etc if you use this and my bluetooth-cal stuff, you can eliminate the libppu-bin, libwl1251-bin, sysinfod-rx51 and wl1251-cal-bin packages. On Maemo, you can eliminate bluetooth-sysinfo, wl1251-cal and libppu if you are updating mp-blah-pr appropriately. Removing libwl1251 will force a removal of testserver, whatever that is (no clue if testserver is important or not) Differences from the Nokia tool: 1.It does not use sysinfo, it reads everything directly from cal via libcal. 2.WiFi regulatory domain (FCC vs not FCC) is read from CAL (same place in CAL as sysinfo-tool -g /certs/ccc/pp/wlan-channel would get it from) rather than being determined based on the current mobile network country code. (if you wanted to make it use current MCC it would be easy enough to support on Maemo5 at least, dont know about ofono) 3.It doesn't print the same output to stdout when its run as wl1251-cal from Nokia (as of now it only prints what it thinks the regulatory domain is) 4.It probably doesn't have the same error handling as the Nokia tool 5.The order that it does the 3 steps (set MAC address, send NVS, set regulatory domain) is different to the Nokia tool (easily fixed if necessary and I doubt it matters in any case) 6.My tool may leak resources (e.g. not closing handles properly) where the Nokia tool does not (or in some cases the Nokia tool may leak resources that my tool does not) It appears to be working (in that I see the right IOCTL being triggered, the right MAC address appearing and the right data being sent over netlink for regulatory domain and for NVS) but I cant be sure that there are no problems with it resulting from the differences between my tool and Nokias. This will NOT work for any device other than the N900 nor do I have any plans to do anything for any device other than the N900. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
replacement for bluetooth-sysinfo (and plans for libcal and wl1251-cal)
I have written a package I call bt-cal which is a replacement for bluetooth-sysinfo as a way to read the bluetooth MAC address from CAL and send it to the bluetooth driver. Source is available here: http://www.cncmods.net/files/bt-cal_1.0-1.tar.gz To compile you need libcal-dev installed. No .deb file posted because its not intended for people to install this, its intended for this to be used for CSSU. The ultimate aim is that someone will modify this and make it talk to something more standard than the /sys/devices/platform/hci_h4p/hwaddr that it talks to now (allowing the non-standard interface to be removed from kernel-power/kernel-cssu/whatever) The next thing I will work on is a clone of wl1251-cal to grab the MAC address and NVS from the CAL and send it to the WiFi chip. (with the aim being to allow the elimination of the non-standard netlink stuff) I will also work on a clone of libcal to allow replacement of that component too. This work is also of value for Meego/Mer/Nemo/etc as a way of eliminating the dependance on the proprietary libcal, wl1251-cal and sysinfo package (sysinfo packages on Meego/Mer/Nemo contain the bluetooth MAC address script) None of this work is aimed at the N9 or N950 as I do not own either device. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
N900 dbus interfaces
I have created a Wiki post to document the known Nokia-specific dbus interfaces used on the N900. http://wiki.maemo.org/N900_dbus Let me know if you have any feedback on the page or if you have anything to add to it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: information required to replace Maemo5 wlan bits
Timur Kristóf wrote: I'm not sure what would be the point of replacing the proprietary WLAN bits. 1.Ability to support WiFi security mechanisms that the stock bits dont support 2.Support for assigning higher priorities to different wireless networks (i.e. if you move into range of a higher-priority network than the one you are on, it will join to that) Probably other things too. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Any interest in replacing ICD?
I am in the process of figuring out all the dbus interfaces, gconf keys etc that one would need to support in order to replace ICD with something else (e.g. whatever MeeGo/Nemo/Mer/etc uses) and still have other parts of the system keep working but I want to know if there is actually any interest in this work (and in an ICD replacement) or whether I should abandon it and give up. No point in me working on this if no-one else cares (e.g. someone who can help write code or who knows how the replacement thingo that we would be using works)... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
information required to replace Maemo5 wlan bits
Here is the information on the things you need to know about/provide/use/etc in order to replace the Maemo5 ICD WLAN plugin with something better (e.g. based on wpa-supplicant) and have every other package on the stock install continue to work properly. You will need to replace the following packages (and update the ICD2 configs accordingly) osso-wlan osso-wlan-security libicd-network-wlan libicd-network-wps libicd-network-eap and possibly icd2-network-wlan-config You may need to send the following dbus messages com.nokia.icd_ui.show_private_key_passwd_dlg com.nokia.icd_ui.show_gtc_dlg com.nokia.icd_ui.show_server_cert_dlg com.nokia.icd_ui.show_mschap_change_dlg com.nokia.icd_ui.show_passwd_dlg You may need to add handlers for the following dbus signals: com.nokia.icd_ui.passwd com.nokia.icd_ui.mschap_change com.nokia.icd_ui.gtc_response com.nokia.icd_ui.private_key_passwd com.nokia.icd_ui.server_cert com.nokia.wps_ui.method_sig You will need to respond to the following dbus messages: com.nokia.wlancond.request You will need to signal on the following dbus signals: com.nokia.wlancond.signal.scan_results com.nokia.eap.signal.wps_success You may need to read files from /usr/share/sub-ca-certificates You may need to use maemosec libraries and other things to read certificates And you will probably need to read or write the following gconf keys (In particular note that type and wlan_security need to be set to match stock Maemo. Some keys will need to be read, some will need to be written to, some will need to be both read and written to. This list is all the relevant gconf keys referenced by both the packages being replaced and by other packages on the system. The %s is replaced with the IAP name, whatever that might be.) /system/osso/connectivity/IAP/wlan_tx_power /system/osso/connectivity/IAP/%s/type /system/osso/connectivity/IAP/%s/wlan_security /system/osso/connectivity/IAP/%s/wlan_ssid /system/osso/connectivity/IAP/%s/wlan_wepdefkey /system/osso/connectivity/IAP/%s/wlan_wepkey1 /system/osso/connectivity/IAP/%s/wlan_wepkey2 /system/osso/connectivity/IAP/%s/wlan_wepkey3 /system/osso/connectivity/IAP/%s/wlan_wepkey4 /system/osso/connectivity/IAP/%s/nai /system/osso/connectivity/IAP/%s/temporary /system/osso/connectivity/IAP/%s/wlan_hidden /system/osso/connectivity/IAP/%s/EAP_wpa2_only_mode /system/osso/connectivity/IAP/%s/powersave_after_scan /system/osso/connectivity/IAP/%s/wlan_powersave /system/osso/connectivity/IAP/%s/wlan_adhoc_channel /system/osso/connectivity/IAP/%s/EAP_TLS_PEAP_client_certificate_file /system/osso/connectivity/IAP/%s/EAP_default_type /system/osso/connectivity/IAP/%s/EAP_wpa_preshared_passphrase /system/osso/connectivity/IAP/%s/PEAP_tunneled_eap_type /system/osso/connectivity/IAP/%s/EAP_MSCHAPV2_username /system/osso/connectivity/IAP/%s/EAP_MSCHAPV2_password /system/osso/connectivity/IAP/%s/EAP_GTC_identity /system/osso/connectivity/IAP/%s/EAP_wpa_preshared_key /system/osso/connectivity/IAP/%s/EAP_SIMPLE_CONFIG_device_password /system/osso/connectivity/IAP/%s/EAP_MSCHAPV2_password_prompt /system/osso/connectivity/IAP/%s/EAP_manual_username /system/osso/connectivity/IAP/%s/EAP_use_manual_username /system/osso/connectivity/IAP/%s/TLS_server_authenticates_client_policy_in_client Combining this information with e.g. libicd-network-wpa could allow a proper open-source drop-in replacement for the WiFi infrastructure on Maemo5 Fremantle (for e.g. CSSU) that will automatically pick up all your existing WiFi networks. No I dont have time to actually write any code for this. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
How to embed microb browser view/daemon in your app
Thanks to a nice person at Nokia who published Fremantle sources for tablet-browser-daemon and browser-neteal, we now have the 100% correct browser-neteal-dev package required to embed the browser view in your app just like Nokia did with microb, tutorial-home-applet and other things. This is what you need to know in order to embed the microb browser view widget (which in turn talks to the browser daemon just like microb does) in your app: 1.Download http://www.cncmods.net/files/browser-neteal-dev_0.7.10.1-2_armel.deb http://www.cncmods.net/files/tablet-browser-view-test.c and http://www.cncmods.net/files/tablet-browser-view-test.sh into scratchbox. 2.Install tablet-browser-view-dev from the SDK. 3.Install browser-neteal-dev from the above deb file. 4.Run tablet-browser-view-test.sh to make sure things compile and that you have all the dependencies in place 5.Study tablet-browser-view-test.c to see how to embed tablet-browser-view into your app. 6.Enjoy a nice simple way of embedding the Maemo browser widget/view/engine into your app and talking to the Maemo browser daemon. Why would you want to use this instead of other methods of adding a browser in your app? 1.Its simple to use (compared to pulling in a full browser engine like webkit or gecko and talking to it) 2.You get all the advantages of the Maemo browser daemon without the need to talk to it over dbus and do other complex things. 3.It handles some of the tricky stuff like scrolling and zooming automatically so you dont have to. Basically its a nice way to use the existing Maemo browser view/microb engine without the need to do lots of tricky stuff on your end. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New tool available to decrypt encryped N900 backups without a N900
Jonathan Wilson wrote: Thanks to Pali finding some old osso-backup source in http://repository.maemo.org/pool/maemo3.2/free/source/, I was able to build a tool that decrypts encrypted osso-backup files without the need to have a working N900 Fremantle install. The download is at http://www.cncmods.net/files/backupdec.zip and is compiled via backupdec.sh. It will compile in scratchbox if you have libosso-gsf-1-dev, libglib-2.0-dev and libssl-dev installed or it should compile in a normal linux environment if you have normal libgsf, glib and openssl headers installed (you will need to edit the sh file pkg-config options for this) To run the compiled binary, run backupdec in out password where in is the encrypted zip file from the backup, out is the name of the output unencrypted zip file and password is the password used when the zip file was created. It can also be used to decrypt zip files on the N900 itself if you want to decrypt the files without actually restoring the backup. (i.e. build an arm binary of this and run it on the phone) If someone has a specific need for a binary of this built for a specific platform, let me know and I will see what I can do to get a binary. The source code here is released under the GPL if you want to re-use it. Also, this only works if you know the actual password as the encryption is too strong to brute force it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
New tool available to decrypt encryped N900 backups without a N900
Thanks to Pali finding some old osso-backup source in http://repository.maemo.org/pool/maemo3.2/free/source/, I was able to build a tool that decrypts encrypted osso-backup files without the need to have a working N900 Fremantle install. The download is at http://www.cncmods.net/files/backupdec.zip and is compiled via backupdec.sh. It will compile in scratchbox if you have libosso-gsf-1-dev, libglib-2.0-dev and libssl-dev installed or it should compile in a normal linux environment if you have normal libgsf, glib and openssl headers installed (you will need to edit the sh file pkg-config options for this) To run the compiled binary, run backupdec in out password where in is the encrypted zip file from the backup, out is the name of the output unencrypted zip file and password is the password used when the zip file was created. It can also be used to decrypt zip files on the N900 itself if you want to decrypt the files without actually restoring the backup. (i.e. build an arm binary of this and run it on the phone) If someone has a specific need for a binary of this built for a specific platform, let me know and I will see what I can do to get a binary. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Resources for learning Qt on Mameo5 Fremantle
> That book is fine, but is focused on desktop. There are a couple of > books out there focused on Qt and mobile apps. "Beginning Nokia Apps > Development" is about Qt on Symbian and MeeGo and can be had for under > $10 USD. Thanks, I will see if I can track down that book (ordering it from Amazon is an option but the shipping to Australia is a killer :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Resources for learning Qt on Mameo5 Fremantle
I am looking for resources related to learning Qt on Maemo5 Fremantle. More specifically I am trying to understand the workings of this app: (and add some new features to it such as a one-step undo for when you press the wrong block by mistake) http://maemo.org/packages/view/skidstone/ I have a copy of a book titled "C++ GUI Programming with Qt 4 Second Edition", will the information in that book be of any use in understanding whatever version of QT Maemo5 has? Where can I find tutorials and things dealing with mobile-specific stuff like touch events? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Looking for someone to do a review of operator-name-cbs-widget-0.1 to make it something that can go into the repos/CSSU
I am looking for someone who can look at my operator-name-cbs-widget-0.1 and the libconnui-dev-0.1 package that its using and can check it over (the code and especially the debian packaging configuration files) so it can be brought up to the standards required for it to be added to the repositories and to the CSSU. Relavent files: http://www.cncmods.net/files/libconnui-dev-0.1.zip http://www.cncmods.net/files/libconnui-dev_0.1_armel.deb http://www.cncmods.net/files/operator-name-cbs-widget-0.1.zip http://www.cncmods.net/files/operator-name-cbs-widget_0.1_armel.deb I have no idea what the requirements to get this into the repositories or into the CSSU are so I am hoping someone else can help me work through this and get it to the point where it can be added :) (and maybe one of these days I will find out what to do with incoming cell broadcast SMS messages on channels other than 50, like all those emergency alert messages people keep going on about :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Looking for help from a GTK guy with 2 projects
Have you considered Maliit? http://wiki.maliit.org/Documentation/Installing#Maemo_5_.28Fremantle.29 That looks nice but: 1.Its clearly stated that its use on Maemo5 is "not ready for prime time" 2.Its written in QT (and not only that, it uses QT version labeled "experimental") and takes over a lot more of the input system than I would like (including not using Maemo keyboard layouts which is something I want to keep doing) and 3.There is no way Maliit or anything based on it would be accepted into the CSSU because of #1 and #2. (and the CSSU is the eventual target for any keyboard replacement. The replacement that I want help to write needs to: 1.Replace as little as possible of the input system (ideally only hildon-im-vkbrenderer itself) 2.Not use any libs other than whats included in a stock PR1.3.x/CSSU image 3.Be written using just GTK and not QT. and 4.Be suitable for eventual inclusion into the CSSU. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Looking for help from a GTK guy with 2 projects
I already written hildon control panel plugin (clone of maemo-applet-tvout: http://atrey.karlin.mff.cuni.cz/~pali/maemo-applet-tvout.git/ ), so I can help you. But What is Cell Broadcast SMS? Already found someone to help me with this work but thanks for the offer. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Looking for help from a GTK guy with 2 projects
I am looking for someone with some GTK skills to help me with 2 projects. The first is my Cell Broadcast SMS widget, I need someone who can help me write the control panel/settings thing (including use of whatever settings storage method makes the most sense) The second is related to my virtual keyboard work. Rather than create an identical clone of the existing virtual keyboard, I have realized that its better to figure out exactly what the external interface to libhildon-im-vkbrenderer is and then have someone else with the right GTK skills write a new virtual keyboard that confirms to the same externals (and is therefore a drop-in replacement) Please let me know if you have the skills and can help me. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
New stuff available for creating/editing virtual keyboards on the N900 now available
I have just released some stuff to aid in creating/editing virtual keyboard layouts on the N900, including layouts for the "special characters view" (i.e. what you get if you press "sym") Download http://www.cncmods.net/files/vkb.zip The following files are included: decode_vkb.pl script to decode a .vkb file to XML for editing (its a modification of an existing Perl script, it now properly decodes everything the N900 vkb parser will parse) gen_vkb binary for program to generate a .vkb file from an XML file (its a clone of the gen_vkb from older Maemo versions but it supports all the N900 features) gen_vkb.c source for gen_vkb gen_vkb.sh script to compile gen_vkb.c imlayout_vkb.h header file you can use to talk to the libimlayout library (which loads and parses the vkb files) vkb-format-v4.txt (modified/updated description of the .vkb file format) If you wish to compile gen_vkb.c, you will need to put gen_vkb.c and gen_vkb.sh in a folder on your scratchbox setup, then put imlayout_vkb.h in your /usr/include, then make sure you have the libimlayout0 package installed in your scratchbox install, then create a symbolic link from /usr/lib/libimlayout.so.0 to /usr/lib/libimlayout.so. Then run gen_vkb.sh. gen_vkb should compile and run for both x86 and ARM if you have a usable libimlayout library available. The stock vkb files are in /usr/share/keyboards and /usr/share/scv_layouts ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
where to get gen_fkb?
I see references here https://bugs.maemo.org/show_bug.cgi?format=multiple&id=2892 and elsewhere to a gen_fkb program used to generate keyboard layout files for the virtual keyboard (including the symbols keyboard you get if you press "blue arrow" then "sym") but I cant find it anywhere. Only copy I can find dates back to the N770 and appears to be useless for the N900. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
tablet-browser-view-test source is now available
If you want to embed a browser widget in your app, tablet-browser-view takes care of a lot of the work (including scrolling and zooming) Download http://www.cncmods.net/files/tablet-browser-view-test.c You will also need http://www.cncmods.net/files/browser-neteal-dev_0.7.10.1-2+0m5_all.deb http://www.cncmods.net/files/browser-neteal-dev-0.7.10.1-2+0m5.zip ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
browserd (aka tablet-browser-daemon) is now open source
I have taken the old browserd source code at http://vcs.maemo.org/svn/browser/client-server/trunk/server/ and come up with a set of code that is functionally identical to the N900 browserd. http://www.cncmods.net/files/tablet-browser-daemon_0.6.3-3.1+0m5.zip contains the modified code, its made to be as close to the (closed source) Nokia version as possible. You will also need http://www.cncmods.net/files/microb-eal-dev_2.9.5-1.23+0m5_armel.deb (compiled from the Fremantle microb-eal package) Also of value is http://www.cncmods.net/files/browser-neteal-dev-0.7.10.1-2+0m5.zip and http://www.cncmods.net/files/browser-neteal-dev_0.7.10.1-2+0m5_all.deb which lets you talk to the browserd daemon in the same way as the stock web browser. http://www.cncmods.net/files/eal-client.c is an example source file showing how to use it. With this browserd source code, there is nothing (other than time/interest from people with the right skills) stopping someone (e.g. CSSU) porting a more recent Gecko version to Maemo5. I am currently considering cloning the browser-neteal package (the UI packages like tablet-browser-view are too complicated to clone and the code in the old repos is useless for the purpose) I am also considering cloning the tutorial/getting started applet so it can be used as an example of how to use browser-neteal and possibly also something that could be made into a "flash launcher" (i.e. pass it the URL or filename of a .swf file and it will show/play that flash file) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
differences in N900 regional versions?
Can anyone tell me whats different between the USA, Middle East and North Africa, India, UK and Global releases of the N900 software? Or does someone have a N900 with a version other than the global release who can show me the dependancies list for mp-fremantle-pr or whatever its called (since that will tell me whats different) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
looking for help from a GTK/hildon guru
I am working on a test program to test out browser-neteal (so you can talk to the browser daemon and stuff just like the stock web browser, conversations app etc) and to eventually provide an example people can use to see how to create a flash app or web page as an application ala the tutorial application. But its not working, it just displays a blank black screen until I kill it. And yes there is valid HTML in my test html file (and it displays fine in the maemo browser) Can someone with more hildon and GTK skills than I have take a look at and see if I have made any mistakes with the hildon/GTK stuff? Source and binary packages from the browser-neteal-dev package I have been working on http://www.cncmods.net/files/browser-neteal-dev-0.7.10.1-2+0m5.zip http://www.cncmods.net/files/browser-neteal-dev_0.7.10.1-2+0m5_all.deb sample program http://www.cncmods.net/files/browsertest.c ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
how to talk to browserd/embed browser in your app?
Does anyone know if there exists any known public way to use browser-neteal or tablet-browser-view (the packages used by e.g. conversations to embed the web browser widget) or is the only way to embed a browser widget in your app to pull the whole thing in via gtkmozembed or qtwebkit or similar? I ask because if there is no public information, I intend to reverse engineer some things and come up with a set of files to let you embed these things :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
libconnui-dev-0.1 and operator-name-cbs-widget-0.1 updated, testers wanted (and help wanted with gconf and gtk)
I have uploaded new versions of libconnui-dev and operator-name-cbs-widget. The new version of operator-name-cbs-widget should more closely match the stock widget in terms of what operator name it displays. You can get the source and .deb files for both at http://www.cncmods.net/files/libconnui-dev-0.1.zip http://www.cncmods.net/files/libconnui-dev_0.1_all.deb http://www.cncmods.net/files/operator-name-cbs-widget-0.1.zip http://www.cncmods.net/files/operator-name-cbs-widget_0.1_armel.deb operator-name-cbs-widget will require libconnui-dev to compile. To install libconnui-dev, you need to copy libconnui.so.0.0.0 and libconnui_cell.so.0.0.0 from your phone into the /usr/lib of your scratchbox target. To use it, just pass libconnui-dev to pkg-config to get the right include/lib paths and libraries. Then #include in your code. What I am looking for is for people willing to install and test operator-name-cbs-widget and report back with any issues (e.g. if it fails to display an operator name when it should or if it displays the wrong operator name or if its displaying a bogus cell tower name or if its causing hildon-home to crash). I am also looking for someone who can help me with gconf and gtk to implement some options in the dummy control panel (and matching code in the widget). Specifically I need a checkbox to make the logging optional (i.e. all of the fopen/fprintf/fclose calls in operator-name-cbs-widget.c) and another checkbox to make the cell broadcast SMS display optional (not sure exactly what the best place to insert that code is) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: announcing libconnui-dev-0.1 and operator-name-cbs-widget-0.1
Michael Cronenworth wrote: Jonathan Wilson wrote: If anyone has any feedback on my code (or if you have found bugs in it) please let me know so I can make my code better :) If anyone starts playing with or using libconnui-dev, I would also be interested to know. While I find your work very interesting I keep coming back to one question in my mind: What are you developing this for? Just to provide an open source alternative to the closed source libs? Its a set of header files to allow developers to use the functionality inside these closed-source libraries, some of the functionality seems useful to me (bits of functionality are being used in operator-name-cbs-widget-0.1) and I am guessing other devs may also like it. I am not planning to clone these libraries as the Nokia versions work just fine. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
announcing libconnui-dev-0.1 and operator-name-cbs-widget-0.1
I have just released libconnui-dev-0.1 and operator-name-cbs-widget-0.1 they can be found at http://www.cncmods.net/files/libconnui-dev-0.1.zip and http://www.cncmods.net/files/operator-name-cbs-widget-0.1.zip libconnui-dev-0.1 is a set of reverse-engineered declarations for the closed-source libconnui and libconnui_cell libraries (which are used for various things by connectivity status bar widgets, control panels and other things). I tried to reverse engineer as many of the "interesting-looking" functions as possible. Obviously not all of them are tested yet (I dont particularly want to test connui_cell_emergency_call for example although connui_cell_emergency_get_numbers works :) but I tested a few of the ones that were easy to test. Some of them are also being used by operator-name-cbs-widget-0.1. To install libconnui-dev-0.1 you need to copy libconnui.so.0.0.0 and libconnui_cell.so.0.0.0 from your phone into the /usr/lib of your scratchbox target. Then you need to unzip libconnui.zip into the scratchbox target location (so that the files end up in /usr/include/* and /usr/lib/*) Then you go to /usr/lib and do these commands: ln -s libconnui.so.0.0.0 libconnui.so.0 ln -s libconnui.so.0 libconnui.so ln -s libconnui_cell.so.0.0.0 libconnui_cell.so.0 ln -s libconnui_cell.so.0 libconnui_cell.so To use it, just pass libconnui-dev to pkg-config to get the right include/lib paths and libraries. Then #include in your code. operator-name-cbs-widget-0.1 is a replacement for the standard operator name home screen widget. It displays the operator name using an algorithim that is almost identical to the stock nokia algorithim (it doesn't handle some extra data related to roaming, I am still working on figuring out what the nokia code is doing). It also displays any cell broadcast SMS messages it recieves on channel 50 (i.e. the cell tower name, if the tower sends one) alongside the operator name. (although I plan to make the tower name display optional via an option in the currently-empty control panel). You will need the libconnui-dev stuff set up if you want to compile operator-name-cbs-widget. If anyone has any feedback on my code (or if you have found bugs in it) please let me know so I can make my code better :) If anyone starts playing with or using libconnui-dev, I would also be interested to know. Oh and if anyone wants a precompiled .deb of operator-name-cbs-widget, let me know and I will make one available. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Looking for anyone who can roam their N900 onto a network other than their home network
If you have a N900 running Fremantle and can roam said N900 onto a network that is not the home network, I need some information from you. Please run run the following shell script on your N900 (make sure the script has UNIX line endings rather than dos otherwise things will break) echo get_service_provider_name dbus-send --system --print-reply --dest=com.nokia.phone.SIM /com/nokia/phone/SIM Phone.Sim.get_service_provider_name echo get_service_provider_info dbus-send --system --print-reply --dest=com.nokia.phone.SIM /com/nokia/phone/SIM Phone.Sim.get_service_provider_info CSD_NET=`dbus-send --system --print-reply --dest=com.nokia.phone.net /com/nokia/phone/net Phone.Net.get_registration_status | grep uint32` OPERATOR_COUNTRY_CODE=`echo -e $CSD_NET | awk 'NR < 2{ print $6 }' ` OPERATOR_NETWORK_ID=`echo -e $CSD_NET | awk 'NR < 2{ print $4 }'` NETWORK_ID=$OPERATOR_NETWORK_ID OPERATOR_NETWORK_ID_STRIPPED=`echo $NETWORK_ID | sed 's/0*//'` echo country $OPERATOR_COUNTRY_CODE echo operator $OPERATOR_NETWORK_ID_STRIPPED echo NET_NITZ_FULL_OPER_NAME dbus-send --system --print-reply --dest=com.nokia.phone.net /com/nokia/phone/net Phone.Net.get_operator_name byte:3 uint32:$OPERATOR_NETWORK_ID_STRIPPED uint32:$OPERATOR_COUNTRY_CODE echo NET_HARDCODED_LATIN_OPER_NAME dbus-send --system --print-reply --dest=com.nokia.phone.net /com/nokia/phone/net Phone.Net.get_operator_name byte:0 uint32:$OPERATOR_NETWORK_ID_STRIPPED uint32:$OPERATOR_COUNTRY_CODE I need the output when you run it on both the home network and the roaming network. I also need to know which operators are involved (i.e. who you pay for services, who owns the equipment for the home network and who owns the equipment for the roaming network) as well as whether you were connected to 2G or 3G and what operator name was displayed on the home screen for both the home network and the roaming network. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Looking for anyone with a N900 running Maemo5 to run a shell script & get some diagnostics for me
I want everyone who has a N900 running Maemo5 (and who can do it) to run the following shell script on their N900 (make sure the script has UNIX line endings rather than dos otherwise things will break) echo get_service_provider_name dbus-send --system --print-reply --dest=com.nokia.phone.SIM /com/nokia/phone/SIM Phone.Sim.get_service_provider_name echo get_service_provider_info dbus-send --system --print-reply --dest=com.nokia.phone.SIM /com/nokia/phone/SIM Phone.Sim.get_service_provider_info CSD_NET=`dbus-send --system --print-reply --dest=com.nokia.phone.net /com/nokia/phone/net Phone.Net.get_registration_status | grep uint32` OPERATOR_COUNTRY_CODE=`echo -e $CSD_NET | awk 'NR < 2{ print $6 }' ` OPERATOR_NETWORK_ID=`echo -e $CSD_NET | awk 'NR < 2{ print $4 }'` NETWORK_ID=$OPERATOR_NETWORK_ID OPERATOR_NETWORK_ID_STRIPPED=`echo $NETWORK_ID | sed 's/0*//'` echo country $OPERATOR_COUNTRY_CODE echo operator $OPERATOR_NETWORK_ID_STRIPPED echo NET_NITZ_FULL_OPER_NAME dbus-send --system --print-reply --dest=com.nokia.phone.net /com/nokia/phone/net Phone.Net.get_operator_name byte:3 uint32:$OPERATOR_NETWORK_ID_STRIPPED uint32:$OPERATOR_COUNTRY_CODE echo NET_HARDCODED_LATIN_OPER_NAME dbus-send --system --print-reply --dest=com.nokia.phone.net /com/nokia/phone/net Phone.Net.get_operator_name byte:0 uint32:$OPERATOR_NETWORK_ID_STRIPPED uint32:$OPERATOR_COUNTRY_CODE What I want is the output from this shell script. I also want to know what the name of your service provider is (i.e. the company you pay for service) as well as the name of your operator (i.e. the company that actually operates the cell towers and/or matches the MNC/MCC that get output by the script as "country" and "operator") and I want to know whether you were connected to 2G or 3G when you ran the script as well as what operator name was displayed on the home screen and whether you were roaming or on your home operator at the time. (if there is someone out there who is in a position to get output from when you are roaming rather than on your home network, that would be nice) This data will help me figure out exactly how to get the operator name as displayed by the home screen widget so that my Cell Broadcast SMS widget can display the correct name 100% of the time. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
looking for help with dbus_g_proxy_call
This code: #define PHONE_SIM_SERVICE "com.nokia.phone.SIM" #define PHONE_SIM_PATH "/com/nokia/phone/SIM" #define PHONE_SIM_IFACE "Phone.Sim" #define GET_SERVICE_PROVIDER_NAME "get_service_provider_name" DBusGProxy *dbus_g_proxy = NULL; dbus_g_proxy = dbus_g_proxy_new_for_name(plugin->priv->dbus_conn, PHONE_SIM_SERVICE, PHONE_SIM_PATH, PHONE_SIM_IFACE); if(dbus_g_proxy) { gchar *operator_name = NULL; guint32 val1; guint32 val2; gint32 val3; if(dbus_g_proxy_call(dbus_g_proxy, GET_SERVICE_PROVIDER_NAME, NULL, G_TYPE_INVALID, G_TYPE_STRING, &operator_name, G_TYPE_UINT, &val1, G_TYPE_UINT, &val2, G_TYPE_INT, &val3)) { if ((operator_name != 0) && (operator_name[0] != 0)) { free(plugin->priv->operator_name); plugin->priv->operator_name = strdup(operator_name); g_free(operator_name); g_object_unref(dbus_g_proxy); return; } } g_object_unref(dbus_g_proxy); } should be doing the same as this: dbus-send --system --type=method_call --print-reply --dest=com.nokia.phone.SIM /com/nokia/phone/SIM Phone.Sim.get_service_provider_name dbus_g_proxy is initialized to a valid value but the dbus_g_proxy_call call is failing. I can confirm that the dbus-send command outputs valid output on my device, I just cant figure out why my dbus_g_proxy_call call is failing. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
looking for feedback on operator-name-cbs-widget
I uploaded the first pass of my code here: http://www.cncmods.net/files/operator-name-cbs-widget-0.1.zip It works pretty good, it applies the patch and it displays the right output (except for the operator name which I am still working on) but I want further feedback on what I should be doing differently. I dont plan to change it to use CDBS or anything like that, I am happy with the Debian control files as they stand right now, I just want to know the minimum I should be doing differently to make it a proper package worthy of submitting to the repos (extras-devel or whatever) and hopefully eventually to the cssu (assuming its suitable for that) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Looking for some help with autoconf/automake/dpkg (and general feedback on my code)
Daniil Ivanov wrote: > At least debian/install is missing in debianization of a package > http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install Thanks, that's a start. Still cant get it to even produce a cbspatch binary though. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Looking for some help with autoconf/automake/dpkg (and general feedback on my code)
I have uploaded my code and files to http://www.cncmods.net/files/operator-name-cbs-widget-0.1.zip I am looking for general feedback on this code and packaging but specifically I am having problems getting it to create, include in the .deb file and run the cbspatch binary I suspect also I need more in the postinst file in terms of verifying the correct binary and things, any help would be appreciated. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: looking for info from Phone.SIM.get_service_provider_info, Phone.SIM.get_service_provider_name and getting the proper operator name
> My suggestion was to eavesdrop on what the plug-in is doing. You > could just eaves drop on the whole system bus and then grep of the > strings you are looking for. I have a few weeks worth of such logs > and I found one relevant reference: I already know what the plugin is doing, it uses some combination of Phone.Net.get_operator_name, Phone.SIM.get_service_provider_info and Phone.SIM.get_service_provider_name and possibly other things to decide what operator name to display. What I dont know is how it actually does that and decides what operator name to display because the Phone.SIM dbus calls are undocumented. If I could figure out how the Phone.SIM dbus calls work (or better yet how to call various functions in libconnui.so & libconnui_cellular.so) I could make this work. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: looking for info from Phone.SIM.get_service_provider_info, Phone.SIM.get_service_provider_name and getting the proper operator name
I run dbus-send --system --type=method_call --print-reply --dest=com.nokia.phone.SIM /com/nokia/phone/SIM Phone.Sim.get_service_provider_name and get string "TPG" uint32 0 uint32 0 int32 0 I run dbus-send --system --type=method_call --print-reply --dest=com.nokia.phone.SIM /com/nokia/phone/SIM Phone.Sim.get_service_provider_info and get array [ ] int32 1003 Problem is, there is no information available as to what the parameters are (other than the operator name obviously) Hence why I need information. Perhaps if other people post the output from running the same commands, it might make it easier to figure out what we are looking at. That or someone needs to reverse engineer libconnui_cellular.so :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
looking for info from Phone.SIM.get_service_provider_info, Phone.SIM.get_service_provider_name and getting the proper operator name
I am trying to find out how to get the proper operator name as displayed by the home widget. I know about Phone.Net.operator_name_change and Phone.Net.get_operator_name and the other Phone.Net calls but that returns the actual operator (in my case "YES OPTUS") and not the service provider (in my case its "TPG") The stock operator widget uses calls to Phone.SIM.get_service_provider_info and Phone.SIM.get_service_provider_name to get the correct service provider but I cant find any info on what those dbus calls do or return. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Looking for some help/tutorials on status bar widgets for my "Cell Broadcast SMS" status bar widget
I have gotten my Cell Broadcast SMS code finished to the point where it does everything it should except that it: 1.Writes to a log file instead of updating a status bar widget (i.e. the log file is written to anytime something happens that would trigger a change in the status bar widget) and 2.Doesn't handle anything other than the location messages on channel 50 (mostly because I cant find any information on how to handle those messages or what they are for and because I dont know how to handle multi-page CBS messages) I am looking for someone who can help me build a status bar widget to display the location information. I understand some of how to program in QT but GTK (which is what you are supposed to use to write status bar widgets) is totally alien to me. The widget I want to build would basically be similar to the (unfortunatly closed source) connui-home-cellular widget (which displays the operator name) Help with parsing and displaying the other non-location messages would be nice too if anyone knows how to do that. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N950 SEGFAULT - help?
the debug information found in "c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvrPVR2D_DRI2WSEGL_r125.so" does not match "c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvrPVR2D_DRI2WSEGL.so" (CRC mismatch). the debug information found in "c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvr2d_r125.so" does not match "c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvr2d.so" (CRC mismatch). The libpvr libraries are binary blobs for the PowerVR GPU and have nothing to do with QT. No I dont know where you would get appropriate blobs that will not cause the errors you are seeing. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Rtcom-Eventlogger Source
There is source at http://repository.maemo.org/pool/maemo5.0/free/r/rtcom-eventlogger/ for version 1.4-4+0m5 which matches whats on my fully updated phone. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
New wiki page with links to relavent information on the N900 and its binary blobs
I have created a wiki page http://wiki.maemo.org/N900_Resources with links to all the relavent information I (and others) have found/collected/figured out regarding various bits (especially binary closed bits) of the N900 Fremantle software. If you have anything else relavent for the wiki page, feel free to update it. (maybe someone else knows of some hidden gems that may help :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
How to attach gdb to hildon-desktop?
Can anyone tell me how I can attach gdb to hildon-desktop (on the phone, not in the SDK environment) so I can debug a status bar widget? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
I am attempting to clone the mce libvibrator.so plugin, help wanted
I have dumped my code here http://www.cncmods.net/files/mce.zip Its a rather hacked up version of the MeeGo mce source tree (or rather the oldest version in that particular repo) and currently only builds libvibrator.so (any files not linked into libvibrator.so are assumed to be WIP and/or unusable) The plugin builds fine but when I run it on my N900 in place of the stock plugin, it just makes mce go crazy and doesn't actually seem to work. Any help in finding out why this plugin isn't working or to bring it closer to a functioning state would be GREAT :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Can anyone tell me how the N900 vibrator driver works?
ICD2 policy plugins never went anywhere, I dont think I can make them do what I thought they could and would need to clone the entire icd2 binary (and given how hard cloning any binary is, even simple ones, that's not something I plan to try) mce plugins are on hold, all I have so far is an attempt to clone the vibrator plugin. The resulting plugin does not work properly though (will be making a post about it on the mailing list in case someone can help me find out why its not working) cell broadcast SMS is still on the go, right now I am stuck because I cant figure out the various cell network related dbus signals (or the functions in libconnui and libconnui-cellular that the connectivity widgets use) tklock (touchscreen and keypad lock), I posted the information on that to the mailing list and hopefully the people doing custom lock screens will take it and use it for their custom lock screens bme stuff, I posted on the mailing list with all the info one would need related to hald-addon-bme and libbmeipc for the benefit of those who want to replace bme with something talking directly to the hardware All of my other ideas for cloning stuff (like cloning the clock settings applet) never went anywhere. So right now I am going to hope that someone comes up with the goods and can help me get my libvibrator.so clone going and that someone can help me reverse engineer libconnui/libconnui-cellular and/or help me with the csd-net dbus signals so I can move forward with my plans for Cell Broadcast SMS. As for code, the only code I have posted that's of any use so far is the Cell Broadcast SMS stuff at http://www.cncmods.net/files/cbsdunp.zip and the stuff related to the tklock at http://www.cncmods.net/files/systemui.h ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Can anyone tell me how the N900 vibrator driver works?
I am looking for information on the driver the responds to /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_vibra/pulse and in particular details of just what it does with the numbers. Pointers to the source code for the driver in question may also help although I dont know the first thing about linux kernel drivers :P I am attempting to create a clone of the N900 mce vibrator plugin (so that it can be extended and improved) and having this info would help me understand what is going on. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Details on the information required to replace the tklock (touchscreen/key lock) systemui plugin
The information here references this header file http://www.cncmods.net/files/systemui.h It assumes you are familiar with dbus, glib and gconf. Where I refer to "the code" in these notes, unless otherwise specified, I mean the source code to various versions of mce as published online in various places All systemui plugins go in the /usr/lib/systemui folder and are named libsystemuiplugin_blah.so. The stock tklock plugin is named libsystemuiplugin_tklock.so. All systemui plugins link to the systemui binary and call functions contained within it (my gcc-fu isn't up to code so I dont know exactly how one would go about doing that in scratchbox) Systemui plugins export 2 functions plugin_init is called when systemui starts up and plugin_close is called when it shuts down. Their prototypes match what is given in systemui.h The tklock plugin plugin_init function registers 2 systemui handlers using systemui_add_handler and also registers a dbus signal handler for the signal display_status_ind sent by mce (documentation for the display_status_ind dbus call is in the mce-dev documentation) The plugin_close function uses systemui_remove_handler to remove the 2 handlers. The 2 handlers match to dbus messages sent by mce to systemui (which then calls the registered handlers for those messages) Specifically, handlers are registered for SYSTEMUI_TKLOCK_OPEN_REQ and SYSTEMUI_TKLOCK_CLOSE_REQ The prototype of a callback function matches the typedef in systemui.h The argarray is a GArray containing instances of type dbustype (not pointers to dbustype structures but actual structures one after the other) With regards to the dbustype structure (specifically as used for the returntype parameter), the unk1 and unk2 fields should be left alone. The type field contains a 32-bit integer corresponding to the relavent dbus type character such as 's' or 'u' or 'b'. the value field contains the value. If the dbus type character is 's', the value field is a char * pointer to the string, if it is 'u', the value field is an int, if it is 'b', the value field is a single byte boolean value. Also, the return type of the callback function should be a dbus type. The entries in the system_ui_data parameter should be used when referencing dbus, gconf etc (i.e. fields like gc_client, dbusconnection etc) Both of the systemui dbus handlers get passed 4 string parameters as their first 4 arguments, these are used for the callback mechanism (along with the systemui_check_set_callback, systemui_do_callback and systemui_free_callback functions which will be mentioned later) The SYSTEMUI_TKLOCK_OPEN_REQ handler gets passed a uint argument for the lockscreen mode, can be TKLOCK_ENABLE, TKLOCK_ONEINPUT or TKLOCK_ENABLE_VISUAL. TKLOCK_ONEINPUT is for the blank screen lock mode (called "event eater mode" in the code) and TKLOCK_ENABLE_VISUAL is for the slide to unlock screen. Not sure what TKLOCK_ENABLE is for exactly. The second parameter is a boolean argument labeled "silent" by the code. The code says "true = disable infoprints, false = enable infoprints". The third parameter is a flag that seems to indicate if there is a "flicker key" (whatever that is). Both the second and third parameters seem to be ignored by the stock tklock plugin. The SYSTEMUI_TKLOCK_CLOSE_REQ handler gets passed a single bool argument. This is the same "silent" value as above and is also ignored by the stock tklock plugin. systemui_check_plugin_arguments is used to check the passed in arguments. Pass it the GArray from the callback, an array of 32-bit ints containing the arguments (NOT including the first 4 string arguments). So for the tklock_open callback, you would pass in 'u','b','b' (all as 32-bit ints obviously) and a count. The return value of systemui_check_plugin_arguments is 0 for failure, 1 for success. Here is what the tklock_close handler does: Calls check_plugin_arguments to verify the plugin arguments. Calls systemui_free_callback to free the callback arguments stored earlier by a call to systemui_check_set_callback. Calls some functions to shut down the lockscreen logic. then returns 'v' as its return value and does not set returntype parameter. The tklock_open handler calls check_plugin_arguments to verify the plugin arguments, it also calls functions to create the appropriate lock handler based on the mode. And it calls systemui_check_set_callback to store the callback handler details. It sets returntype.type to 'i' and returns 'i'. It also sets returntype.value to either -2 or -3 (not sure if the values matter) systemui_do_callback is called passing in a member of the tklock_status enum as the callbackarg parameter. Other things the code does: Registers a handler for the dbus signal com.nokia.clockd /com/nokia/clockd time_changed (used to update the time on the lock screen) Triggers the dbus signal com.nokia.tklock.signal /com/nokia/tklock/signal mm_key_press. Unsure what
How to get dbus-monitor to listen to more dbus messages?
I am trying to get dbus-monitor to listen to some dbus messages, (specifically the tklock_open and tklock_close messages sent from mce to systemui for the device lock state) and no combination of arguments to dbus-monitor seems to get dbus-monitor to output them. After trying this http://mvidner.blogspot.com/2008/05/d-bus-spying.html to try and get dbus-monitor to show me what I wanted to see and nearly bricking my phone in the process, I am out of ideas. Any ideas on how to get logs of these messages would be appreciated (and if editing the dbus config file is the right solution, I need exact steps to do it that are known to be safe and easily reversible) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Looking for information on some cell network related dbus signals
I am looking for anything anyone here knows about what event(s) would cause the following dbus signals to trigger: (or any other information about those signals :) registration_status_change cellular_system_state_change radio_access_technology_change radio_info_change cell_info_change operator_name_change ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[CSSU] Replacements for closed-source apps in the CSSU, what are the targets?
I notice that the CSSU has replacements for a number of closed-source Nokia packages like the TV-out control panel, the notification light control panel, the display control panel, the camera UI, the FM transmitter status widget, the calculator, battery status widget and the profiles widget. Are there any other nokia-closed-source packages (widgets, control panels, apps etc) that would be beneficial to create an open replacement for to then use in the CSSU? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Information on the interface to hald-addon-bme (so it can be replaced with something that bypasses BME and talks to the kernel directly)
The following items are exposed by hald-addon-bme: HAL items exposed under /org/freedesktop/Hal/devices/bme maemo.charger.type (data type is string), valid values are wall charger host 500 mA host 100 mA none unknown error initial value is none maemo.charger.connection_status (data type is string), valid values are connected error disconnected unknown initial value is disconnected maemo.rechargeable.charging_status (data type is string), valid values are error unknown on continue off full initial value is off maemo.rechargeable.positive_rate (data type is bool). Set when the flow into the battery is positive as far as I can tell. initial is false battery.present (data type is bool) Always set to true battery.type (data type is string) Always set to pda battery.is_rechargeable (data type is bool) Always set to true battery.remaining_time (data type is int) set to the remaining battery use time battery.charge_level.capacity_state (data type is string), valid values are low ok full empty unknown initial value is ok battery.charge_level.unit (data type is string) Always set to bars battery.charge_level.design (data type is int) Set to the design charge level, initial value is 0 battery.charge_level.current (data type is int) Set to the current charge level, initial value is 0 battery.charge_level.percentage (data type is int) set to capacity / nominal capacity, initial value is 0 battery.charge_level.last_full (data type is int) set to last full charge level, initial value is 0 battery.rechargeable.is_charging (data type is bool) set when charging, initial value is false battery.rechargeable.is_discharging (data type is bool) set when discharging, initial value is false battery.reporting.unit (data type is string) Always set to mAh battery.reporting.design (data type is int) set to nominal capacity, initial value is 0 battery.reporting.last_full (data type is int) set to last full capacity, initial value is 0 battery.reporting.current (data type is int) set to current capacity, initial value is 0 battery.voltage.unit (data type is string) Always set to mv battery.voltage.design (data type is int) initial value is 0, it will then be set to one of 4100 4200 battery.voltage.current (data type is int) set to current voltage, initial value is 0 battery.remaining_time.calculate_per_time (data type is bool) Always set to false Also, hald-addon-bme exposes the following signals under com.nokia.bme.signal /com/nokia/bme/signal (unless otherwise specified, these signals have no arguments) charger_connected charger_disconnected charger_charging_failed charger_charging_off charger_charging_on battery_full battery_empty battery_low battery_state_changed (arguments for this are 2 uints, dbus type 'u', unknown exactly what they are for) battery_timeleft (arguments for this are 2 uints, dbus type 'u', first one is for idle time, second is for active time) The purpose of these signals should be self-explanatory for the most part. Plus it exposes 2 dbus methods on com.nokia.bme.request. Both take no parameters. The status_info_req method causes a method to be run that will send the appropriate signals from the list above. The timeleft_info_req method also causes the signals to be sent but it also sends a message to BME to retrieve the relavent data for the timeout fields. Also it should be possible to create a dummy libbmeipc that supports the bits needed by dsme-thermalobject-surface and modules-nokia-voice.so (the 2 users of libbmeipc we need to care about), thus allowing a complete replacement of BME without loosing the functioning of the nokia pulseaudio bits. Information that is relavent for said libbmeipc replacement: (all taken from various revisions of the LGPL MeeGo n900_libbme sources and all verified against the N900 Fremantle BME to ensure they match) typedef __uint16_t uint16; typedef __uint32_t uint32; struct emsg_battery_info_req { uint16 type, subtype; uint32 flags; }; struct emsg_battery_info_reply { uint32 zero; uint32 flags; uint16 bat_type; uint16 nominal_capa; uint16 temp; uint16 voltage; uint16 voltage_tx_on; uint16 voltage_tx_off; uint16 voltage_pwm_on; uint16 voltage_pwm_off; uint16 generation; uint16 voltage_sh_chk; }; union emsg_battery_info { struct emsg_battery_info_reqrequest; struct emsg_battery_info_reply reply; }; #define EM_BATTERY_INFO_REQ 0x06 #define EM_BATTERY_TEMP 0x0004 int bme_connect(void); void bme_disconnect(void); int bme_write(const void *msg, int bytes); int bme_read(void *msg, int bytes); Study the source code of dsme-thermalobject-surface to see how it is calling libbmeipc and what its sending to (and receiving from) BME. I can confirm from my analysis that module-nokia-voice is making the exact same libbmeipc calls (and, like dsme-thermalobject-surface, only cares about th
detecting flight-mode and change of cell network status, how to do it?
Does anyone know of a way to detect flightmode (i.e. phone switching into and out of flight mode) or a way to detect a switch of cell network (e.g. change between 2G and 3G or change to another operator via roaming) Analysis of the cellular operator name widget reveals that libconnui has functions for this (connui_flightmode_close, connui_flightmode_status, connui_cell_net_status_close and connui_cell_net_status_register) but I have no idea how to call them as libconnui is unfortunatly undocumented :( (which is a pitty as there are a LOT of interesting looking APIs in there) Note I am not interested in simply being able to obtain the current status of these things, I am interested in being notified of changes in the state in the way that the cellular operator name widget is. Presumably libconnui is wiring up to something lower down (dbus or whatever) in order to obtain these notifications so we need to figure out what its tapping into to get the info. This is in support of Cell Broadcast SMS so I dont keep displaying stale information (no point in displaying the name of a cell tower you last saw half-an-hour-ago when you phone switched to 3G and isn't receiving operator name SMSs anymore. Although the other option might be to add a timeout and say "ok, if we dont receive another operator name SMS in the next x number of minutes, we declare the information "stale" and stop displaying it" ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
more Cell Broadcast SMS code
http://www.cncmods.net/files/cbsdump.zip contains the latest code I have got for testing Cell Broadcast SMS work. The files need to be compiled in a Scratchbox FREMANTLE_ARM environment with dbus and glib installed. run cbsdump.sh to compile. cbspatch.c will apply the needed patch to /usr/lib/libsms.so.0.0.0 Note that it does not back up the file before hand nor does it verify the correct checksums. Can someone who knows N900 shell scripting create a script to handle it all? (i.e. check the checksum, backup the file and run the patcher) cbsdump.c is a program that, when run, sits there and listens for the IncomingCBS signal. It will then decode the Cell Broadcast SMS PDU (I have no idea what it will do with multi-page PDUs though since I have nothing I can use to test) and write it to /home/user/MyDocs/cbsms.log. Be aware that if you leave this running for too long it will simply keep expanding cbsms.log until it runs out of space. The only thing I have tested it on so far are the Cell Broadcast messages my local towers are sending (cell tower names on channel 50). Tomorrow I plan to go on a big trip as far as the bus/train system will take me and log as many different cell towers as possible :) smsutil.c, smsutil.h, util.c and util.h are hacked/modified versions of the same files from ofono (modified to remove a few dependancies the bits I needed dont use) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[CSSU] Advice wanted on the best way to package Cell Broadcast SMS bugfix for closed libsms library
Basically, due to a bug in libsms (closed source Nokia library that's part of the telephony stack in Fremantle), Cell Broadcast SMS does not work on the N900. Specifically it is a bug in the function sms_gsm_cb_routing_ntf. Its clear at this point that Nokia will not release the source code to libsms (or back-port the fix for this bug from Harmattan where it appears to be fixed). Nor are they likely to release the information required to allow replacement of libsms without a wholesale replacement of most of the telephony stack (including the dialer, messaging app etc). Given this, I have come up with a possible solution and would like advice on the best way to package this solution. Option 1: Patch libsms (there are 3 bytes that need to be changed to fix the bug) and distribute the patched .so file. (i.e. basically an updated libsms package) Option 2: Distribute a package that will patch (and un-patch on uninstall I would guess) libsms with the 3 changed bytes to fix the bug. Option 3: Distribute a package that somehow loads something into the memory space of the CSD daemon and applies the 3-byte patch to the in-memory image of libsms. Option 4: Create a clone of sms_gsm_cb_routing_ntf and use LD_PRELOAD or something similar to cause libsms to use the clone and not the original in libsms I dont know much about how ARM Linux works (or how Debian packaging works or what the CSSU maintainers would find acceptable) so I dont know which option is the best option. Hence I am asking the CSSU gurus to help me figure out which option is the best option going forward as a way to distribute this fix (which will then allow a user-space widget to be produced that can talk to the IncomingCBS DBUS signal and do something with the incoming Cell Broadcast SMS messages) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Major progress made on Cell Broadcast SMS on N900
What's 0x53 in your patch? I hope it's not just another arbitrary fixed length of SMS text you assume instead of the faulty 0 0x52 is the size of the content_of_message array in the tSMS_SubGSMCBMessage sub-block as passed to userspace by the cell modem firmware. The previously mentioned Harmattan libsms package also uses 0x52 in the same bit of code. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Major progress made on Cell Broadcast SMS on N900
With a bit of reverse engineering and debugging (and a little reverse engineering help from the Harmattan-i386 package of libsms :), I have managed to get Cell Broadcast SMS to function on the N900 up to the point where I can see an incoming cell broadcast message (in this case a cell tower name as that's the only thing my local cell tower is broadcasting) Reference http://www.cncmods.net/files/cbsms.zip for the files I mention in the description below. The reason Cell Broadcast SMS is broken on the N900 is that there is a bug in libsms, specifically it is incorrectly dealing with the size field of the SMS packet being sent from the cell modem firmware. As Nokia are unlikely to fix the bug (at least in Fremantle libsms, its fixed in Harmattan libsms), publish source code for libsms or publish the information required to produce a replacement for libsms that doesn't require rewriting or replacing half the system, I have found a way to patch the binary of libsms to fix the bug. To do it, change byte DD78 from 0xFF to 0x52, (changes a CMP R3, #0xFF instruction to a CMP R3, #0x52 instruction) then change DD7C from 0x00 to 0x52 and DD7F from 0x03 to 0xC3 (changes a MOVEQ R3, #0 instruction into a MOVGT R3, #0x52) After the bug is fixed (whether the right fix is a binary patch to the file on disk or some sort of in-memory patch to the memory of libsms.so as loaded into the CSD daemon I don't know, the binary patch is easier for testing), then you can listen to the IncomingCBS signal via DBUS. dbuscb.c contains a test program (written using the Fremantle Scratchbox SDK) which will listen for the signal and dump any incoming cell broadcast messages to disk (in a file /var/log/cbsms.log) The output in cbsms.log contains PDU data ready to send straight to a Cell Broadcast SMS decoder such as the cbs_decode/cbs_decode_text functions in ofono. cbsms.log contains an example of a dumped cell broadcast message and sms-test.c is a modified ofono test program and contains code to test the decoding of cell broadcast messages dumped from dbuscb (when you run it, it will decode the same cell broadcast message contained in cbsms.log and should print EastVicPark as the decoded message (its the name of a 2G GSM cell tower near where I live, presumably the one sending CBSMS messages to my phone) What is required to make Cell Broadcast SMS messages fully functional is for someone to figure out the best way to apply the binary patch and then for someone to write some kind of UI to do something with the incoming messages. BTW, I can confirm that libsms.so and the SMS subsystem is subscribing to every single cell broadcast SMS message channel (or whatever it is) and will receive anything the tower is sending. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Telepathy approver example for maemo?
Is there an example out there of a Telepathy approver written for maemo using telepathy-glib? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
I am currently reverse engineering rtcom-call-ui (dialer app), help is wanted
http://wiki.maemo.org/Dialer is where I have put all my notes and reverse engineering info so far. I am specifically focusing on non-UI bits as that's what someone building a dialer replacement would need to know. Here is a list of all the functions imported by the dialer app __assert_fail __cxa_finalize __gmon_start__ __strtol_internal __strtoul_internal _Jv_RegisterClasses access auic_client_close auic_client_is_ui_open auic_client_new auic_client_open_accounts_list auic_client_set_visible bind_textdomain_codeset bindtextdomain cairo_destroy cairo_paint cairo_paint_with_alpha clock_gettime close dbus_bus_add_match dbus_bus_get dbus_bus_get_unique_name dbus_bus_remove_match dbus_bus_request_name dbus_connection_add_filter dbus_connection_get_is_connected dbus_connection_remove_filter dbus_connection_send dbus_connection_send_with_reply dbus_connection_send_with_reply_and_block dbus_connection_set_exit_on_disconnect dbus_connection_unref dbus_error_free dbus_error_init dbus_error_is_set dbus_free_string_array dbus_g_bus_get dbus_g_connection_get_connection dbus_g_connection_register_g_object dbus_g_connection_unref dbus_g_method_return dbus_g_method_return_error dbus_g_object_path_get_g_type dbus_g_object_register_marshaller dbus_g_proxy_add_signal dbus_g_proxy_begin_call dbus_g_proxy_begin_call_with_timeout dbus_g_proxy_call_no_reply dbus_g_proxy_end_call dbus_g_proxy_new_for_name dbus_g_type_get_collection dbus_g_type_get_map dbus_g_type_get_struct dbus_message_append_args dbus_message_get_args dbus_message_get_interface dbus_message_get_member dbus_message_is_signal dbus_message_iter_get_arg_type dbus_message_iter_get_basic dbus_message_iter_init dbus_message_iter_next dbus_message_iter_recurse dbus_message_new_method_call dbus_message_set_no_reply dbus_message_unref dbus_pending_call_cancel dbus_pending_call_set_notify dbus_pending_call_steal_reply dbus_pending_call_unref dbus_set_error_from_message dcgettext e_book_query_unref e_book_query_vcard_field_test e_contact_get e_contact_get_const e_contact_get_type e_contact_set e_vcard_add_attribute e_vcard_attribute_add_value e_vcard_attribute_copy e_vcard_attribute_free e_vcard_attribute_get_name e_vcard_attribute_get_value e_vcard_attribute_get_values e_vcard_attribute_new e_vcard_get_attribute e_vcard_get_attributes exit g_array_append_vals g_array_free g_array_new g_array_sized_new g_ascii_strncasecmp g_atomic_pointer_get g_build_filename g_cclosure_marshal_VOID__BOOLEAN g_cclosure_marshal_VOID__BOXED g_cclosure_marshal_VOID__INT g_cclosure_marshal_VOID__OBJECT g_cclosure_marshal_VOID__POINTER g_cclosure_marshal_VOID__STRING g_cclosure_marshal_VOID__UINT g_cclosure_marshal_VOID__VOID g_clear_error g_dgettext g_error_free g_file_set_contents g_free g_get_home_dir g_getenv g_hash_table_destroy g_hash_table_foreach_remove g_hash_table_get_values g_hash_table_insert g_hash_table_iter_init g_hash_table_iter_next g_hash_table_lookup g_hash_table_lookup_extended g_hash_table_new g_hash_table_new_full g_hash_table_remove g_hash_table_remove_all g_hash_table_replace g_hash_table_size g_hash_table_unref g_idle_add g_idle_add_full g_intern_static_string g_key_file_free g_key_file_get_integer g_key_file_load_from_file g_key_file_new g_key_file_set_integer g_key_file_to_data g_list_delete_link g_list_free g_list_length g_list_prepend g_list_reverse g_log g_main_loop_new g_main_loop_quit g_main_loop_run g_main_loop_unref g_object_add_weak_pointer g_object_class_install_property g_object_get g_object_get_data g_object_get_qdata g_object_new g_object_notify g_object_ref g_object_ref_sink g_object_set g_object_set_data g_object_set_data_full g_object_set_qdata g_object_set_qdata_full g_object_unref g_once_impl g_once_init_enter_impl g_once_init_leave g_param_spec_boolean g_param_spec_float g_param_spec_int g_param_spec_object g_param_spec_pointer g_param_spec_string g_param_spec_uint g_ptr_array_add g_ptr_array_sized_new g_quark_from_static_string g_quark_to_string g_queue_free g_queue_is_empty g_queue_new g_queue_pop_head g_queue_push_tail g_return_if_fail_warning g_set_error g_signal_connect_data g_signal_emit g_signal_emit_by_name g_signal_handler_disconnect g_signal_handlers_block_matched g_signal_handlers_disconnect_matched g_signal_handlers_unblock_matched g_signal_lookup g_signal_new g_signal_stop_emission g_signal_stop_emission_by_name g_slice_alloc g_slice_alloc0 g_slice_free1 g_slist_delete_link g_slist_find g_slist_foreach g_slist_free g_slist_nth_data g_slist_prepend g_slist_remove g_slist_reverse g_snprintf g_source_remove g_str_equal g_str_has_prefix g_str_has_suffix g_str_hash g_strcmp0 g_strconcat g_strdup g_strdup_printf g_string_append g_string_append_printf g_string_free g_string_insert_c g_string_sized_new g_strndup g_strstr_len g_strv_get_type g_thread_init g_timeout_add g_timeout_add_full g_timeout_add_seconds g_type_add_interface_static g_type_check_instance_cast g_type_check_instance_is_a g_type_class_add_private g_type_class_peek_parent g_t
need code for decoding cell broadcast SMS messages
I am looking for some code that can decode cell broadcast SMS messages, anyone know of any? ofono has some but its too hard to separate from ofono itself. Regular SMS decoders wont work as the cell broadcast SMS message format is different. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Is it possible to dump packets sent between the AP and cell modem?
I want to dump the isi/phonet packets being sent between the cellular modem and the AP so I can see the low level packet being sent for Cell Broadcast SMS and see just what data is being sent (and figure out if the issue is a bug in my code, a bug in the nokia telephony stack or an issue with what my carrier is sending as cell broadcast) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Progress on Cell Broadcast, testing and help needed
http://www.cncmods.net/files/cbs.zip contains a test app I wrote (plus its code) Its job is simply to connect to the IncomingCBS dbus signal and dump the arguments to the signal to disk as binary in /var/log/cbsms.log The information in this test was found by finding the function in libsms.so that handles SMS_GSM_CB_ROUTING_NTF and (using the www.wirelessmodemapi.com docs) matching the members of the tSMS_SubGSMCBMessage structure through the code in libcsd-sms.so to the dbus arguments. When I run it on my phone (phone being set to 2G) I can see the IncomingCBS signal appearing in dbus-monitor and I can see data going into the cbsms.log but I cant see usefull data in there (i.e. no actual message). I know on my old 2G-only phone I used to get proper CBSMS messages with a cell tower name in them so I dont know whats up. What I need is for people who know their N900 is receiving cell broadcast messages to try this on their own phone and see if they get usable data (e.g. examine the cbsms.log file with a hex editor) and also for people to look at my code and see if they can identify anything wrong (or otherwise play with it) Once we get this test app properly dumping cell broadcast messages and producing correct output, building a GUI to actually display this stuff is (hopefully) the easy part (we might need some of the connectivity UI stuff like flightmode though if we want to do things properly and cleanly) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Nokia and MS
Added to the promise of the CSSU, and related efforts, as well as the increasing potential freedom both from reverse engineered bits, as well as documentation that should have been found ages ago, but for various reasons hasn't been - and code 'newly' released for meego - the platform could be an interesting one for hackers for some time to come. What reverse engineered bits and what documentation are you referring to? And what code is released for MeeGo? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Cellmo-headers and Cellmo-icpr82-headers packages...
Anyone know what happened to these packages or where I can get them? Since they were specifically for Fremantle, they are likely to be exactly matched to the N900 cell modem (something which the docs on www.wirelessmodemapi.com dont appear to be for the GPS stuff at least) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
help with listening to DBUS signals (it relates to Cell Broadcast SMS)
I have confirmed with dbus-monitor that my N900 (in 2G mode) is in fact triggering the IncomingCBS dbus signal. What I want to do now is to wire up that signal and dump its parameters so we can reverse engineer what those parameters are and write a GUI to do something with the results. I have identified that the csd-sms plugin is making the following calls dbus_message_new_signal("/com/nokia/phone/SMS","Phone.SMS","IncomingCBS") dbus_message_append_args(blah) dbus_message_unref() Also, dbus-monitor says this signal sender=:1.19 -> dest=(null destination) serial=550 path=/com/nokia/phone/SMS; interface=Phone.SMS; member=IncomingCBS The parameters that the IncomingCBS call seems to take are array of bytes uint32 uint32 byte byte byte I have been following various dbus examples (including dbus-monitor source) and am confused as to how to listen to a signal and what values to pass to listen for this signal and only this signal. Can someone point me to an example out there (using either lowlevel or glib binding) and some info on how I would listen to this signal? If we can figure out how to listen to this signal and what the arguments mean, writing something to display the results shouldn't be that hard :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
some more dev questions related to my libicd_policy_home_network.so project
1.What is the best place to store configuration information on the N900? And where can I find documentation and examples of storing such configuration information for my plugin? (in this case I will have a control panel plugin which sets a value and the ICD policy plugin retrieves it) 2.Is there an example of how to produce a control panel plugin? and 3.Is there an example of how to produce a dialog box and drop-down list similar to the dialog box that lists all the different available internet connections? I need to know how to create the dialog, how to set its title, how to create the dropdown list, how to add buttons to the dropdown list and how to respond to button presses/item selections (and then how to close the dialog after doing what I need with the button press) I also need to match a piece of data with each button/list item and to retrieve that data when the button is pressed. With so much of the UI of the N900 closed, its hard to know where to look to find suitable code examples for UI work. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Looking for someone who can run a test for me
I am looking for someone who has access to (i.e. can connect to and join with his N900) 2 different wireless networks. One of the networks must be one that you can enable and disable. You will not be using any actual data during this test (other than what your phone may use for other reasons) What I need done is this: 1.Download the code from here http://code.google.com/p/icd-policy/source/browse/#svn%2Ftrunk 2.Compile it (you will need icd2-dev package installed). It will produce a libicd_policy_log.so file. 3.Copy the libicd_policy_log.so file to your phone in /usr/lib/icd2 4.Run gconftool-2 -s -t list --list-type string /system/osso/connectivity/policy/modules [libicd_policy_log.so,libicd_policy_merge.so,libicd_policy_ask.so,libicd_policy_any.so,libicd_policy_change.so,libicd_policy_add.so,libicd_policy_always_online.so,libicd_policy_one.so,libicd_policy_restart.so,libicd_policy_nw_disconnect.so] 5.Connect to the wireless network you have control over 6.Run /etc/init.d/icd2 restart to load the new plugin 7.Switch off the wireless network you have control over (make a note of what network the phone switches to, the other wireless network or the cellular data) 7a.If it switched to the cellular data, switch to the second wireless network via the UI. 8.Switch the wireless network you switched off back on (does it reconnect to the wireless network that just reappeared or stay on the other wireless network) 9.On your phone, choose the other wireless network and connect to it 10.Move out of range of both wireless networks (your phone should switch straight from network #2 to the cellular data connection) 11.Move into range of the wireless networks (and make a note of which network it connects to) 12.Having done that, run gconftool-2 -s -t list --list-type string /system/osso/connectivity/policy/modules [libicd_policy_merge.so,libicd_policy_ask.so,libicd_policy_any.so,libicd_policy_change.so,libicd_policy_add.so,libicd_policy_always_online.so,libicd_policy_one.so,libicd_policy_restart.so,libicd_policy_nw_disconnect.so] 13.Run /etc/init.d/icd2 restart 14.Copy the /var/log/icdpolicy.log file from your phone. 15.You may now delete /var/log/icdpolicy.log and /usr/lib/icd2/libicd_policy_log.so What I am looking for is details of the steps you took (e.g. connected to network #1, turned network #1 off, turned network #1 back on), what network the phone switched to at these points and the contents of the /var/log/icdpolicy.log file. If you are concerned about personal information, you can study the source code in policy_log.c and you can obfuscate any names (network names, cellular carrier names etc) that you dont feel comfortable sharing. I just need to know the sequence of events, not actual names. This information will help me produce what I am calling libicd_policy_wlan_home.so which will (if I can make it work the way I want to) always connect to a "home" wireless network when that network comes in range, regardless of if its connected to a different wireless network. I am unable to do this test as I only have the one wireless network that I have access to. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Some dev questions related to my icd2 policy plugin work
Firstly, can anyone tell me the right way to edit gconf settings not exposed by the UI? Specifically there are settings in /etc/gconf/gconf.xml.defaults/schemas/system/osso/connectivity/policy/%gconf.xml and /usr/share/icd2-settings-default/icd2-settings.xml that pertain to the ICD policy plugins, how can I edit those to make ICD load my new plugin (and whats the best way to make the ICD policy plugin restart itself so it can load the plugin?) Secondly, are there any particular compile/link options I should be using when I build the shared library in order for it to work properly on the N900? Any tips for trying to figure out what compile/link options Nokia may have used? Anything else I should know before I attempt to write this plugin and run it on my precious N900? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: idea to get Cell Broadcast SMS working for Fremantle on the N900 - help wanted
To follow up on this, it looks like the csd-sms plugin for the csd daemon exports something over dbus on com.nokia.phone.SMS /com/nokia/phone/SMS On this dbus thing is an interface called Phone.SMS On this interface is a signal called IncomingCBS This seems to pass in the following arguments: array of bytes uint32 uint32 byte byte byte All the code inside sms-csd, libsms and libisi seems to be there We need someone who knows more about dbus who can play with this signal (or maybe someone with a contact at Nokia who can find out some info on this signal) and then once we verify the signal, someone just has to write a GUI for Cell Broadcast. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Information about ICD2 policy plugins discovered
http://wiki.maemo.org/ICD_Policy_Plugins This should mean people can have more control over how icd2 manages networks (e.g. how it chooses which network to connect to at any given time) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
syslog on maemo/n900
I installed sysklogd with apt-get and I added what I thought was the right line in /etc/syslog.conf (*.notice /var/log/syslog) but its not recording messages sent with log level "notice" (like the log messages from the SMS code). Can someone tell me what I am doing wrong? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
idea to get Cell Broadcast SMS working for Fremantle on the N900 - help wanted
The MeeGo ofono code here: http://meego.gitorious.org/meego-cellular/ofono contains a driver for the isi modem (as used in the n900) and a plugin called n900.c. Both appear to have been written by nokia employees. This code contains support for Cell Broadcast SMS (something the N900 running Maemo does not support). Cell Broadcast SMS is where cell towers broadcast messages to all phones in range. Its used for a number of things but the most common use is that a number of operators use it to broadcast a cell tower ID of some kind. This may be the name of the tower (e.g. the suburb the tower is in or the name of the special location like a major shopping center, airport, train station or sports field) or it may be a postcode for the tower or a set of coordinates. Many phones (including quite a few cheaper Nokias I have seen as well as my previous Motorola Z6) support Cell Broadcast SMS and can display the tower ID on the screen. I wish to attempt to send the same Cell Broadcast SMS commands as ofono does to see if its possible to write some code for Maemo/Fremantle that handles Cell Broadcast SMS (for example, a libcbsms and then a cbsms-applet to actually display the info) but I cant figure out how to send isi/phonet commands on the N900 inside Maemo. Does anyone know how to send these commands or have any other ideas on how we can try the ofono code on Maemo/Fremantle to see if its possible to build Cell Broadcast SMS support into Maemo/Fremantle without replacing the entire telephony stack and all the user space telephony apps that depend on it (dialer, SMS etc) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers