Re: [QtMoko] Translate into Danish
la. den 25. 09. 2010 klokka 20.37 (+0200) skreiv Radek Polak: > Ole Carlsen wrote: > > > Hi > > Will you need an e-mail address or can you attach it here on the list? > > Hi, > sorry for delay, i was doing release and had to leave then. Anyway in the > attachment is first bunch of files for translating. Rest is in my git and i > can > send it later. > > Regard > > Radek > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community I could be interested in translating into norwegian, is it possible for me to use the same files and just send them via e-mail when they are translated? - Rune ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
Alex Samorukov writes: > Thank you for update. How did you measure this drift? Anyway, i don`t With http://lindi.iki.fi/lindi/openmoko/compare-clock-sources.pl > see that its a big issue. E.g. i have a daily alarm set, so in a worst > case (phone was in a standby mode, no calls/sms`s) i will wakeup 3 > minutes later :) If phone will wake up 3 minutes before than its also > not a problem - on a standby alarm will be setup again, so it will > just wake up 3 minutes later. Yes it's not a big issue in that scenario. I just needed more accurate alarms myself :-) > hwclock changes are not important for qtmoko, because rtc driver > controls /dev/rtc elusively (its very easy to change, but i don`t > think that it needs to be changed). Hmm, what driver is that in qtmoko btw? > Thank you, need to check. If it is - then its a serious argument > against this change. Do you know any other syslogd with in-memory > buffer? How about just using normal syslogd with tmpfs as storage? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
On 09/25/2010 09:53 PM, Timo Juhani Lindfors wrote: > > At least here the RTC drifts so fast (6 seconds per hour) that I don't > even try to keep it in sync. Instead I predict what the RTC will read > at a given time using a simple linear model. I sent a patch to add > --predict option to hwclock and upstream included it some time this > year. > > Thank you for update. How did you measure this drift? Anyway, i don`t see that its a big issue. E.g. i have a daily alarm set, so in a worst case (phone was in a standby mode, no calls/sms`s) i will wakeup 3 minutes later :) If phone will wake up 3 minutes before than its also not a problem - on a standby alarm will be setup again, so it will just wake up 3 minutes later. hwclock changes are not important for qtmoko, because rtc driver controls /dev/rtc elusively (its very easy to change, but i don`t think that it needs to be changed). > Note that busybox syslog silently truncates long lines (debian bug > #519356). > Thank you, need to check. If it is - then its a serious argument against this change. Do you know any other syslogd with in-memory buffer? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
Alex Samorukov writes: > could you please add RTC sync on every suspend to the sources? It is > *very important* to make it synced before suspend, because if they are > not in sync - phone will wake up in the wrong time. I will send you the > patch. At least here the RTC drifts so fast (6 seconds per hour) that I don't even try to keep it in sync. Instead I predict what the RTC will read at a given time using a simple linear model. I sent a patch to add --predict option to hwclock and upstream included it some time this year. > 2) Syslogd replacement with debian`s busybox. Its already works for me, > i will try to send patches tomorrow. Note that busybox syslog silently truncates long lines (debian bug #519356). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
On 09/25/2010 08:41 PM, Gennady Kupava wrote: > В Сбт, 25/09/2010 в 21:38 +0200, Alex Samorukov пишет: > > >> 2) Syslogd replacement with debian`s busybox. Its already works for me, >> i will try to send patches tomorrow. >> > Why? > I`m using memory buffer for logging and it makes my flash and NAND memory happy :) If i need persystent logging i can always do busybox logger -f > /var/log/messages Or just busybox logger > /tmp/log if you need las buffer length. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
В Сбт, 25/09/2010 в 21:38 +0200, Alex Samorukov пишет: > 2) Syslogd replacement with debian`s busybox. Its already works for me, > i will try to send patches tomorrow. Why? Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
Hi Radek, Thank you for working on the project. About alarm fixes: could you please add RTC sync on every suspend to the sources? It is *very important* to make it synced before suspend, because if they are not in sync - phone will wake up in the wrong time. I will send you the patch. Another things i`m working on: 1) GPRS/Voice fixes: fix wrong modem id processing inside NEO modem driver. Issue affecting not only GPRS but also multiply concurrent calls (using hold or conferences). If there is someone on the list familiar with Qtopia sources - please contact me, i`m not sure if i`m doing right. 2) Syslogd replacement with debian`s busybox. Its already works for me, i will try to send patches tomorrow. 3) GPRS on demand mode. I already fixed the main issue (hangup on start), but found that it works very unreliable because of 1). P.S. If someone have a cheap GTA02 (e.g. with broken LCD screen or case) then i`ll be glad to buy it - its hard to do too much experiments on every-day phone :) On 09/25/2010 10:53 AM, Radek Polak wrote: > Hi, > new experimintal qtmoko-v27 with 2.6.34 kernel is out now. You can download it > from our sourceforge page [1] > > Qtmoko is distribution based on debian+qtopia, for more info see [2][3][4]. > > Changes from latest v26 stable release: > > * New 2.6.34 kernel [5] > * GPRS fixes (Alex Samorukov and Pierre) > * Alarm fixes (Alex Samorukov) > * Using devtmpfs for faster boot and more memory > > For new kernel credits go to Gennady Kupava, Lars-Peter Clausen and > Thibaut Girka. Lars for porting to newer versions and upstreaming, Gena for > help with the power consumption bug, fixing WS problems and being nice to help > anytime, Thibaut for upstreaming and blanking fix. > > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Translate into Danish
Den 25-09-2010 20:37, Radek Polak skrev: > Ole Carlsen wrote: > >> Hi >> Will you need an e-mail address or can you attach it here on the list? > > Hi, > sorry for delay, i was doing release and had to leave then. Anyway in the > attachment is first bunch of files for translating. Rest is in my git and i > can > send it later. I know about the release, just re-flashed to v27 today. :-) Thanks for the files I will have a look at it during the next week. -- Ole @ Carlsen-web.dk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Translate into Danish
Ole Carlsen wrote: > Den 24-09-2010 15:22, Radek Polak skrev: > > On Friday 24 September 2010 14:57:03 Ole Carlsen wrote: > >> Hi > >> I was thinking of translating QtMoko into Danish and went to here: > >> http://qtmoko.org/wiki/Translations but then gave up as it seems to me > >> that I need to build to be able to translate? > >> > >> There isn't a more easy way to do it?? > > > > I can handle adding new language. I can send you the translate files and > > you can translate them with linguist and send me them back. Or if you > > are familiar with git you can do it with git+linguist. > > > > Please let me know if i you are interested and if you prefer git+linguist > > or if you want to use just mail+linguist. > > > > Regards > > > > Radek > > Hi > Will you need an e-mail address or can you attach it here on the list? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Translate into Danish
Ole Carlsen wrote: > Hi > Will you need an e-mail address or can you attach it here on the list? Hi, sorry for delay, i was doing release and had to leave then. Anyway in the attachment is first bunch of files for translating. Rest is in my git and i can send it later. Regard Radek da_DK.tar.gz Description: application/compressed-tar ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
В Птн, 24/09/2010 в 15:11 +0200, Marco Trevisan (Treviño) пишет: > Some days ago I've tried to port this patch to the Openmoko kernel, > after applying it to the SHR 2.6.32 kernel (patches at [1]), I got > these results (in average): > > dbus-ping-pong test: > Ping dbus-daemon (s) kdbus (s) speedup > 500 ping 3.332.1336.2% > 5000 ping 32.59 26.09 19.9% > 5 ping313.56 176.35 43.8% > > > Adrien Bustany’s ipc-performances tool with 6 random 10 char > strings: > > dbus-daemon query (s) kdbus query (s) speedup > 102.7574.71 27.29% > Interesting, how adding FCSE will influence this dbus test? Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
>Looking at your numbers, we're talking about shaving `up to 43.8%' off >of something that's already down in the singe-digit milliseconds range >to start with: in the best case above, it goes from 6.3 ms per query >to 3.5 ms per query; in the worse cases, it goes from 6.5 ms down to >5.2 ms. In your last test with Adrien's tool, the 27.29% improvement >is from 1.7 ms to 1.2 ms. waah? dbus in kernel space? well we could really try to make the system-bus more "system" ;-) >Is D-Bus actually enough of a bottleneck in, say, the FSO or SHR designs >that we should expect to accumulate enough of these ~2-ms reductions >quickly enough for them to actually become noticeable? An improvement of >`2 ms per' can be worthwhile if it adds up quickly enough--but does it? >How long does it take, under normal operating conditions, before even >50 D-Bus calls are made (a total of 0.1 seconds of accumulated savings)? Hmm. Well, its really something making the system slower. But would the change to kdbus really make SHR/FSO that faster? ... but its worth a try... >I don't know the answers to these questions, so they're not rhetorical :) There are empiric facts needed... Indeed regards leviathan signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
Marco Trevisan "(Treviño)" writes: > > Il giorno gio, 16/09/2010 alle 17.23 +0100, Al Johnson ha scritto: > > kdbus is proof-of-concept at the moment, the idea being to reduce the > > number > > of context switches needed for each dbus message. One synthetic benchmark > > shows a 3x speed increase on the n900 but speedup in real world > > applications > > seems much more modest. > > > > http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/ > > Some days ago I've tried to port this patch to the Openmoko kernel, > after applying it to the SHR 2.6.32 kernel (patches at [1]), I got > these results (in average): > > dbus-ping-pong test: > Ping dbus-daemon (s) kdbus (s) speedup > 500 ping 3.332.1336.2% > 5000 ping 32.59 26.09 19.9% > 5 ping313.56 176.35 43.8% > > > Adrien Bustany’s ipc-performances tool with 6 random 10 char > strings: > > dbus-daemon query (s) kdbus query (s) speedup > 102.7574.71 27.29% > > So, the results are quite good, but the code is actually buggy... [...] > I guess that this system could give us a nice speedup when with many > core applications with very few sources changes. > > Comments? Looking at your numbers, we're talking about shaving `up to 43.8%' off of something that's already down in the singe-digit milliseconds range to start with: in the best case above, it goes from 6.3 ms per query to 3.5 ms per query; in the worse cases, it goes from 6.5 ms down to 5.2 ms. In your last test with Adrien's tool, the 27.29% improvement is from 1.7 ms to 1.2 ms. Is D-Bus actually enough of a bottleneck in, say, the FSO or SHR designs that we should expect to accumulate enough of these ~2-ms reductions quickly enough for them to actually become noticeable? An improvement of `2 ms per' can be worthwhile if it adds up quickly enough--but does it? How long does it take, under normal operating conditions, before even 50 D-Bus calls are made (a total of 0.1 seconds of accumulated savings)? I don't know the answers to these questions, so they're not rhetorical :) -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr." ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
Hi, Radek. > I have been testing 2.6.34 kernel for one week now and to me it looks ok. > There can be issues with SD card [6], > [6] http://www.shr-project.org/trac/ticket/1143 About this issue: here, recompiling shr-2.6.32 kernel, i can reproduce problems with sd-card. For example i have to recheck my xfs filesystem after _each_ time i mount it with shr's kernel. Contrary to this, my .34 which is very close to your version, never had any problems with sd card - boot from sd, mounting my xfses, suspending and powering down/up cycle is perfectly ok for last several months (from point of view of sd card). My wild guess that SHR's sd-card problems somehow related to kms changes. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Translate into Danish
Den 24-09-2010 15:22, Radek Polak skrev: > On Friday 24 September 2010 14:57:03 Ole Carlsen wrote: > >> Hi >> I was thinking of translating QtMoko into Danish and went to here: >> http://qtmoko.org/wiki/Translations but then gave up as it seems to me >> that I need to build to be able to translate? >> >> There isn't a more easy way to do it?? > > I can handle adding new language. I can send you the translate files and you > can translate them with linguist and send me them back. Or if you are familiar > with git you can do it with git+linguist. > > Please let me know if i you are interested and if you prefer git+linguist or > if you want to use just mail+linguist. > > Regards > > Radek Hi Will you need an e-mail address or can you attach it here on the list? -- Ole @ Carlsen-web.dk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
qtmoko v27
Hi, new experimintal qtmoko-v27 with 2.6.34 kernel is out now. You can download it from our sourceforge page [1] Qtmoko is distribution based on debian+qtopia, for more info see [2][3][4]. Changes from latest v26 stable release: * New 2.6.34 kernel [5] * GPRS fixes (Alex Samorukov and Pierre) * Alarm fixes (Alex Samorukov) * Using devtmpfs for faster boot and more memory For new kernel credits go to Gennady Kupava, Lars-Peter Clausen and Thibaut Girka. Lars for porting to newer versions and upstreaming, Gena for help with the power consumption bug, fixing WS problems and being nice to help anytime, Thibaut for upstreaming and blanking fix. I have been testing 2.6.34 kernel for one week now and to me it looks ok. There can be issues with SD card [6], the touchscreen driver is missing filtering so it's a bit jittery and i think accelerometers are somehow strange now. Please report if you find any other regressions against 2.6.29. Otherwise i will probably switch to 2.6.34 as stable kernel in next releases. As for GPRS - it should work again and a bit better. However we still probably need better multiplexing - plan is to use kernel gsm multiplexer. Alarm now uses RTC_WKALM and instead of deprecated RTC_ALM and we no longer build with BROKEN_RTC_ALARM which could cause random wakeup at night. In the end i have decided to use devtmpfs as default /dev manager. You can easily switch back to udev by just apt-get install udev. I hope i havent missed anything. Please report mainly regressions again v26 version. For me this version is good enough for daily use - i hope same will be for you. Regards Radek [1] https://sourceforge.net/projects/qtmoko/files/Experimental/ [2] http://qtmoko.org/ [3] http://activationrecord.net/radekp/qtmoko/ [4] http://github.com/radekp [5] http://github.com/radekp/linux-2.6/tree/qtmoko-v27 [6] http://www.shr-project.org/trac/ticket/1143 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] [SHR-T] ffalarms
Jeffrey Ratcliffe writes: > 2010/9/20 Łukasz Pankowski : >>> Are you saying that if I want to schedule new alarms, at say, 6.00, >>> 6.05, and 6.10, then I should create 6.00, quit and restart ffalarms, >>> create 6.05, etc..? >> >> No, only if you set two alarms at 6.00 they both start at 6.00 and my >> schedule the next alarms two times. > > I've never done that. I do edit the alarms quite a bit, though - > mostly just changing the day. > > Whatever caused it, I am now seeing about 30 duplicates. To fix > things, should I just delete the duplicate scripts in /var/spool/at? > or is there a better way? Fixed in ffalarms git repository, should be soon in SHR-U, do not know when it hits SHR-T. Regards, Łukasz > > Regards > > Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[Om2008.9] log of in/out SMS and calls
Hello, Is there some log file of send/received SMS and calls in the FR in release [Om2008.9]? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
