Re: [CSSU] how to include rewrites of closed blobs
thanks Andrew, for clarification :-D 100% agree. I just like to add we already have some apps that are no rewrites but clearly depend on CSSU (orientation lock applet, CSSU-tweaker...) and thus also should live in that repo CSSU-extras (or whatever path we choose to implement the concept) cheers jOERG (IRC: DocScrutinizer) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problem with three keys pressed
see http://wiki.maemo.org/N900_Hardware_Subsystems#Keyboard where I elaborated about the problem, though only regarding qualifier keys (Fn, Shift, Ctrl) /j ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: more Cell Broadcast SMS code
>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) I will marry it with the flawed busybox script earlier in that thread. It works for catching errors quite nicely, not though for the core part of patching which is domain of your code. :-) I'll also look into packaging etc, when I find the time to do. /j ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [CSSU] Advice wanted on the best way to package Cell Broadcast SMS bugfix for closed libsms library
bash-3.2$ python ./smscb.py Sun Jun 26 13:33:02 2011 New cell broadcast message received from channel 221 Message: 364883548122 Sun Jun 26 13:35:18 2011 New cell broadcast message received from channel 221 Message: 364977548097 Sun Jun 26 13:36:03 2011 New cell broadcast message received from channel 221 Message: 364883548122 Sun Jun 26 13:37:17 2011 New cell broadcast message received from channel 221 Message: 364977548097 Sun Jun 26 13:38:04 2011 New cell broadcast message received from channel 221 Message: 364883548122 Sun Jun 26 13:39:47 2011 New cell broadcast message received from channel 221 Message: 364977548097 Sun Jun 26 13:40:32 2011 New cell broadcast message received from channel 221 Message: 364883548122 #ok, now moving device somewhere else Sun Jun 26 13:43:03 2011 New cell broadcast message received from channel 221 Message: 364883548122 #doublette, shouldn't happen? ^CTraceback (most recent call last): File "./smscb.py", line 101, in listen() File "./smscb.py", line 69, in listen gobject.MainLoop().run() KeyboardInterrupt bash-3.2$ python ./smscb.py #added a typo fix Sun Jun 26 13:53:47 2011 New cell broadcast message received from channel 221 Message: 364977548097 think we got it jonwil said he want's to pick up on posting/publishing a proper c binary to patch the 3 bytes in libsms.so. I give up on messing with crippled messybox, rather adding bit of icing to the python code that created the above, and ship that here cheers jOERG ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [CSSU] Advice wanted on the best way to package Cell Broadcast SMS bugfix for closed libsms library
meanwhile: bash-3.2$ id uid=2(user) gid=2(users) bash-3.2$ dbus-monitor --system | grep -A 90 "member=IncomingCBS" signal sender=:1.21 -> dest=(null destination) serial=344 path=/com/nokia/phone/SMS; interface=Phone.SMS; member=IncomingCBS array [ byte 51 byte 27 byte 13 byte 135 byte 155 byte 213 byte 104 byte 184 byte 152 byte 76 byte 214 byte 104 byte 52 byte 26 byte 141 byte 70 byte 163 byte 209 byte 104 byte 52 byte 26 byte 141 byte 70 byte 163 byte 209 byte 104 byte 52 byte 26 byte 141 byte 70 byte 163 byte 209 byte 104 byte 52 byte 26 byte 141 byte 70
Re: [CSSU] Advice wanted on the best way to package Cell Broadcast SMS bugfix for closed libsms library
don't bother to try to get this version of patcher script running, it has several flaws on stock maemo (busybox etc). I may or may not ship a better version later. sorry for the noise till then. /j ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [CSSU] Advice wanted on the best way to package Cell Broadcast SMS bugfix for closed libsms library
#!/bin/sh
# Hi Jon
#attached find a little script to do the patching.
#I suggest to package this script together with whatever GUI(?) SMSCB app,
#and run in from postinst. Then up the pkg to extras-devel. If you prefer, I
#can do the packaging and upload to extras-devel repo.
#cheers
#jOERG
#--- 8X -- (snip)
#!/bin/sh
# file: /usr/local/bin/patch-libsms
# perm: chmod +x /usr/local/bin/patch-libsms
#
# USAGE:
# ~# patch-libsms
# (needs root permisions)
#
# this script will patch the libsms.so library to fix a bug, so N900
# finally could receive cell broadcast SMS
# There'll be a backup of the original file so you can revert if the
# results are not satisfactory
#
# see http://lists.maemo.org/pipermail/maemo-developers/2011-June/028434.html
# All kudos to Jonathan Wilson for digging into this and finally find the
patch
#
# Alas xargs -Ixx printf is *really* too slow, and -I not supported by busybox
# busybox awk doesn't support gsub function :-/
# so you have to install *something* anyway, either a binary to patch, or a
# interpreter like perl to run a proper script,
# or you get proper awk from gawk package in SDK repo:
# IroN900:~# apt-cache policy gawk
# gawk:
# Installed: 1:3.1.4-2osso.2
# Candidate: 1:3.1.4-2osso.2
# Version table:
# *** 1:3.1.4-2osso.2 0
# 500 http://repository.maemo.org fremantle/sdk/free Packages
# 100 /var/lib/dpkg/status
# IroN900:~# apt-get install gawk
#
# (C)Joerg Reisenweber, joerg add openmoko dodd org, GPLv2
# thanks to Paul ;-)
LOG=/home/user/MyDocs/.documents/$( basename $0).log
LIBSMS=/usr/lib/libsms.so.0.0.0
BACKUP=/home/user/$(basename $LIBSMS)
MD5ORIG=6d9560f64f97dd18ccbd3119229717ae
MD5PATCHED=fff53e239c8a46c97015a8ef78f9e7ad
#set -vx
dd if=/dev/zero of=$LOG bs=2k count=1 2>/dev/null || (echo "Can not create
logfile $LOG, exiting!"; exit 5)
trap "cleanup" exit
cleanup(){
trap - exit
if [ -f $LOG ]
then
#exec
echo -e "An Error occured! Please keep the logfile $LOG, and provide it to
developers for analyzing what happend\nThe logfile:" >&3
cat $LOG >&3
fi
exit
}
exec 3>&2 1>$LOG 2>&1
set -e
echo "checking $LIBSMS for correct MD5 checksum, so we can apply patch..."
echo "$MD5ORIG $LIBSMS" | md5sum -c
echo "creating backup of $LIBSMS to $BACKUP..."
cp -va $LIBSMS $BACKUP
# 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)
echo "patching $LIBSMS..."
od -Ax -tx1 -w1 -v $LIBSMS | awk '/00dd78 ff/ { $0 = "00dd78 52"} /00dd7c 00/
{ $0 = "00dd7c 52"} /00dd7f 03/ { $0 = "00dd7f c3"} { gsub(/^.* /, "0x");
printf "%c", strtonum($0) }'
echo "checking result for correctness..."
if !echo "$MD5PATCHED $LIBSMS" | md5sum -c
then
echo "result incorrect! Restoring from backup $BACKUP..."
cp -va $BACKUP $LIBSMS
echo "removing backup..."
rm $BACKUP
echo " system info ==="
osso-product-info
exit 5
fi
rm $LOG
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [CSSU] Advice wanted on the best way to package Cell Broadcast SMS bugfix for closed libsms library
I forgot: IroN900:~# md5sum /usr/lib/libsms.so.0.0.0 6d9560f64f97dd18ccbd3119229717ae /usr/lib/libsms.so.0.0.0 Please tell which version (of combined fiasco image) you got installed, this above should be International. Also you maybe can give a context hexdump of byte DD78 -30bytes to +30bytes, so I could find the code in case it has just moved a bit Thanks /j ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [CSSU] Advice wanted on the best way to package Cell Broadcast SMS bugfix for closed libsms library
Jon, I have some binary patcher ready here, alas I can't reproduce your patch, as the values of bytes to patch differ massively from your instruction PR1.3 CSSU system: IroN900:~# ls -l `find /usr -name '*libsms*'` lrwxrwxrwx 1 root root15 2010-06-23 06:08 /usr/lib/libsms.so.0 -> libsms.so.0.0.0 -rw-r--r-- 1 root root 79964 2009-12-15 14:41 /usr/lib/libsms.so.0.0.0 lrwxrwxrwx 1 root root21 2010-06-23 06:07 /usr/lib/libsms-utils.so.0 -> libsms-utils.so.0.0.0 -rw-r--r-- 1 root root 42932 2009-12-16 11:31 /usr/lib/libsms-utils.so.0.0.0 -rw-r--r-- 1 root root 7836 2010-02-04 10:50 /usr/lib/rtcom- eventlogger/plugins/libsms.so /j ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is it possible to dump packets sent between the AP and cell modem?
http://forums.internettablettalk.com/showthread.php?p=1027338#post1027338 http://maemo.cloud-7.de/wireshark1.4.4_ISI sorry for being late in here /j ___ 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
awesome work, many thanks! This should go to cssu probably, at least judging by definition of cssu's purpose which is "fixing things that are part of fremantle-mp" Nevertheless we also could get a simple app package that does all the needed binary patching. Ugly but would work. 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 cheers jOERG ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 GPS - RTCM / DGPS?
N900 GPS is connected to BB5 modem chip, and access is via ISI/Phonet. So I'd guess there's very little chances to get this DGPS thing working on N900. See http://wiki.maemo.org/N900_Hardware_GPS /j ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: USB host mode on N900 (was Re: N900 usb host + power charge)
[Paul Fertser Di 8. Dezember 2009]: > Hi, > > On Mon, 21 Sep 2009 00:01:41 +0300, Igor Stoppa wrote: > > On Sun, 2009-09-20 at 22:56 +0200, ext Kees Jongenburger wrote: > > > On Sun, Sep 20, 2009 at 9:02 PM, Igor Stoppa wrote: > > > > Add to that several HW bugs that were discovered during the > > > > development > > > > and needed workarounds. > > > > > > Does this simply mean it's not possible at all? not even for example > > > booting in HOST only mode? > > > > AFAIK no. Not even that. Note that i'm no USB expert, but if i have > > understood correctly, part of the configuration is done > > automatically by the transceiver and that cannot be done because of > > the missing line from the connector that would identify the port as > > A type. > > I'm no USB expert either but given what i already know about it, i > think more hardware information is needed to be able to give a final > verdict on the N900 usb host mode functionality. I'm not talking here > about perfectly correct standards implementation or certification > issues though i personally would prefer to have a working hostmode > implementation to having a useless usb logo on the box. > > So, a bit of theory first: > > 1. n810 analogy doesn't work here since n810 uses a dedicated usb > controller (tusb6010b) along with a power management ic (tps65030) > while n900 uses an integrated Mentor Graphics OTG controller (musb > mhdrc) and other components still unknown to the general public. > > 2. For "true" OTG operation a dedicated line should be routed from the > "ID" pin of receptable to the MUSB core. > > 3. For a device to act as a slave a "strong" 1.5k pullup should be > connected to the DP line, this way a slave signals its presence. > > 4. For a device to act as a host two 15k pulldowns should be connected > to DM and DP lines. If actual hardware lacks those, they can be easily > connected externally, along with the peripheral equipment. > > 5. MUSB has output pins to control the necessary resistors and > external circuits to provide power on Vbus. > > 6. Even in traditional usb-host <-> usb-device scenario power on the > 5V line can come from either side, one can e.g. modify a powered hub > in a way to provide power both to the host and to the peripherals, and > since host charging circuit is generally independent from the usb > controller, one most likely can use a hub like that to charge host and > to enable usage of slave devices at the same time. Probably current > musb driver doesn't support this scenario yet but it shouldn't be hard > to implement. > > 7. I can't tell for sure because MUSB "datasheet" looks like a parody > but it seems highly unlikely that it's impossible to manually switch > musb to the host mode. > > Now, the questions: > > 0. Is there any real show-stopper to use USB host mode? > > 1. Does n900 have an integrated curcuit to provide power to the > external devices over usb and if yes, what is it and how is it > connected/controlled? > > 2. Does n900 have the necessary 15k pulldowns in place? > > 3. Is it indeed the connection between the ID pin on usb receptable > and musb that is missing? It'd look strange to not route that line, > even if the hostmode/otg is not fully functional, it's only one > possibly useful line after all. > > 4. What HW bugs you mentioned are still present in the mass-produced > devices, how do they affect usb operation? > > 5. Since musb driver doesn't seem to be in a particularly good shape, > is it possible that some problems nokia engineers faced are software > issues and hence can be fixed? What were they? > > Looking forward to your reply, TIA :) > Happy hacking! It's a pity nobody ever answered those questions, as it would have saved us an Olympus Mons of troubles we had to go through, to find out about all that by ourselves, with ZERO support from Nokia. Whatever, Nokia said it's not possible, I always said it's impossible that this is not possible, so finally hostmode taskforce team [1] proudly presents: * USB HOSTMODE ON N900 * * * see https://garage.maemo.org/pipermail/h-e-n-devel/2010/35.html https://garage.maemo.org/plugins/ggit/browse.php/?p=h-e-n;a=commit;h=d7f76e505b16f7e9305c59c51d02fb1473ab5b2c [1] hostmode taskforce team mostly are the gals and guys listed as members of h-e-n.garage.maemo.org Joerg Reisenweber System Architect, Senior EE, Consultant signature.asc Description: This is a digitally signed message part. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Notification LED (blue color) in PR 1.2
[saurabh aggarwal Mi 23. Juni 2010]: > Looks like it is no longer working. I tried with the dbus command that used > to work with PR 1.1 (http://wiki.maemo.org/Phone_control#Deactivate_LEDs), > and it doesn't work. I also tried sending an IM message to the native IM > application, and even that didn't turn the blue LED on. > > Can some one confirm the break? > > -Saurabh > No, seems to work usually. Have you checked your indicator light settings in settings app? Please notice the PatternCommunicationIM blue flashing is only while screen is dim and only for IM, aiui. Also your link is to DEactivate_LEDs - probably a mishap. you could do a echo 50 > /sys/class/leds/lp5523:b/brightness to power up the blue LED permanently and see if the hardware is ok. (echo 0 to switch back off) But if you ever see a white indicator, then the blue LED is definitely ok, no need for that test. HTH /jOERG signature.asc Description: This is a digitally signed message part. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Open Letter/Proposal to allow Maemo on the MeeGo Community OBS
[David Greaves Mi 16. Juni 2010]: > > *Please discuss on meego-community mailing list* > > DocScrutinizer on irc pointed out that a url might be useful but was too shy > to post himself ;) > >http://lists.meego.com/listinfo/meego-community For your convenience, head of thread in mail archive: http://lists.meego.com/pipermail/meego-community/2010-June/001041.html /jOERG PS: I wasn't "too shy" but thought me answering to that thread could give bad example and start a concurrent discussion thread here, rather than keeping things in one list. So: Please don't post thought or comments here, but join meego ML! signature.asc Description: This is a digitally signed message part. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
[kate.alh...@nokia.com So 13. Juni 2010]: > - Original message - > For application performance and cpu usage also time needed for tile pre- > processing need to be counted. > > Does it some scaling for tiles after loading them ? > > Finally time used for scaling tiles is one key issues. Do we scale them or > download every size. How much cpu power is used for scaling or do we leave > it all for GPU ? The main concern is about scaling has to be done *only once* and NOT for every refresh of the display. Depending on how ignorant the widget is coded, you might end with a redraw() triggered for every visible tile of the map, if the map content is only shifted aside by a few pixels. Then each tile object does all the scaling again, and that's for sure not the optimum way to implement that. Displaying a minimal change of the map, quite usually this means moving the bitmap by a few pixels and adding a few new pixels to the canvas at one side, this is definitely a completely different thing than drawing a new map from scratch which should be avoided as much as possible, for obvious performance considerations. Or simply put: if you got CPU load issues on displaying a slowly and minimally changing map, then you did something terribly wrong. /j signature.asc Description: This is a digitally signed message part. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
[Till Harbaum / Lists Sa 12. Juni 2010]: > Hi, > > Am Samstag 12 Juni 2010 schrieb Ian Stirling: > > And speedups may be very possible - if for example you can offload > > portions of the workload onto a GPU. > That addresses the performance problem, but this likely also if you do this > for performance reasons, it also increases battery consumption as you > put additional load onto another component of the SOC. It's rather moot, as this isn't a movie at 25fps, so an occasional image refresh, no matter how it's done, will take magnitudes less energy per time in average, than the backlight eats to display the image. When screen is dimmed (or the widget invisible/hidden/background) then of course all gfx workload should suspend, for obvious reasons /j signature.asc Description: This is a digitally signed message part. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: /etc/init.d/ssh stop does not stop ssh on the N900
[Ajai Khattri Mi 24. März 2010]: > On Wed, 24 Mar 2010, Sivan Greenberg wrote: > > > I'd say supporting > > /etc/init.d/ssh stop is important for users that are coming from the > > pre-upstart time. > > Better get used to it - upstart has been standard on several distros for > a few years now (Ubuntu, Fedora and maybe the next Debian release). I think it doesn't matter if there's upstart or sysV-init - if I find a /etc/init.d/foo script, I expect this script to support "foo start" and "foo stop" and the other few valid options, and of course these shall work properly If the script doesn't work as everybody would expect, then it shouldn't be there at all. jOERG signature.asc Description: This is a digitally signed message part. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
