Re: qtmoko v27
Oh, that's true, i didn't paid attention to that ... It's a relief ^^ -- Gand' On Sun, Oct 3, 2010 at 2:46 PM, Ole Carlsen o...@carlsen-web.dk wrote: Den 03-10-2010 14:08, Gand' skrev: Since i moved to the v27, my touchscreen is kind of weird ... I can't draw a straight line, and when i keep the stylus on the screen, it draws a tiny star (more or less 9mm²) It makes the docked keyboard pretty unusable as when press a key, one of the surrounding key often responds ... -- Gand' That was also one of the things that Radek mentioned when releasing it: -- 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. -- As a work-around, for the keyboard, I have rotated my screen 90 degrees and now I don't hit the wrong key very often anymore. I would though prefer the possibility to personally decide the size of my keyboard. -- Ole @ Carlsen-web.dk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
Since i moved to the v27, my touchscreen is kind of weird ... I can't draw a straight line, and when i keep the stylus on the screen, it draws a tiny star (more or less 9mm²) It makes the docked keyboard pretty unusable as when press a key, one of the surrounding key often responds ... -- Gand' On Tue, Sep 28, 2010 at 11:52 AM, Patryk Benderz patryk.bend...@esp.plwrote: [cut] Also it can compare only system clock with RTC, so we always assume that system time is correct. Calypso time - do we need it at all? Maybe to correct drifting RTC? -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
Den 03-10-2010 14:08, Gand' skrev: Since i moved to the v27, my touchscreen is kind of weird ... I can't draw a straight line, and when i keep the stylus on the screen, it draws a tiny star (more or less 9mm²) It makes the docked keyboard pretty unusable as when press a key, one of the surrounding key often responds ... -- Gand' That was also one of the things that Radek mentioned when releasing it: -- 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. -- As a work-around, for the keyboard, I have rotated my screen 90 degrees and now I don't hit the wrong key very often anymore. I would though prefer the possibility to personally decide the size of my keyboard. -- Ole @ Carlsen-web.dk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27 (+ answering usability)
Le 27/09/2010 19:08, Alfa21 a écrit : 2010-09...@17:32 Thomas HOCEDEZ and go to the dial interface I can confirm this. ooh! great, you remembered to me an annoying usability issue about the answer screen: when I'm in a hurry or I'm walking sometimes I push the answer button twice due to the latency of the gui just because I've an vibrating touch... and actually I drop the incoming call :P is it possible to split the button in 2 so it's not the same area active on the screen to do both the functions? ...or just reduce the size of the button and move it from left to right accordingly to its active function of the moment? ...or substitute the button with a slide? (in this way I also do not answer while I'm grabbing it out of my poket) Yes it might be done in the Theme, I'll put it in the final release thanks for this idea ! -- Thomas HOCEDEZ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
[cut] Also it can compare only system clock with RTC, so we always assume that system time is correct. Calypso time - do we need it at all? Maybe to correct drifting RTC? -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
Le 25/09/2010 10:53, Radek Polak a écrit : 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 As usual it roxxes ! But there is always this strange bug : when you change theme, and go to the dial interface, the phone restarts (not reboot : restarts ie : gfx, modem, usb ...) For the V27, i'm preparing also a new theme. Rgds. -- Thomas HOCEDEZ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27 (+ answering usability)
2010-09...@17:32 Thomas HOCEDEZ and go to the dial interface I can confirm this. ooh! great, you remembered to me an annoying usability issue about the answer screen: when I'm in a hurry or I'm walking sometimes I push the answer button twice due to the latency of the gui just because I've an vibrating touch... and actually I drop the incoming call :P is it possible to split the button in 2 so it's not the same area active on the screen to do both the functions? ...or just reduce the size of the button and move it from left to right accordingly to its active function of the moment? ...or substitute the button with a slide? (in this way I also do not answer while I'm grabbing it out of my poket) -- ALFA21 IS PROVIDED AS IS AND WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
On 09/25/2010 10:45 PM, Timo Juhani Lindfors wrote: Alex Samorukovm...@os2.kiev.ua 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 Thanks. Also it can compare only system clock with RTC, so we always assume that system time is correct. Calypso time - do we need it at all? I think right scenario is to get ntptime (slow op), and then - RTC + system, and compare them. Not sure that system clock is really accurate :) 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? Not driver, daemon. atd from qpe. 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? It will not do circular buffer then. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
Alex Samorukov m...@os2.kiev.ua writes: With http://lindi.iki.fi/lindi/openmoko/compare-clock-sources.pl Also it can compare only system clock with RTC, so we always assume compare-clock-sources.pl compares 1) GPS to system time 2) GPS to pcf time 3) GPS to calypso time. It does not compare system time with RTC. Calypso time - do we need it at all? Probably not since it is reset so easily. It will not do circular buffer then. Log rotation should do that? ___ 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: 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 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 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
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
Alex Samorukov m...@os2.kiev.ua 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 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 m...@os2.kiev.ua 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
