Re: [2008.12] Make the sound setting permanent
On Wed, Dec 24, 2008 at 09:32:57AM +0100, julien cubizolles wrote: Hi, I've switched to Om2008.12 yesterday and really enjoyed it. I'm suggesting an improvement to the volume bar during calls. Could the last setting be recalled on the next call. So far, I've always needed to set it to max and it's not very convenient when you don't use a headset. Also, what alsa setting does it change ? Refer to http://docs.openmoko.org/trac/ticket/1489 and http://git.openmoko.org/?p=qtopia.git;a=commit;h=eb855af76018bedf6a89b9ac736d2ffa3961932b It doesn't change alsa, but uses AT+CLVL instead. Btw couldn't this volume bar be adjusted by the AUX button (you don't really need to lock/unlock during a call). It would be more convenient in my opinion : you don't need to put down the handset to ajust it. Thanks for the good work, Julien. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.12 illume theme
try disable qtopia under /etc/X11/Xsession.d first, restart X, finish the config, move qtopia back... - John On Fri, Dec 19, 2008 at 03:45:09PM +0200, Timo Jyrinki wrote: ... yes, you maybe need some trys to get there without a segfault :) I get the segfault directly at startup no matter how many times I try. Is there any way to do the engine change somehow when the asu theme is running or via ssh? -Timo ___ 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: WSOD
On Wed, Dec 17, 2008 at 07:57:17PM +, Andy Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | http://downloads.openmoko.org/daily/testing/openmoko-testing-om-gta02.rootfs.jffs2 | http://downloads.openmoko.org/daily/testing/testing-om-gta02-20081216.uImage.bin | | booted it up and within 5-10 suspend/resume cycles i got the wsod | again. should these images have the fix? if not, can someone point | me to a kernel/rootfs that doesn't wsod? I can't tell from the filename if they should have it or not. But, I can tell from the filename of this package that it should have it. http://downloads.openmoko.org/repository/testing/om-gta02/kernel-2.6.24_2.6.24+gitr76014+fb42ce6724576fc173faf8abfb04aa2c36d213b7-r2.01_om-gta02.opk John, maybe you can clarify the situation with the other path (and maybe change it to have a git hash). The filenames under daily/testing is as it is now because Sean specifically requested these to be 'simplified' many times in the past. Not sure if Ray wants to change it again. The versions of the kernel packages in the system could be obtained by opkg list_installed | grep kernel I think it would help to clarify the situation. - John - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklJWZ0ACgkQOjLpvpq7dMp0VQCfVxId2dAzx9XxgQfd7GnapaHW h0cAn1YOwxA34xbNLDgWNnwmpBBD9mdW =vqJO -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM daily testing image
that's exactly the problem... http://wiki.openmoko.org/wiki/Om2008.8#Known_Issues check QPE high cpu usage reboot after you made the change. - John On Tue, Dec 16, 2008 at 03:49:04PM +0100, Giorgio Marci wrote: Yes i have an SD card installed and in it is installed QTExtended 4.4.2 distribution! (kernel in the primary vfat partition and the rootfs in the secondary ext3 partition). why should be a problem? - Original Message - From: John Lee To: Giorgio Marci Subject: Re: OM daily testing image Date: Tue, 16 Dec 2008 21:08:16 +0800 wild guess: do you have a sd card installed? what is in it? - John On Tue, Dec 16, 2008 at 01:41:38PM +0100, Giorgio Marci wrote: Yesterday i had installed the daily testing release 20081215 (jffs and kernel) and its was nice, i was able to make and receive call, send and receive messages and other stuff but the suspend didn't work!! if the phone goes to suspend mode, it never wake up and i have to remove the battery! I think this is a kernel issue. How could i resolve? maybe in the today daily testing kernel image the problem has fixed..or could i use any stable kernel without problem? thanks -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com ___ 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
Notes about the current testing image
Dear community, Here is the note I kept about the current testing image. Part of it was already in the status update I sent before. I modified a bit to match the current situation and put it here so it could be archived. Please remember that since it's not in stable repo, it is a subject to change. What I wrote here only applies to the testing image for the last couple days. Upgrade from Om2008.9 - Note: you can also flash new image in http://downloads.openmoko.org/daily/testing Note: only upgrade from a clean Om2008.9 image is tested. sed -i -e 's%Om2008.8%testing%' /etc/opkg/*.conf /etc/init.d/xserver-nodm stop screen -DR opkg update opkg -force-overwrite upgrade # please ans Y to all questions # the sshd (dropbear) will restart, so you need to reconnect and do # 'screen -DR' again opkg upgrade # just in case shutdown -r now To get the fastest boot time you also need to remove the following packages: opkg remove task-base-nfs task-base-smbfs task-base-bluetooth \ task-base-usbgadget avahi-daemon avahi-autoipd blueprobe \ usb-gadget-mode portmap exquisite exquisite-theme-freerunner \ exquisite-themes Known problems about upgrade * Dropbear restart during opkg upgrade * some obsolete packages (like kernel modules) still left in system * will purge your incompatible e config, so you might need to set stuffs like suspend time again. Known issues * usb network won't work at first boot if you flash new image (#2096) * Illume sigsegv (#1767) - make sure you use asu theme if you use software_16 engine. If you want to use illume theme, you must switch to 'software' engine via illume config (in the upper shelf) * must remove 'ro' in kernel boot parameter if you use sd boot. * Most of the http://wiki.openmoko.org/wiki/Om_2008.8#Known_Issues are still there. Changes related to the dismissed optimization team -- #1267: echo AT%N patch applied, credit of Treviño #1489: qtopia volume bar #69: boot time scripts. Some qtopia modifications as well. #1347, #2113: userspace suspend/resume Touch screen driver enhancement: see http://lists.openmoko.org/pipermail/devel/2008-October/002822.html #2031: Scroll list enhancement. There are still many todo items left on my list and some items half done, but we didn't have enough time to finish them all. Sorry. Echo No definitive software solution yet. A way to improve it is: control.4 Speaker Playback Volume in /usr/share/openmoko/scenarios/gsmhandset.state the max value is 127, 95 works best on my neo. With volume level 3 or 4 in qtopia dialer, the other side can only hear a minor trace of echo while I get good audio quality. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.testing (2008.9 upgraded) - Settings not running
Hi BillK, Your version of python-etk is correct so this doesn't seem to be related to upgrade. Can you try exposure.py -f run and paste the results just like in https://docs.openmoko.org/trac/ticket/2088 ? - John On Thu, Dec 11, 2008 at 09:36:46PM +0900, William Kenworthy wrote: Unfortunately, this doesnt fix it - Ive added to the bug report. BillK On Tue, 2008-12-09 at 09:27 +0100, Gunnar AAstrand Grimnes wrote: The problem is probably broken python-ekt bindings, the upgrade path from 2008.08 to testing is (was?) broken. See https://docs.openmoko.org/trac/ticket/2127 for a fix and more explanation. - Gunnar W.Kenworthy wrote: I am using 2008.testing (2008.9 upgraded) and the Settings app wont start - same if I run exposure.py in a terminal, and no debug is printed. A ps aux shows exposure running, but no window appears and the command line returns without printing anything. Is there a way to debug python apps and see where its going wrong? BillK ___ 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 -- William Kenworthy [EMAIL PROTECTED] Home in Perth! ___ 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
No more optimization team
Dear community, I'm writing this to inform you that the optimization team is dismissed, so there won't be weekly updates anymore. Further details and reasons behind this are inappropriate to be answered by me. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/30 ~ 12/06)
On Tue, Dec 09, 2008 at 04:52:13AM -0800, Gothnet wrote: John Lee wrote: Olv is having kernel fun now, but since it's gta03 related, you probably won't see him a lot on the public kernel list. ... OM is moving more focus to gta03 now, so my current resource for qtopia is fairly limited. I know it's important for OM to keep moving forward, but really, focusing on gta03? Already? It's been a few months since GTA02 went GA and we still don't really have a working system, focusing most effort on GTA03 now seems to be an abandonment of freerunner owners. With the software in the state it was when the 02 came out, I certainly won't be buying a 03 until OM proves it can actually make something that's a useful product rather than just a public alpha. this goes double if the alpha product is essentially left for dead without ever being fully working. I shouldn't say gta03, I should say the next generation software we are going to use. Since people will switch to that software with their freerunner (gta02), it makes more sense to put more resource to work on that. My writing wasn't accurate enough. Sorry about that. - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/30 ~ 12/06)
On Mon, Dec 08, 2008 at 12:16:03PM +0100, Xavier Bestel wrote: On Sun, 2008-12-07 at 11:24 -0800, Christoph Siegenthaler wrote: I've been testing todays openmoko-testing-om-gta02.rootfs.jffs2 together with testing-om-gta02-20081207.uImage.bin after following the ML without actually flashing my freerunner a lot (for a few weeks). BTW I just tested these images too, and I have no wifi (i.e. the settings allow to turn on GPS and Bluetooth, buth there's no more a WIFI entry). Is that expected ? Xav yes. please refer to https://docs.openmoko.org/trac/ticket/2003 - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Optimization team update (11/30 ~ 12/06)
Dear Community, Team status update: As in http://lists.openmoko.org/pipermail/community/2008-December/036792.html (send/receive files via bluetooth in NEO), Erin keeps working on bluetooth. Jeremy fixed some qtopia and location bugs, and will continue learning more about kernel. The GTK redraw problem is fixed now (#1946) so Julian will be back to help with the Paroli edje files and keeps working on python. Olv is having kernel fun now, but since it's gta03 related, you probably won't see him a lot on the public kernel list. Tick mostly worked on opkg this week. Basically there are two big issues: * Incorrect behavior: as Tick indicated on devel list, there are still some logical error in opkg, which caused some problems during upgrade. That's why I have to use the -force-overwrite option in my previous upgrade howto. * Efficiency: opkg is obviously not very efficient, both in memory and in speed. Maybe we could expect another opkg release soon. Qtopia: OM is moving more focus to gta03 now, so my current resource for qtopia is fairly limited. Currently the things I want to fix most are: * UCSD problem * Window focus (soft menu disappear, problems when multiple sms come in, etc.) * Partial import of sim contacts. Please suggest if anything missing and I'll arrange my priorities. There are several good things worth mentioning last week: * The infamous WSOD (#1841) seems to be solved. It's already in testing repo. Praise for all helped in this! * GTK redraw problem (#1946) solved along with similar problem in qt with an illume patch. Thanks, Raster! p.s. It seems my last update might have created an impression that the only way to try the testing repo is to upgrade from Om2008.9. It's not true. Another way is to flash directly from http://downloads.openmoko.org/daily/testing/ if you don't mind reflash the phone. another p.s. Someone in OM kindly reminds me that my post can create inappropriate impressions, because although the logic is correct, the words and tongues might be misleading. My native language is Chinese (and I'm a master of words and tongues in Chinese), so it's kind of difficult for me to enhance this. All I can do is encouraging you to go ahead and ask if anything unclear, and keep in mind I'm a Taiwanese engineer when you read this. ;) Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/30 ~ 12/06)
On Sun, Dec 07, 2008 at 11:24:40AM -0800, Christoph Siegenthaler wrote: Dear Community I've been testing todays openmoko-testing-om-gta02.rootfs.jffs2 together with testing-om-gta02-20081207.uImage.bin after following the ML without actually flashing my freerunner a lot (for a few weeks). Positive: - Boot time improved - Suspending worked fairly well - At least one sms received (the second, sent from the FR to my own number didn't work) - probably a lot more improvements What was disappointing: - Echo on calls still there - Buzzing still there - It took quite a long time before I've been able to pick up the phone when it was suspended (but I could live with that) After I switched to the illume-theme, Enlightenment SIGABRT'd all the time. Please see https://docs.openmoko.org/trac/ticket/1767 I think I should really put a warning sign somewhere when user chooses this combination... Slowly but steadily my enthusiasm for the FR is vanishing. I was at least hoping to be able to use my freerunner as a basic phone after 5 months... Best regards, Chris PS: Sorry that I didn't provide any logs. This was primarily to release steam... Yes, I do feel better now. Hans-Martin wrote: Am Sonntag, 7. Dezember 2008 17:50:14 schrieb John Lee: Dear Community, Team status update: ... * The infamous WSOD (#1841) seems to be solved. It's already in testing repo. Praise for all helped in this! I tested the whole day and you don't know how happy i am: WSOD seems to be gone :) That was a very important step getting back my 'fever' for openmoko. Now i love my Neo again :D ... Regards, John HMB ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/Optimization-team-update-%2811-30-%7E-12-06%29-tp1625647p1626131.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ 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: [OM2008.x] praise for the new testing image
On Thu, Dec 04, 2008 at 06:07:38PM +, Vasco Névoa wrote:
I also went that way and hacked the qwerty button in again (but not
the wrench - didn't know how).
However, the button is there and it reacts, but the keyboard does not appear.
Instead, it controls the appearance of the qtopia keyboard...
How do we reach the illume keyboard from this button?
* disable the qtopia keyboard
* enable the illume one if it still doesn't show up. you need to hack
eet file because wrench doesn't work.
Once wrench works this will be pretty easy though.
- John
Citando John Lee [EMAIL PROTECTED]:
On Wed, Dec 03, 2008 at 08:36:53AM -0800, Martin Benz wrote:
Read the bugreport:
https://docs.openmoko.org/trac/ticket/1767
So we have a slow illume-theme with rasters keyboard or a fast asu-theme
without an usable keyboard (especially for non-engish users)...
Maybe i'll try to hack the edj-file, did manage to get the qwerty-menu back
in the wrench, but messing around with the keyboard only gave me errors
when
running build.sh...
(See Method 2 from http://wiki.openmoko.org/wiki/Keyboard_Toggle)
cheers
Martin
actually it's quite easy to bring back the wrench and the qwerty
buttons in asu theme. it's not the real issue though.
wrench: it's a gadget to put on the illume 'shelf'. so just add it
back into the config then it will show up. something like this
(haven't tested):
Index: illume-theme-asu/config/e.src
===
--- illume-theme-asu/config/e.src (revision 4796)
+++ illume-theme-asu/config/e.src (working copy)
@@ -428,6 +428,24 @@
value resizable uchar: 0;
}
}
+ group clients list {
+group E_Config_Gadcon_Client struct {
+ value name string: configuration;
+ value id string: configuration;
+ value geom.pos int: 0;
+ value geom.size int: 32;
+ value geom.res int: 472;
+ value geom.pos_x double: 0.0;
+ value geom.pos_y double: 0.0;
+ value geom.size_w double: 0.0;
+ value geom.size_h double: 0.0;
+ value state_info.seq int: 1;
+ value state_info.flags int: 1;
+ value style string: plain;
+ value autoscroll uchar: 0;
+ value resizable uchar: 0;
+}
+ }
}
}
value font_hinting int: 0;
qwerty: enable it in the theme.
Index: illume-theme-asu/misc-data/asu/freerunner.edc
===
--- illume-theme-asu/misc-data/asu/freerunner.edc (revision 4796)
+++ illume-theme-asu/misc-data/asu/freerunner.edc (working copy)
@@ -1575,8 +1575,8 @@
type: RECT;
mouse_events: 1;
description { state: default 0.0;
-//visible: 1;
- visible: 0; // sean wants it gone. don't look at me.
+ visible: 1;
+//visible: 0; // sean wants it gone. don't look at me.
color: 0 0 0 0;
rel1 {
to_y: e.swallow.content;
@@ -1585,8 +1585,8 @@
rel2 {
to_x: kbdtext;
to_y: e.swallow.content;
-// relative: 1.0 1.0;
- relative: 0.0 1.0; // sean wants it gone. don't look at me.
+ relative: 1.0 1.0;
+// relative: 0.0 1.0; // sean wants it gone. don't look at me.
offset: -1 -1;
}
}
@@ -1595,8 +1595,8 @@
type: TEXT;
mouse_events: 0;
description { state: default 0.0;
-//visible: 1;
- visible: 0; // sean wants it gone. don't look at me.
+ visible: 1;
+//visible: 0; // sean wants it gone. don't look at me.
align: 0.0 1.0;
fixed: 1 1;
rel1 {
the real problem is, after you click on the wrench, it will show the
config menu, but click on any one of them will give you black screen.
probably black fonts on black background. I hope someone can find out
what went wrong because I don't have time to work on it.
- John
Vasco Névoa wrote:
I've been trying the illume (gray) theme with the testing image, and
it is badly broken - Enlightenment keeps crashing at random moments
for reasons unknown.
I gave up on trying to have illume's keyboard, and reverted to the
original asu (black) theme. The qtopian keyboard sucks, but at least
everything else rocks.
I find it very strange that the whole image works so solidly with the
asu theme and is so flakey with the illume theme...
Citando Vasco Névoa [EMAIL PROTECTED]:
Citando William Kenworthy [EMAIL PROTECTED]:
And also yes, I have modified 89qtopia - but it doesn't
Re: [OM2008.x] praise for the new testing image
On Thu, Dec 04, 2008 at 06:05:04PM +, Vasco Névoa wrote: Yes, that's how I get my ballance... it's the operator that automatically sends it at hangup. I confirm that the dialer exits when we try to do it upon request... I would like to know how many people need this. My resource for qtopia is very limited and I need to decide what to fix first. - John Citando Marco Trevisan (Treviño) [EMAIL PROTECTED]: Vadim, Efimov wrote: Another 2 positive points I forgot to mention: - the UCSD messages are now correctly displayed (yay, I can see my account balance!!) how? i call *102# and dialer just disappear... I figure that actually only the ones sent by operator (with no an explicit request, i.e. after a call) are working. There's an issue while placing an USSD request... -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [latest 2008.9] USB issues?
On Tue, Dec 02, 2008 at 06:34:09PM +0100, Tony Berth wrote: Dear list, I just installed the latest 2008.9 kernel and jffs2 and when I connect to a debian 4 box it doesn't get listed as a USB device. As a result, I can't establish USB networking. Am I doing something wrong here? Thanks Tony opkg will execute the postinst script during first boot, so modules won't work properly until 2nd boot. https://docs.openmoko.org/trac/ticket/2096 - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
On Wed, Dec 03, 2008 at 08:36:53AM -0800, Martin Benz wrote:
Read the bugreport:
https://docs.openmoko.org/trac/ticket/1767
So we have a slow illume-theme with rasters keyboard or a fast asu-theme
without an usable keyboard (especially for non-engish users)...
Maybe i'll try to hack the edj-file, did manage to get the qwerty-menu back
in the wrench, but messing around with the keyboard only gave me errors when
running build.sh...
(See Method 2 from http://wiki.openmoko.org/wiki/Keyboard_Toggle)
cheers
Martin
actually it's quite easy to bring back the wrench and the qwerty
buttons in asu theme. it's not the real issue though.
wrench: it's a gadget to put on the illume 'shelf'. so just add it
back into the config then it will show up. something like this
(haven't tested):
Index: illume-theme-asu/config/e.src
===
--- illume-theme-asu/config/e.src (revision 4796)
+++ illume-theme-asu/config/e.src (working copy)
@@ -428,6 +428,24 @@
value resizable uchar: 0;
}
}
+ group clients list {
+group E_Config_Gadcon_Client struct {
+ value name string: configuration;
+ value id string: configuration;
+ value geom.pos int: 0;
+ value geom.size int: 32;
+ value geom.res int: 472;
+ value geom.pos_x double: 0.0;
+ value geom.pos_y double: 0.0;
+ value geom.size_w double: 0.0;
+ value geom.size_h double: 0.0;
+ value state_info.seq int: 1;
+ value state_info.flags int: 1;
+ value style string: plain;
+ value autoscroll uchar: 0;
+ value resizable uchar: 0;
+}
+ }
}
}
value font_hinting int: 0;
qwerty: enable it in the theme.
Index: illume-theme-asu/misc-data/asu/freerunner.edc
===
--- illume-theme-asu/misc-data/asu/freerunner.edc (revision 4796)
+++ illume-theme-asu/misc-data/asu/freerunner.edc (working copy)
@@ -1575,8 +1575,8 @@
type: RECT;
mouse_events: 1;
description { state: default 0.0;
-//visible: 1;
- visible: 0; // sean wants it gone. don't look at me.
+ visible: 1;
+//visible: 0; // sean wants it gone. don't look at me.
color: 0 0 0 0;
rel1 {
to_y: e.swallow.content;
@@ -1585,8 +1585,8 @@
rel2 {
to_x: kbdtext;
to_y: e.swallow.content;
-// relative: 1.0 1.0;
- relative: 0.0 1.0; // sean wants it gone. don't look at me.
+ relative: 1.0 1.0;
+// relative: 0.0 1.0; // sean wants it gone. don't look at me.
offset: -1 -1;
}
}
@@ -1595,8 +1595,8 @@
type: TEXT;
mouse_events: 0;
description { state: default 0.0;
-//visible: 1;
- visible: 0; // sean wants it gone. don't look at me.
+ visible: 1;
+//visible: 0; // sean wants it gone. don't look at me.
align: 0.0 1.0;
fixed: 1 1;
rel1 {
the real problem is, after you click on the wrench, it will show the
config menu, but click on any one of them will give you black screen.
probably black fonts on black background. I hope someone can find out
what went wrong because I don't have time to work on it.
- John
Vasco Névoa wrote:
I've been trying the illume (gray) theme with the testing image, and
it is badly broken - Enlightenment keeps crashing at random moments
for reasons unknown.
I gave up on trying to have illume's keyboard, and reverted to the
original asu (black) theme. The qtopian keyboard sucks, but at least
everything else rocks.
I find it very strange that the whole image works so solidly with the
asu theme and is so flakey with the illume theme...
Citando Vasco Névoa [EMAIL PROTECTED]:
Citando William Kenworthy [EMAIL PROTECTED]:
And also yes, I have modified 89qtopia - but it doesn't seem to have
much of an effect :(
I found out how my illume keyboard went missing. From the wiki:
edit '/etc/enlightenment/default_profile' to use illume theme
instead of 'asu'
So, if you just want to get rid of it, replace illume with asu inside
/etc/enlightenment/default_profile ...
But if you want to keep it exclusively for the terminal, I don't know
how...
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Tue, Dec 02, 2008 at 07:50:58PM +0900, William Kenworthy wrote: On Mon, 2008-12-01 at 22:22 +0900, William Kenworthy wrote: Thanks, also I was bit too rushed. I shut down X which allowed me to Fonts and widgets are far too large on apps like pythm, tangogps and the like. ... Fixed by adding the gtkrc fix from FDOM Should I raise a bug for this - I think it is an old issue (as evidenced by the fact that FDOM has had the fix for awhile) BillK Please do since I couldn't find it in trac. Here is the diff between the old gtkrc from moko-gtk-engine and the one from FDOM: $ diff -urN gtkrc /home/john/tmp/FDOMizer/fixes/gtkrc --- gtkrc 2008-10-30 18:42:30.0 +0800 +++ /home/john/tmp/FDOMizer/fixes/gtkrc 2008-10-19 16:12:35.0 +0800 @@ -12,6 +12,12 @@ gtk-button-images = 0 gtk-menu-images = 0 gtk-icon-sizes = gtk-button=32,32:gtk-small-toolbar=48,48:gtk-large-toolbar=48,48 +gtk-font-name = Sans 4 +gtk-icon-theme-name=openmoko-standard +gtk-toolbar-icon-size = GTK_ICON_SIZE_SMALL_TOOLBAR + + + # Set the default gtk-color-scheme property gtk_color_scheme = fg_color:#fff;bg_color:#333;base_color:#aaa;text_color:#000;selected_bg_color:#ff7d00;selected_fg_color:#000 @@ -182,10 +188,10 @@ } widget *.mokosearchbutton style mokosearchbutton -include matchboxpanel -include openmoko-calculator -include openmoko-contacts -include openmoko-dialer -include openmoko-panel-plugins -include openmoko-mediaplayer +include /usr/share/themes/Moko/gtk-2.0/matchboxpanel +include /usr/share/themes/Moko/gtk-2.0/openmoko-calculator +include /usr/share/themes/Moko/gtk-2.0/openmoko-contacts +include /usr/share/themes/Moko/gtk-2.0/openmoko-dialer +include /usr/share/themes/Moko/gtk-2.0/openmoko-panel-plugins + I don't have enough knowledge to comment on it. The second section seems strange to me though, because it assumes files will be installed to /usr/share/themes/Moko/gtk-2.0/ while this should really be decided by autotools. Could someone please review it? If it's okay I'm going to apply it to svn. - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Tue, Dec 02, 2008 at 10:49:47AM +0100, Andreas Fischer wrote: John Lee wrote: On Mon, Dec 01, 2008 at 05:31:37PM +0100, Andreas Fischer wrote: Hi John, All, Just upgraded from 2008.9. Things to mention: - Boot time decreased. A lot! Thumbs up and a great Thank you for that :) - Also, startup time for applications (dialer) seems to have decreased. - As mentioned elsewhere, Enlightenment configuration was reset to not show the spanner and as the settings utility is unusable and the phone tends to suspend after 31 seconds, it is pretty unusable until one switches Enlightenment themes according to http://wiki.openmoko.org/wiki/Keyboard_Toggle (bottom of the page). sorry about the settings problem. we fixed multiple problems yesterday (see https://docs.openmoko.org/trac/ticket/2148). there was a really strange line in local.conf saying EXTENDPE = , which will cause a lot of problems. I have no idea who put that in... Ah - that would probably also explain the frequent enlightenment crashes I was going to complain about. I'll test with the new python-etk and see how it goes from there. Thanks for your answer, Andreas enlightenment crashes? sounds familiar https://docs.openmoko.org/trac/ticket/1767 I'm in a dilemma here. Either I have to put in a lot of resource to fix the software_16 engine, or I have to switch to software_x like Raster suggested and make everything slower. :( - John there used to be a wrench and qwerty button enabled theme, and now raster's illume default theme (illume-theme-illume, illume-config-illume) provides the same functionalities with a very different look. OM's theme will remain as it is like our designer wants it to be. you are free to switch between these two though, by setting it inside /etc/enlightenment/default_profile. - John - Even after disabling suspend I am having problems. In particular I am now experiencing WSoD even after screen blank (probably bug #2115: https://docs.openmoko.org/trac/ticket/2115 ). I suppose I need to disable screen blank too for now? Nevertheless, even though there are problems it's good to see progress. Keep up the good work. Regards, Andreas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Mon, Dec 01, 2008 at 10:22:28PM +0900, William Kenworthy wrote: Thanks, also I was bit too rushed. I shut down X which allowed me to stay logged in and find out that the customisations to get the spanner and keyboards had been undone - fixed them and I can now use the phone. The suspend time is fixable from the spanner so the settings isnt needed. Some of my existing apps wont start (pypennotes, ...) so they probably need upgrading. openmoocow (old version) started once out of three tries - left me at a grey screen otherwise. At one point the display died and restarted itself when I tapped a blank part of the home screen. Fonts and widgets are far too large on apps like pythm, tangogps and the like. Tried a test call - no audio :( thanks for the feedback! that sounds like #2140. have you tried to tune up the volume ? Probably need to set a profile, but need the settings app for that. BillK On Mon, 2008-12-01 at 12:51 +, Joseph Reeves wrote: I've discovered the same: https://docs.openmoko.org/trac/ticket/2148 Joseph 2008/12/1 William Kenworthy [EMAIL PROTECTED]: Loaded it up and it rebooted fine, but isnt usable. Ive lost the spanner so I cant configure it It goes to sleep automaticly after a few seconds and without the spanner I cant figure out how to disable it (I see you mention that sleep time needs to be reset - but how?). Same if I have it plugged into usb, goes to sleep while I am logged into it. The old settings icon is still present, but does nothing except spin for a few seconds and exits - tried logging in to faultfind it but - you guessed it, phone went to sleep. Its gone back to the huge icons - a real pain, again I cant see how to select the smaller ones without the spanner. Ive lost the terminal keyboard and only have the crappy ones left - unusable for anything serious, like trying to use a terminal to fix things :( I'll try an unmodified 2008.9 in a couple of days and see if my changes to make 2008.9 usable are the cause of the above. The good - gsm registered immediately, but then it went to sleep :( BillK On Sun, 2008-11-30 at 19:50 +0800, John Lee wrote: Dear Community, As Sushama (our new testing team member) indicated in http://lists.openmoko.org/pipermail/devel/2008-November/003493.html , we won't have a release in Nov. Currently the testing team is going to do a full test on the latest testing image. It has all the goodies we did and a lot of improvements over Om2008.9, so please try it and report any error you find. Upgrade howto: From Om2008.9 it's recommanded to upgrade with the following steps: sed -i -e 's%Om2008.8%testing%' /etc/opkg/*.conf /etc/init.d/xserver-nodm stop screen -DR opkg update opkg -force-overwrite upgrade # (please ans Y to all questions) # (the sshd (dropbear) will restart, so you need to reconnect and do # 'screen -DR' again) opkg upgrade shutdown -r now To get the fastest boot time you also need to remove the following packages: opkg remove task-base-nfs task-base-smbfs task-base-bluetooth \ task-base-usbgadget avahi-daemon avahi-autoipd blueprobe \ usb-gadget-mode portmap exquisite exquisite-theme-freerunner \ exquisite-themes Known issues: * GTK redraw problem * some obsolete kernel modules still left in system * must remove 'ro' in kernel boot parameter if you use sd boot. * will purge your incompatible e config, so you might need to set stuffs like suspend time again. Echo: Since there are different hw versions out there (a5, a6, a7), it's impossible to provide one alsa state file that suits all models. However, it seems you can always find appropriate values for your neo. My way is to adjust control.4 Speaker Playback Volume in /usr/share/openmoko/scenarios/gsmhandset.state the max value is 127, 95 works best on my a5. With volume level 3 or 4 in qtopia dialer, the other side can hear no echo while I get good audio quality. Team update: Tick helped to put his touchscreen improvement into stable-tracking, he will work on opkg internals next. Olv moved to look into kernel and fso. Erin will try bluetooth. Julian is working on the GTK redraw issue, please help him out. Jeremy will fix some qtopia bugs and keep working on suspend/resume issues. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- William Kenworthy [EMAIL PROTECTED] Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Mon, Dec 01, 2008 at 10:22:28PM +0900, William Kenworthy wrote: Thanks, also I was bit too rushed. I shut down X which allowed me to stay logged in and find out that the customisations to get the spanner and keyboards had been undone - fixed them and I can now use the phone. The suspend time is fixable from the spanner so the settings isnt needed. Some of my existing apps wont start (pypennotes, ...) so they probably need upgrading. openmoocow (old version) started once out of three tries - left me at a grey screen otherwise. At one point the display died and restarted itself when I tapped a blank part of the home screen. Fonts and widgets are far too large on apps like pythm, tangogps and the like. Just checking: Do you have moko-gtk-engine and moko-gtk-theme installed ? Tried a test call - no audio :( Probably need to set a profile, but need the settings app for that. BillK On Mon, 2008-12-01 at 12:51 +, Joseph Reeves wrote: I've discovered the same: https://docs.openmoko.org/trac/ticket/2148 Joseph 2008/12/1 William Kenworthy [EMAIL PROTECTED]: Loaded it up and it rebooted fine, but isnt usable. Ive lost the spanner so I cant configure it It goes to sleep automaticly after a few seconds and without the spanner I cant figure out how to disable it (I see you mention that sleep time needs to be reset - but how?). Same if I have it plugged into usb, goes to sleep while I am logged into it. The old settings icon is still present, but does nothing except spin for a few seconds and exits - tried logging in to faultfind it but - you guessed it, phone went to sleep. Its gone back to the huge icons - a real pain, again I cant see how to select the smaller ones without the spanner. Ive lost the terminal keyboard and only have the crappy ones left - unusable for anything serious, like trying to use a terminal to fix things :( I'll try an unmodified 2008.9 in a couple of days and see if my changes to make 2008.9 usable are the cause of the above. The good - gsm registered immediately, but then it went to sleep :( BillK On Sun, 2008-11-30 at 19:50 +0800, John Lee wrote: Dear Community, As Sushama (our new testing team member) indicated in http://lists.openmoko.org/pipermail/devel/2008-November/003493.html , we won't have a release in Nov. Currently the testing team is going to do a full test on the latest testing image. It has all the goodies we did and a lot of improvements over Om2008.9, so please try it and report any error you find. Upgrade howto: From Om2008.9 it's recommanded to upgrade with the following steps: sed -i -e 's%Om2008.8%testing%' /etc/opkg/*.conf /etc/init.d/xserver-nodm stop screen -DR opkg update opkg -force-overwrite upgrade # (please ans Y to all questions) # (the sshd (dropbear) will restart, so you need to reconnect and do # 'screen -DR' again) opkg upgrade shutdown -r now To get the fastest boot time you also need to remove the following packages: opkg remove task-base-nfs task-base-smbfs task-base-bluetooth \ task-base-usbgadget avahi-daemon avahi-autoipd blueprobe \ usb-gadget-mode portmap exquisite exquisite-theme-freerunner \ exquisite-themes Known issues: * GTK redraw problem * some obsolete kernel modules still left in system * must remove 'ro' in kernel boot parameter if you use sd boot. * will purge your incompatible e config, so you might need to set stuffs like suspend time again. Echo: Since there are different hw versions out there (a5, a6, a7), it's impossible to provide one alsa state file that suits all models. However, it seems you can always find appropriate values for your neo. My way is to adjust control.4 Speaker Playback Volume in /usr/share/openmoko/scenarios/gsmhandset.state the max value is 127, 95 works best on my a5. With volume level 3 or 4 in qtopia dialer, the other side can hear no echo while I get good audio quality. Team update: Tick helped to put his touchscreen improvement into stable-tracking, he will work on opkg internals next. Olv moved to look into kernel and fso. Erin will try bluetooth. Julian is working on the GTK redraw issue, please help him out. Jeremy will fix some qtopia bugs and keep working on suspend/resume issues. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- William Kenworthy [EMAIL PROTECTED] Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Mon, Dec 01, 2008 at 05:31:37PM +0100, Andreas Fischer wrote: Hi John, All, Just upgraded from 2008.9. Things to mention: - Boot time decreased. A lot! Thumbs up and a great Thank you for that :) - Also, startup time for applications (dialer) seems to have decreased. - As mentioned elsewhere, Enlightenment configuration was reset to not show the spanner and as the settings utility is unusable and the phone tends to suspend after 31 seconds, it is pretty unusable until one switches Enlightenment themes according to http://wiki.openmoko.org/wiki/Keyboard_Toggle (bottom of the page). sorry about the settings problem. we fixed multiple problems yesterday (see https://docs.openmoko.org/trac/ticket/2148). there was a really strange line in local.conf saying EXTENDPE = , which will cause a lot of problems. I have no idea who put that in... there used to be a wrench and qwerty button enabled theme, and now raster's illume default theme (illume-theme-illume, illume-config-illume) provides the same functionalities with a very different look. OM's theme will remain as it is like our designer wants it to be. you are free to switch between these two though, by setting it inside /etc/enlightenment/default_profile. - John - Even after disabling suspend I am having problems. In particular I am now experiencing WSoD even after screen blank (probably bug #2115: https://docs.openmoko.org/trac/ticket/2115 ). I suppose I need to disable screen blank too for now? Nevertheless, even though there are problems it's good to see progress. Keep up the good work. Regards, Andreas John Lee wrote: Dear Community, As Sushama (our new testing team member) indicated in http://lists.openmoko.org/pipermail/devel/2008-November/003493.html , we won't have a release in Nov. Currently the testing team is going to do a full test on the latest testing image. It has all the goodies we did and a lot of improvements over Om2008.9, so please try it and report any error you find. Upgrade howto: From Om2008.9 it's recommanded to upgrade with the following steps: sed -i -e 's%Om2008.8%testing%' /etc/opkg/*.conf /etc/init.d/xserver-nodm stop screen -DR opkg update opkg -force-overwrite upgrade # (please ans Y to all questions) # (the sshd (dropbear) will restart, so you need to reconnect and do # 'screen -DR' again) opkg upgrade shutdown -r now To get the fastest boot time you also need to remove the following packages: opkg remove task-base-nfs task-base-smbfs task-base-bluetooth \ task-base-usbgadget avahi-daemon avahi-autoipd blueprobe \ usb-gadget-mode portmap exquisite exquisite-theme-freerunner \ exquisite-themes Known issues: * GTK redraw problem * some obsolete kernel modules still left in system * must remove 'ro' in kernel boot parameter if you use sd boot. * will purge your incompatible e config, so you might need to set stuffs like suspend time again. Echo: Since there are different hw versions out there (a5, a6, a7), it's impossible to provide one alsa state file that suits all models. However, it seems you can always find appropriate values for your neo. My way is to adjust control.4 Speaker Playback Volume in /usr/share/openmoko/scenarios/gsmhandset.state the max value is 127, 95 works best on my a5. With volume level 3 or 4 in qtopia dialer, the other side can hear no echo while I get good audio quality. Team update: Tick helped to put his touchscreen improvement into stable-tracking, he will work on opkg internals next. Olv moved to look into kernel and fso. Erin will try bluetooth. Julian is working on the GTK redraw issue, please help him out. Jeremy will fix some qtopia bugs and keep working on suspend/resume issues. Regards, John ___ 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Mon, Dec 01, 2008 at 12:18:36AM +0300, Paul Fertser wrote: And why the optimization team is still trying to fix bugs in Qtopia and derivitaves? Let Nokia do their work, if they really want to. Wouldn't it be better for the optimization team to hack on FSO or at least (as they are in Taiwan, that should be easy for them) get those bloody 100uF capacitors in place to finally provide the users with a decent bass? Because people still need to use Om2008 based distro until the software release of gta03. Also, I have pointed out qtopia issues will be of lower priority before. I don't want to sound too harsh to the optimization team. I just don't see them being public enough, coordinating their efforts with the main developers (of FSO and kernel) enough, going forward enough. In the beginning of this thread I wrote we are going to become more involved with fso and kernel, but please understand what you think we should do may not be the same as what we are going to do and what we were asked to do. I'm just afraid that they are somewhat like that mythical interface design department that never publicly communicates and demands technical nonsense from the real developers. (btw, i still remember the idea of taking a screenshot before suspending, oh boy, that was a bad sign from the optimization team) Thanks for your worrying. No personal offense meant. Non taken. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Mon, Dec 01, 2008 at 09:29:48PM +, Neil Jerram wrote: 2008/11/30 John Lee [EMAIL PROTECTED]: Echo: Since there are different hw versions out there (a5, a6, a7), it's impossible to provide one alsa state file that suits all models. However, it seems you can always find appropriate values for your neo. My way is to adjust control.4 Speaker Playback Volume in /usr/share/openmoko/scenarios/gsmhandset.state the max value is 127, 95 works best on my a5. With volume level 3 or 4 in qtopia dialer, the other side can hear no echo while I get good audio quality. Apologies in advance for what may be a dumb question - but does this statement represent the conclusion of your team's work on audio issues (buzz/echo/hiss etc.)? Or is there further work ongoing? No, it's not the conclusion. We will keep working on that. I just described how I get the best out from the current sw/hw. I very much hope the latter. At the very least, I feel we need a definitive and full description from your team of what the issues are, and the best available solutions (hardware and/or software) for them. If some of those solutions are version (a5, a6, ...) dependent, then they must include precise instructions on how an Openmoko user can determine which version they have. Once that description is available, either you or someone else can turn it into some kind of code or package, so that we can all take advantage of it. Okay, I will think about this. I think the only real limitation here is we cannot ask everyone to do the soldering by him/her self, other then that, any software based solution is possible. Let me dig this deeper with the kernel and hw people. - John I know there is already a lot of google-able data on this, but in my view this is not useful even for an experienced user/programmer, as - it is all reported anecdotally and subjectively - there is simply too much of it to digest. So the detailed status needs to come from your team. I also assume (hope!) that you must have equipment specifically for detecting and measuring such audio effects, so I expect you can do a much better job of optimizing whatever needs to be optimized than all of us enthusiasts who don't have that equipment. Best wishes, Neil ___ 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
Optimization team update (11/23 ~ 11/29)
Dear Community, As Sushama (our new testing team member) indicated in http://lists.openmoko.org/pipermail/devel/2008-November/003493.html , we won't have a release in Nov. Currently the testing team is going to do a full test on the latest testing image. It has all the goodies we did and a lot of improvements over Om2008.9, so please try it and report any error you find. Upgrade howto: From Om2008.9 it's recommanded to upgrade with the following steps: sed -i -e 's%Om2008.8%testing%' /etc/opkg/*.conf /etc/init.d/xserver-nodm stop screen -DR opkg update opkg -force-overwrite upgrade # (please ans Y to all questions) # (the sshd (dropbear) will restart, so you need to reconnect and do # 'screen -DR' again) opkg upgrade shutdown -r now To get the fastest boot time you also need to remove the following packages: opkg remove task-base-nfs task-base-smbfs task-base-bluetooth \ task-base-usbgadget avahi-daemon avahi-autoipd blueprobe \ usb-gadget-mode portmap exquisite exquisite-theme-freerunner \ exquisite-themes Known issues: * GTK redraw problem * some obsolete kernel modules still left in system * must remove 'ro' in kernel boot parameter if you use sd boot. * will purge your incompatible e config, so you might need to set stuffs like suspend time again. Echo: Since there are different hw versions out there (a5, a6, a7), it's impossible to provide one alsa state file that suits all models. However, it seems you can always find appropriate values for your neo. My way is to adjust control.4 Speaker Playback Volume in /usr/share/openmoko/scenarios/gsmhandset.state the max value is 127, 95 works best on my a5. With volume level 3 or 4 in qtopia dialer, the other side can hear no echo while I get good audio quality. Team update: Tick helped to put his touchscreen improvement into stable-tracking, he will work on opkg internals next. Olv moved to look into kernel and fso. Erin will try bluetooth. Julian is working on the GTK redraw issue, please help him out. Jeremy will fix some qtopia bugs and keep working on suspend/resume issues. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Sun, Nov 30, 2008 at 10:56:47PM +0100, Fabian Henze wrote: On 30.11.2008 at 12:50:22, John Lee wrote: Since there are different hw versions out there (a5, a6, a7), it's impossible to provide one alsa state file that suits all models. Just a short question: What is a7? Can you please update the wiki article about the GTA02 revisions? -- Fabian I think it's not shipped yet, so maybe it exists only inside openmoko. I don't know about the details. - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Sun, Nov 30, 2008 at 02:16:48PM +0100, Franky Van Liedekerke wrote: On Sun, 30 Nov 2008 19:50:22 +0800 John Lee [EMAIL PROTECTED] wrote: Echo: Since there are different hw versions out there (a5, a6, a7), it's impossible to provide one alsa state file that suits all models. However, it seems you can always find appropriate values for your neo. My way is to adjust control.4 Speaker Playback Volume in /usr/share/openmoko/scenarios/gsmhandset.state the max value is 127, 95 works best on my a5. With volume level 3 or 4 in qtopia dialer, the other side can hear no echo while I get good audio quality. Does this mean the fix is only through alsa? So the fix mentioned here: http://n2.nabble.com/FSO-M4---nice-GSM-sound-tp1486414p1518726.html is not ok? Since that fix is the only real fix for my echo issues (and it seems to come from 2008.8). Franky That fix is already in testing repo, maybe over 1 month now. However even with this patch there is still chance you can hear echo. Let's say A calls B, and B is using a neo with this fix. 1. The receiver (handset speaker) is loud enough and the mic is sensitive enough, so gsm won't turn off the mic. 2. A starts speaking right after B, but gsm needs a little time to turn off mic. In either case you can still here a little echo. Much better then before, of course, but still a little. I was talking about 1. in my previous post. - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Sun, Nov 30, 2008 at 01:32:20PM +, Rui Miguel Silva Seabra wrote:
On Sun, Nov 30, 2008 at 07:50:22PM +0800, John Lee wrote:
Echo:
Since there are different hw versions out there (a5, a6, a7), it's
impossible to provide one alsa state file that suits all models.
However, it seems you can always find appropriate values for your
neo. My way is to adjust
control.4 Speaker Playback Volume in
/usr/share/openmoko/scenarios/gsmhandset.state
the max value is 127, 95 works best on my a5. With volume level 3 or
4 in qtopia dialer, the other side can hear no echo while I get good
audio quality.
This is interesting, I have an a5 and the default value of FSO M4.1a:
control.4 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 127'
iface MIXER
name 'Speaker Playback Volume'
value.0 116
value.1 116
}
Sometimes I ask people on the other side: do you hear echo? The answer
has been no.
Rui
116 was the old value I use before I updated the alsa state file from
FDOM. There was no/very little echo, but the other side always
complains they cannot hear me very well. I also feel the receiver
(handset speaker) is unnecessarily loud sometimes.
The new alsa state file uses 116, but boosts the mic path a little bit
more, so it solved the can't hear me problem while makes the echo
even easier to happen. With the new state file, 95 is the best value
for me because I can always make it louder if necessary with Tick's
volume bar in qtopia.
- John
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Sun, Nov 30, 2008 at 06:56:28PM +, Andy Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: Hi John - | * some obsolete kernel modules still left in system If we didn't do it already, the packaged kernels need to move to having /lib/modules path that is specific to the kernel device and build, similar to what the ./build script does: /lib/modules/2.6.28-GTA02_andy-tracking_d0aa5acc0be7c573-mokodev/ The branch and hash stops any conflict about module versions, and the device tag GTA02 allows multiple kernels to be installed on the same rootfs, so you can share the SD Card between GTA01 and GTA02 say, both times with SD Card boot to the right kernel. Yup, but it won't make opkg remove the unnecessary modules. It's a problem that needs to be solved in OE. | * must remove 'ro' in kernel boot parameter if you use sd boot. At the moment Qi has ro boot everywhere by default, is this restriction just a temporary workaround for something? I think it's related to Olv's new boot scripts. I have rough idea about why but this can be better explained by him. | he will work on opkg internals next. Olv moved to look into kernel | and fso. Erin will try bluetooth. Julian is working on the GTK | redraw issue, please help him out. Jeremy will fix some qtopia bugs | and keep working on suspend/resume issues. Just a thought, it can be worth Olv and Jeremy bouncing what they're planning on doing off the kernel list. For example some advice for Jeremy about suspend / resume issues would be don't waste your time doing any suspend / resume work on 2.6.24 kernel, only on | andy-tracking. Thanks for the reminder. :) - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fix no-icon for Calculator: Where to post a patch?
On Wed, Nov 26, 2008 at 05:53:00PM +0300, Alexander Chemeris wrote:
Hi,
Attached patch fixes problem with openmoko-calculator2 BitBake recipe,
which points incorrect icon location. Thus no icon were shipped with
.ipk file and no icon displayed on home screen (on FSO-M4.1).
I think this belongs to OpenEmbedded bugtracker, but probably
OM guys can get this committed into git faster?
OE will automatically find files in several dirs, one of them is
${PN}, so the bb file itself is actully correct. I have just tested
installing openmoko-calculator2 and the icon shows up alright, so you
might want to check if there is something else going wrong..
- John
--
Regards,
Alexander Chemeris.
SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
diff --git a/packages/openmoko2/openmoko-calculator2_svn.bb
b/packages/openmoko2/openmoko-calculator2_svn.bb
index 66a8707..0da838f 100644
--- a/packages/openmoko2/openmoko-calculator2_svn.bb
+++ b/packages/openmoko2/openmoko-calculator2_svn.bb
@@ -5,11 +5,11 @@ PV = 0.1.0+svnr${SRCREV}
PR = r1
inherit openmoko2
-SRC_URI += file://openmoko-calculator.png
+SRC_URI += file://${PN}/openmoko-calculator.png
do_install_append_openmoko() {
install -d ${D}/${datadir}/pixmaps/
-install ${WORKDIR}//openmoko-calculator.png
${D}/${datadir}/pixmaps/openmoko-calculator.png
+install ${WORKDIR}/${PN}/openmoko-calculator.png
${D}/${datadir}/pixmaps/openmoko-calculator.png
}
PKG_TAGS_${PN} = group::unknown alias::Om_Calculator
___
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
Optimization team update (11/16 ~ 11/22)
Dear community, Not much to say this week. Most of the work we did could be seen by querying docs.openmoko.org with keyword 'Om2008.11' and the commit logs. Overall, Olv pushed his boot time enhancements (#69), so it will be in testing repo. Tick enhanced etk scroll list (#2031) and is working on a volume issue (#1489). Jeremy fixed another suspend ticket (#2113). Erin worked on a qtopia camping problem. She will take a look at bluetooth status starting from next week. Julian helped out our designer, Will, to work on the edge files. Upgrade path is getting better but there are still some issues (#2127). We are having an internal debate regarding the release now, so there is not much I can say about this at the moment. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
On Sun, Nov 16, 2008 at 10:05:16AM +1100, Carsten Haitzler wrote: x's internals are definitely up for improvement - callium3d is there to try and fix this by providing a better more organised and better accelerated driver layer - but again - they aren't going to replace x... just clean up internals. what it means is - the rest of us can continue happily writing x apps and just wait for an improvement to pop out the pipeline. indeed x's internal acceleration layer could be improved. it has in the past (especially with xaa) proved an impediment if you have to code AT the driver layer. as such - x was originally designs (as a system - not specifically the xorg tree etc.) to allow full freedom to implement the internals of x any way you like - so as such if you wanted to spend the effort x could accelerate just about everything as long as hardware can do it, somehow - but the points at which that acceleration knowledge need to go into might be much higher up than xaa/exa. you'd have to write a forked x with all sorts of hooks higher up. - but it's possible... and then x client work as they always did - and get more use of the hardware :) MicroXwin ? http://www.microxwin.com/ MicroXwin is binary compatible to the Xlib API. However it is niether client server nor network oriented. Graphics operations are implemented in the linux kernel via a kernel module. An open source Xlib library sends graphics commands to the kernel. There is no network overhead and no context switch from X client to X server. This makes our solution smaller and faster than traditional X Windows. - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] Where to set Illume's preferences?
On Tue, Nov 11, 2008 at 08:10:24PM +0530, Ramprasad Rajendran wrote: 2008/11/11 Matthias Apitz [EMAIL PROTECTED]: Hello, I'm using the Illume keyboard as described in http://wiki.openmoko.org/wiki/Illume one question remains: the Wiki says «Then switch keyboard from None to Default in Illume's preferences.» Where I do that exactly? There is a small wrench on the top of the pull down menu that lets you change illume's preferences. ... if and only if you use illume-theme-illume + illume-config-illume there is no such icon in the default theme of Om2008. (illume-theme-asu) You should also disable the default keyboard as mentioned in the wiki (adding export QTOPIA_NO_VIRTUAL_KEYBOARD=1 in /etc/X11/Xsession.d/89qtopia) ram http://www.hashcube.com http://ramprasad.livejournal.com ___ 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: OM Testing: task-openmoko-qtopia-x11 has unsatisfied gstreamer depencies
On Tue, Nov 04, 2008 at 03:41:51PM +0800, Ray Chao wrote: Hi Martin, According to Julian, we were taking out a package due to license issue since last Friday, that should be reason for this issue. This might be the cause, but the issue itself still need to be fixed. Please create a ticket if the issue still exists. Currently, we are working on this. Please kindly wait for further notice of this issue within this thread. Sorry for the inconvenience. -- Ray Chao Openmoko System Admin. ___ 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
Optimization team update (11/02 ~ 11/08)
Hi community, A brief summary of what the optimization team did last week: Erin worked on qtopia to improve the network registering time. Qtopia 4.3.2: camp network about 26~36 sec and it would display 'No Network' on screen before that. Qt extended 4.4.2: 40 sec from qpe main() to Ready [black screen first, home screen 20 sec] Qtopia 4.3.2 + X11 [17 + 52 sec before, 52 sec -12 -20 = 30 sec, by applying two patches] http://git.openmoko.org/?p=qtopia.git;a=commit;h=9f0eb58ab7cca96e90bd49845d23b10ecf7ba664 http://git.openmoko.org/?p=qtopia.git;a=commit;h=9c8c832f77f4f24adc5ad17f5031016ce8562a34 FSO: 10-20 sec Google Android: 20 sec Olv tried to replace u-boot by qi along with various improvements to bring down the boot time to illume (without qtopia) to about 30 secs. qi does not support dfu-util so only do this if you know what you're doing. He dived into a lot of code reading to see if there are further possibilities. Jeremy looked into the two issues about suspend/resume that we may fix in userspace. One is #1991, here is his update: As I inspected, qpe and apmd opens /dev/apm_bios right now, and I found two possible scenarios for this issue as below: 1) in qpe, we need to wait for the reply of prepare_suspend for the modem. in this case, we may need to wait for a period +of time that exceed 30 seconds, and we don't know how long it could be, waitfing for the response from modem. 2) It goes to blank, but then ompower doesn't get any request for doing suspend. I doubt in some case, illume doesn't set +the suspend_delay timer. for 1), I will go to check what does that mean by the AT commands we emit before executing apm --suspend. for 2), I will debug illume for a while. Another one #1347 is about after the resume, it goes to suspend immediately. For this one, it's because screensaver timeouts right after the resume. We can fix this by invoking xset s off before going +to sleep, and reset it after the resume. Though I am looking into the possbilities of enabling apm in xglamo and checking the apm_bios driver code to see if we can fix this in xglamo. BTW, Matt has patches to solve ticket #1884. It works. Matt is arranging them and he is going to update some information about it. Julian wrote an initial version of python loader. It imports various modules first, listens on dbus and forks on demand to execfile. This brought down the load time of pyefl-sudoko from 2.59s to 1.38, a 46% improvement, and om-settings from 3.99 to 1.60, 59% improvement. There was already a daemon in Om2008 just for the sake of loading om-settings (and it cleverly sleeps for 4 seconds before starting up, make the booting even slower), we take it out to get the 3.99 number. It is just a start, there are many issues left regarding the python loader and we will keep working on it. Once the code is in a better shape Julian will put it into our svn/git. Tick mainly worked on the upgrade path this week (#2109). Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [om2008-testing] illume-config-illume + illume-theme-illume + illume
On Fri, Nov 07, 2008 at 12:29:40PM +1100, Sarton O'Brien wrote: Hey all, Been out of the loop for a few weeks and decided to see if testing was working again. After updating I had the icons issue and used the combination of: illume-config-illume + illume-theme-illume + illume Which seems to be working except that when prompted to enter my pin I get the SEGV error popup. It seems to coincide with the keyboard popping up but that may be coincidence. At one point I saw this on the console: enlightenment: malloc(): memory corruption I don't have the entire message but it's probably unimportant. Everything else seems fine, it's just when prompted for my pin. Any ideas? Sarton seems like #1767 to me. a temporary workaround will be using software engine instead of software_16. you can find this option in configuration (wrench) - engine - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: no icons in 2008.testing
On Wed, Oct 29, 2008 at 02:51:01PM +0100, Benedikt Schindler wrote: hi, this ticket (http://docs.openmoko.org/trac/ticket/2082) said that the no icons bug is fixed since 4 days. But there isn't an update in the unstable or testing tree. (they are still svnr36882. ) the way to fix this bug is not updating to another svn rev which might introduce other unexpected behaviors due to the massive changes in EFL recently. instead we stick to this 36882 and fix problems there. I don't think we will upgrade efl rev before we have another efl snapshot/release. following some random rev in svn trunk tree is proved to be a very very bad idea. the current stuffs in testing repo works for me and our testing team and also for other engineers. so I bet there's something wrong in the upgrade path or your theme/config combination. the only supported combination is illume-theme-asu + illume if you got stuffs like illume-config, illume-config-asu, please remove them. illume-theme-asu comes with both config and theme files. it does NOT include 'qwerty' button and 'wrench' config. I have also seen the illume default combination works: illume-config-illume + illume-theme-illume + illume notice that config and theme comes in different packages here. it DOES include qwerty and wrench. the way to switch between different sets of config and theme is to set it in /etc/enlightenment/default_profile . this is ugly and will/should be solved in upstream soon. after you make sure your efl related stuff and illume related packages are correct (check with opkg list_installed | grep illume), stop x server, rm -rf ~/.e, start x server. since the next stable release will be the first one that comes directly from a branch of om.dev, the upgrade path from stable (i.e. om2008.9) will need a lot of testing. our beloved testing team will help. FYI: at the moment the 'settings' app in testing repo still got error (not scrolling), this is a known issue. however one can still set the suspend time. - John How long does it need to get into unstable / testing ? Because the updates in the kernel-git (stable) showing up in the unstable-feeds 1 day after the patch is send to the git. So should i say something if these changes are not showing up after 4 days in the unstbale tree or is normal and should i be quiet and wait for it ? :) cu Beni ___ 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
Status update from optimization team
Dear community, On the organization chart we were called 'optimization' team so I put this in the subject, even though my ideal name would be something like 'Keroro' [1]. Olv and Erin provided an experimental fastboot images for the interested to try: http://lists.openmoko.org/pipermail/devel/2008-October/002950.html Jeremy reported his status: http://lists.openmoko.org/pipermail/devel/2008-October/002882.html Julian is still struggling with oprofile, python, etc. etc. along with distro tasks. With nobody offically assigned to distro team this seems never end. Check out tick's work to the touch screen: http://lists.openmoko.org/pipermail/devel/2008-October/002822.html It's commited as abe8f448547d1bd69ac2963e07e2657f27b79691 and should be available in testing repo after next autobuild. The illume issue (#2082) is partially solved now. It requires quite some black magic in the theme and config files to make the icons show up again. Thanks for raster's help on this. read more about this in: http://lists.openmoko.org/pipermail/community/2008-October/034881.html After seeing these cute icons, we found out only qtopia and sudoku work as usual. Other applications such as installer, locations are fully dead (#2098, #2099), while settings is half dead (#2097). Tick fixed 2098 and 2099 in openmoko.git commit 6725b90d5c9d844da196485beca7d9e82f8ce68c This efl update from oe.dev upstream really scared us, so the current plan is to stop following efl svn until another efl snapshot/release. The alsa state file is a real trouble. Since the audio quality actually differs on different versions of FR, it's hard to create one state file that suits all. We will keep working on it. Regards, John [1] http://en.wikipedia.org/wiki/Sgt._Frog ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] found the best gsmhandset.state file in FDOmizer
okay let's give it a try. merged into om svn and will be used as the default gsmhandset.state in the next build. the qtopia echo patch along with this state file still leaves a little echo and buzzing, but doesn't really effect the talking. Regards, John On Mon, Oct 27, 2008 at 01:16:42PM +0100, Matthias Apitz wrote: Hello, Since I own my FR I've already tested a lot of variants of the gsmhandset.state file; today I got to know of the FDOMizer project and pulled out the version of their tar file FDOMizer20081023.tar.gz; this is the best I have ever had until today: no echo, very clear and high volume on both ends (my wife asked me in a call if I have finally changed my opinion and have returned to normal cellphone :-)). There is still some buzzing, for both ends, but this is not so important. Just to let you know. matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e [EMAIL PROTECTED] - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ A computer is like an air conditioner, it stops working when you open Windows Una computadora es como aire acondicionado, deja de funcionar si abres Windows ___ 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: Is Openmoko working on their 'back to basics' plan?
Hi, We will still do a 2008.11 release so it will be in stable soon. If you don't to wait, you can switch to testing repo. Regards, John On Tue, Oct 28, 2008 at 11:06:34AM +0100, umaxx wrote: Hi, On Fri, 24 Oct 2008 14:47:03 +0800 John Lee [EMAIL PROTECTED] wrote: Now for the status update this week: Tick merged the qtopia echo patch (#1267), it works, no echo but the audio sounds a little bit less 'vivid' (not sure if this is the right word). He is now working on the touch screen usage, see http://lists.openmoko.org/pipermail/devel/2008-October/002712.html Will this patch went into stable too? Or did I need to upgrade to testing for this? Regards, Joerg ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Is Openmoko working on their 'back to basics' plan?
Dear community, http://onlinedev.blogspot.com/2008/10/is-openmoko-working-on-there-back-to.html And please read my comment below. I have to say I don't like opinions like this but I will take it as a result of high expectation. We will keep sending to the public list once we have something, commit to public scm, etc. but we certainly won't do _weekly_ release. For now please be patient and let the engineers work. Now for the status update this week: Tick merged the qtopia echo patch (#1267), it works, no echo but the audio sounds a little bit less 'vivid' (not sure if this is the right word). He is now working on the touch screen usage, see http://lists.openmoko.org/pipermail/devel/2008-October/002712.html Olv and Erin is working on reducing boot time. Currently it's reduced from 2:35 (Om2008.9) to around 1:40. One minute less in one week, and Olv just got back from hospital last Monday. We will merge this into OE once we get it organized properly. Jeremy is working together with kernel guy (aka Matt Hsu) to look into the possible improvement, namely take a screenshot and show it first during resume. It's a common technique in mobile phone. Julian is working on the python loader. He is new to python but he got very good helps here in the office such as Guillaume, etc. He still got some distro work to finish so it's going to take a while before he can work full time on this. Currently we have a major blocker #2071. It can be solved by update EFL, but no icons will show up in illume. This seems to be a different bug, but we are having an evas-native related issue on the build server so the EFL packages are not updated correctly in downloads.openmoko.org. This prevents people from confirming it and fire another bug. EFL ABI changed along with the svn rev increment last week, so Installer and Locations won't work without rebuilding. Although people already got reassigned, but nobody will give Om2008 love except us and holger, so we will fix the issues above and update testing repo soon. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is Openmoko working on their 'back to basics' plan?
On Fri, Oct 24, 2008 at 02:47:03PM +0800, John Lee wrote: Now for the status update this week: Olv and Erin is working on reducing boot time. Currently it's reduced from 2:35 (Om2008.9) to around 1:40. One minute less in one week, and Olv just got back from hospital last Monday. We will merge this into OE once we get it organized properly. some bootcharts here: http://people.openmoko.org/olv/tmp/ bootchart* ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.8 - testing] - no desktop icons any more.
On Tue, Oct 21, 2008 at 01:33:09PM -0400, Daniel Benoy wrote: On Tuesday 21 October 2008 12:33:04 you wrote: hi, is someone on the testing tree of the 2008.8 distro, and solved the icon problem yet? My last comments in #2071, but not the same bug it seems. i upgraded to the latest testing 2008.8 packages. I know that there is a problem with the splash screen at boot up, that isn't solved yet. so i disabled the boot screen (btw: that saves 10 seconds boot time) But now i don't have any desktop icons. I'm in the same boat as you there. Can anyone even shed any light on what the cause of this is? I don't mind a little debugging but it's a bit over my head I don't even know where to start. Also, is active development (or building from git or whatever) happening in the 'testing' instead of 'unstable' ? If that's the case then I misunderstood the purposes of the feeds and should have went with stable. active development happening in unstable. This illume issue should not be there in the first place. also the clock-, battery- and signal-panel is at one place now. i restored the old ~/.e directory but that didn't changed anything. I fixed this by removing and reinstalling illume-theme-asu, and then installing illume-theme-illume (I believe this is also necessary in order to get the illume keyboard I like, but it also fixed the problem with all those little icons being squished into the same place and tiny.) - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the basics: improving user experience
On Sun, Oct 19, 2008 at 10:36:38AM -0400, Feydreva wrote: I am not a developer, but i test the images and try to use the openmoko... My main issue with Openmoko are : 1) Battery life : only 4hrs, and when you charge it, it discharge itself after a while. I cannot use it as a daily phone :/ 2) Basic telephony : the phone should wake up faster than it does now the time the phone wakes up, rings, and you pick the call, there has been 6 rings for the other party, and may already be on the voicemail 3)Basic text message should work flawlessly. 4) A way to set up the sound and rings ... There is actually no gui for that Try install qtopia-phone-x11-ringprofile-app-data You might also need illume-theme-illume and use illume in /etc/enlightenment/default_profile to enable the wrench icon. 5) I haven;t find yet where to activate the PIN or not... I put 1 sim card that asked for a pin, it work.. I put a another sim card, where no pin is needed.. it was still asking for a pin... (I had to reflash to solve this one) but there is no Menu where I could choose, Pin on/off, if pin on, set up the pin I do not care at all about any other application. I want a daily phone... where i can receive, make call, receive and send text message, and have the phone a day with me, wihotut having to cahrge it every 2 hrs... (8-10 hrs battery life would be better, with wifi on, gps off) Until we reach this point, I will continue tu use my dumb phone eeyday, and the FR will catch some dust on a shelve... Peace Philippe On Sun, Oct 19, 2008 at 9:21 AM, Stroller [EMAIL PROTECTED]wrote: On 19 Oct 2008, at 13:46, Dale Maggee wrote: arne anka wrote: ==Pim device== imho that's exactly the kind of task openmoko did _not_ ask for. I would respectfully disagree - Openmoko asked about Improving user experience, and users are saying they want to experience PIM capabilities. ... and it's doable by community! Agreed, it could be done by the community, but I don't see anyone doing it, and I'm not smart enough, nor do I have the time at the moment. It does not matter whether YOU could do it or not. it's a matter of where Openmoko's resources are best spent. If you can't write a PIM app, then you CERTAINLY can't write kernel drivers - THAT is where Openmoko's resources should be mist focussed, IMO. As others have stated, there is some hardware-level stuff that only Openmoko has NDA for. And without working hardware drivers to ensure that phonecalls work flawlessly (and wifi, and bluetooth), a PIM is irrelevant. there are a lot of posts lately completely ignoring the point of basics and no eyecandy I haven't seen anybody ask for pretty-looking PIM applications, people seem to be asking for *reliable* PIM applications. I'd call reliability and robustness basic. Basic reliability and robustness resides in a program with which you can enter a number and make a call. Once that prototype exists it is much easier for the community to extend it to PIM functionality. Openmoko can then move on to wifi drivers, Glamo hardware acceleration and pairing of bluetooth headsets. pim frinst is at it's best part of a middle tier, but rather of a particular distribution -- This kind of comes into the Should FSO merge be sped up? debate, as I believe the framework has PIM stuff built into it. AIUI (and I would be delighted to be corrected if I'm wrong), the FSO stuff is intended to provide functions which will allow you to make simple DBUS calls such as get number $var from PIM manager and make call to number $var. Once these are complete, writing your own applications becomes easy. True the first of these example calls requests you integrate the functionality in your own app, but the latter makes problems with dealing with the dialler the GSM chips whatever go away. It is FAR more important to provide the community with these tools than it is to provide any kind of application that utilises them (beyond a command-line version which gets numbers from a text-file and operates as a test example). Once these calls are available there will be dozens of PIM managers posted to this list and being written by enthusiastic Python programmers. Stroller. ___ 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Come to wiki to help improving user experience
Hi, Thanks for starting this page. It's on my list but I'm too slow. I would like to use it to reflect the latest status, so it will be better if we *only* do the the discussion here on the mailing list in the 'Back to the basics' thread. In the meantime, the current todo list there was NOT written by me and will be updated soon. Regards, John On Fri, Oct 17, 2008 at 07:12:03PM +0800, Wendy wrote: Hi, thanks for your help to collecting all the critical problems, it's helpful. :) For more clear picture, we creat a page in our wiki to clean it up. Please go to this page : http://wiki.openmoko.org/wiki/Improving_user_experience You can vote to those issues or add other critical problems. This will help us to verify the bugs and not lost our focus. Feel free to give us your question and suggestion. :) Regards, Wendy ___ 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
Back to the basics: improving user experience
Hi, Like Wolfgang said in http://n2.nabble.com/Weekly-Engineering-News-41-2008-td1336450.html We assembled a team to focus on improving the user experience. Here is our todo list at the moment: * Reduce boot time. * Optimize the touch screen driver on freerunner for finger usage. * A generic python loader to enhance the start up time of python scripts. * Work with system team to improve suspend/resume user experience. I would like to ask the community: What do you want us to work on? The idea is * We improve the current stack, not creating new features. * Prefer stuffs which could be brought over to gta03 instead of gta02/om2008 specific. * won't work on om2007 stack. So, tell us what you want, then the coding monkeys will start working! :) Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the basics: improving user experience
On Thu, Oct 16, 2008 at 05:15:59PM +0800, W.Kenworthy wrote: 2008.9 + updates A phone that works: reliably make and receive calls reliably make and receive sms's At the moment, totally losing sms messages (phone sometimes hangs/crashes when one comes in) or not waking up if suspended when one comes in means that its almost unusable as a phone. It often takes several boots before the pin dialog comes up. If you forget while waiting and it does come up but its awhile until you get to it, it will hang so you have to reboot anyway. Sometimes restarting X helps, but not always Stability: My average in normal usage is at least two boots a day due to crashes, and often extra rebooting to check if an sms comes in (sometimes they will only show on fresh re-registration. Leaving the phone on and registered for hours doesnt seem to help - not sure how vodafone australia takes to retry messages but surely its less that 12 hours. The only way to stop crashes is not to use the thing! No GPS, no wireless, no phone calls, and definitely never send/receive an sms :) I suspect the event/0 thread is at the root of a lot of this so I am waiting a fix for that. I dont think I am alone in this - hopefully the new focus means that these issues can be dealt with. I am a little concerned though that you think things like boot time is important enough to mention, but not basic issues like being able to reliably make a phone call. Though a faster boot means less time wasted going through multiple bootups to get the thing registered. :) I would like to explain a bit more about this: We're not the only team that will work on the new focus. Stability should be greatly improved by the effort of FSO, and boot time is just another thing we would also like to improve. At the same time, we will work on fixing qtopia bugs as well, so if the problems you have is in trac already, we will look into them. - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the basics: improving user experience
On Thu, Oct 16, 2008 at 01:01:27PM +0200, Riccardo Centra wrote: Why Qtopia? I prefer that you release the next minor update ( aka 2008.10 ) and focus all works on paroli and tichy. The new framework is pretty usable and stable. Our plan is to bring qtopia to a more usable state then it currently is before the next big thing - fso + tichy (?) + paroli , but enhancements which could be brought to the new software stack will get higher priority. People (including myself) still need to use the phone before that. :) - John 2008/10/16 John Lee [EMAIL PROTECTED] On Thu, Oct 16, 2008 at 05:15:59PM +0800, W.Kenworthy wrote: 2008.9 + updates A phone that works: reliably make and receive calls reliably make and receive sms's At the moment, totally losing sms messages (phone sometimes hangs/crashes when one comes in) or not waking up if suspended when one comes in means that its almost unusable as a phone. It often takes several boots before the pin dialog comes up. If you forget while waiting and it does come up but its awhile until you get to it, it will hang so you have to reboot anyway. Sometimes restarting X helps, but not always Stability: My average in normal usage is at least two boots a day due to crashes, and often extra rebooting to check if an sms comes in (sometimes they will only show on fresh re-registration. Leaving the phone on and registered for hours doesnt seem to help - not sure how vodafone australia takes to retry messages but surely its less that 12 hours. The only way to stop crashes is not to use the thing! No GPS, no wireless, no phone calls, and definitely never send/receive an sms :) I suspect the event/0 thread is at the root of a lot of this so I am waiting a fix for that. I dont think I am alone in this - hopefully the new focus means that these issues can be dealt with. I am a little concerned though that you think things like boot time is important enough to mention, but not basic issues like being able to reliably make a phone call. Though a faster boot means less time wasted going through multiple bootups to get the thing registered. :) I would like to explain a bit more about this: We're not the only team that will work on the new focus. Stability should be greatly improved by the effort of FSO, and boot time is just another thing we would also like to improve. At the same time, we will work on fixing qtopia bugs as well, so if the problems you have is in trac already, we will look into them. - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The Lost Openmoko Community
On Sat, Oct 04, 2008 at 09:00:05AM -0700, Hire wrote: For me the solution is simple: improve fso, paroli, tichy and say goodbye qtopia. With my FOSS developer's hat on instead of OM employee's, I agree with what you said here. Our resource is very limited so it's better to focus on the same thing. The actual stack, om2008.* sux. I find it absolutely not functional. Om2008.* is actully working as my daily phone now, so for me it's okay. Instead, it will be cool to see SHR on freerunner because merged the power of new framework with the old stack ( 2007.4 ) that seems to be almost stable. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU keyboards
On Thu, Aug 28, 2008 at 11:59:53AM +1000, Carsten Haitzler wrote: ok. i suck. i have screwed this defsault_profile monkey. 1 last time for the dummies (i.e. - me). 1. opkg install illume-config-illume (get illume's config panel and illume keyboard by default - this should be available) 2. opkg install illume-config (get qwery button) 2. echo 'E_PROFILE=-profile illume' /etc/enlightenment/default_profile (switch to the illume profile from asu) 3. reboot (easiest way to get your x session going again as the default_profile is a command-line hack). :) that should do it! hey raster, i ported these stuffs to om.dev, so they should show up in the testing repo soon. however, a few problems: * the qpe keyboard will appear again and replace the illume default after any reload operation, e.g. added a new desktop file. (showing a small wheel on the bottom right of screen) * same thing will happen if i do killall -hup enlightenment * a reboot will put illume kbd back efl rev: 35661 illume rev: 35693 any idea ? Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Request for help: Would like community applications to show anddiscuss at LinuxWorld
On Tue, Jul 29, 2008 at 08:23:29AM +0200, Marcus Bauer wrote: On Tue, 2008-07-29 at 01:08 +0200, Kristian 'kriss' Mueller wrote: Am Dienstag, den 29.07.2008, 00:46 +0200 schrieb Marcus Bauer: The opposite is true. FSO forces you into ASU. It basically makes all work that has been put into OM2007.2 useless. Please stop telling these lies. Marcus, did I miss the irony here, or do you really believe this? This is simply a matter of fact, not of believe. FSO is a shitty API collection which is closely connected to ASU. Steve is a sales guy and has not much clue of the underlying software, thus he simply repeats what others told him. The bad combination is NIH (not invented here) together with almightyness thinking which results in all this religion here, making people like you ask whether I believe. I don't believe, I simply know. Part of my current work requires me to use fso daily. It seems strange that what I know seems to be different from what you know. * fso does not force you to ASU or closely connected in any way. could you please elaborate? fso: an open specification dbus interface (freesmartphone.org) + a reference design (frameworkd, check git.freesmartphone.org) fso-image: fso + a reference python UI based on EFL. asu: a enlightenment WM for mobile phone (illume) + qtopia phone stack (not based on fso) + installer (EFL) + diversity (gps app based on EFL) + exposure (config app based on EFL) the only similarity i can tell is EFL in fso-image. but the fso itself does NOT force you to use it, just the implemented reference UI used it. it's easy to do another reference UI with GTK. Why should anyone at Openmoko want to keep out other frameworks, after even putting qtopia to X11? That was mostly Trolltech's work. And apart from that you technically can't keep out any other toolkit because there is Linux below and X on top of it. But FSO combines plenty of different things into one collection of API's and that is how the Microsoft world works and always did and which drove so many developers to Linux. If I use Apache as webserver I can use Konqueror, Opera, Safari or Firefox as browser. However, Microsoft has more than once tried to tie Internet Explorer to IIS, giving it an advantage over other browsers. Same goes for Microsoft Office and Windows. exactly what are tied together here? i see the arguement here is probably 'fso makes anyone that wants to develop on neo has to use this framework', but this is not true. it can make some developers' life easier but you don't have to use it. for example, you can just run the ogpsd subsystem in frameworkd then use phonekit + gsmd to handle gsm if you want. on the other way around, the frameworkd is just a reference design, anyone can take libgsmd + gsmd to make the same interface on dbus. any app on fso will not notice. snipped FSO is the brainchild of Dr. Michael Lauer, fresh from the university's ivory tower but lacking any industry experience. It is reinventing the wheel and drains lots of ressources that are needed elsewhere inside of Openmoko. It combines plenty of things out of which one is a new PIM API based on dbus. This idea alone is worth to be mentioned every day for a year on the dailyWTF website. could you explain why it's a WTF idea to have a PIM API on dbus? It is not about GTK or qt or ETK. It is about getting a working platform out to users and developers. OM2007.2 was mostly there. It reminds me to a joke: Two fools try to escape from a lunatics hospital. There are 100 walls to climb over and so they start: 10, 20, 50, 90, 99. In that moment says the one to the other: 'Lets go back and do the last wall tomorrow'. ...have fun and enjoy life and start looking at the Neo what it is: a tiny Linux computer with a GPS and a GSM modem. There is no sudden revolution going to happen tomorrow. there are technical reasons behind the re-implementation of gsm daemon but I'm not the one to answer it. I think the reason why you are unhappy is that OM moved away from OM2007.2. well, 1. you are obviously not the only one who felt this way. 2. that's a separate issue. since OM will stick with fso in the foreseeable future, I think port OM2007.2 app suites to fso is a logical move. ogpsd is there based on gypsy, and it should be just another backend of tangogps. Freedom is a synonym for choice. The choice for your keyboard, for your window manager, for you applications, last not least for your gsmd. I like this sentence. if most of the functionalities on my neo have a unified dbus interface then i'm happy. honestly i failed to see anything wrong with this. Regards, John FIC/Openmoko came to support Linux on their hardware platform in order to give you this choice. Now it has changed into some religious life-style thingy with phantasies of becoming tomorrows ubiquitious
Re: Openmoko on Design
On Wed, Jul 30, 2008 at 01:47:29AM +0100, Al Johnson wrote: I'll snip most of it to keep the length reasonable. same here :) On Tuesday 29 July 2008, William Lai wrote: It already is. We've offered a couple of different solutions to community requests that were declined by, well, engineering. One of them was: * create a package to be installed through installer adding manual qwerty button to illume theme. The only suggestion I remember was that the community fork illume. Is this a different take on the same suggestion, or a different suggestion? What was the other option? And what was the objection to providing it as a configuration option with the default being off, as proposed on this list? What we are trying to do: provide a OM repository and a community repository. in this particular case, if in the end the illume still shipped without kbd button, then the community will very likely provide another version of illume called illume-kbd in the community repository. thus you can replace the shipped illume with illume-kbd, and the next upgrade will get the new version of illume-kbd instead of illume, so you don't need to change it again after upgrade. Where we are right at the moment: illume is there. the community repository is not ready yet but we're working on it. the dependency handling of replacing the shipped illume with illume-kbd is not ready yet but we're working on it. My personal comment on this: if the illume is so much more popular then illume-kdb (theoretically we can know that from the repository log) or the other way around then you bet that fact will be very effective in OM. ;) Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Meta Toolchain Release (2008 May)
On Fri, May 30, 2008 at 10:37:40AM +0100, Andy Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | That is exactly the problem. You see, if we put april software update | into consideration (these are standard openmoko apps as well), the | prerequisite will not be small for a toolchain. I'm still thinking | | Not sure what you mean, is it that the dependencies for the April | software are different and hence the toolchains needs both April and | May libs ? | | I have just looked at one app (dialer), so you guys know the | dependencies a lot better than I do and maybe they do make the | toolchain too big, but just for the dialer the toolchain was pretty | reasonable size. | | about this out of my personal interest. Why not allow installation of target packages into the toolchain and these difficult philosophical questions of what to stuff into toolchain are GONE. End users can decide and enforce what they wanted in there purely from normal distribution packages. that's exactly what I was talking about in my previous mails. :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Meta Toolchain Release (2008 May)
I have just realized that opkg-cl isn't in toolchain. :( added and committed, will show up in the next toolchain build. On Thu, May 29, 2008 at 12:34:40PM +0800, John Lee wrote: libjana isn't packaged in toolchain by default. the default compopents are: libmokogsmd2, mokoui2, mokopanelui2, mokojournal2 and dependencies. we cannot package everything or it's going to be a huge toolchain. however, there are 2 interesting aliases in environment-setup: alias opkg='LD_LIBRARY_PATH=/usr/local/openmoko/arm/lib /usr/local/openmoko/arm/bin/opkg-cl -f /usr/local/openmoko/arm/etc/opkg-sdk.conf -o /usr/local/openmoko/arm' alias opkg-target='LD_LIBRARY_PATH=/usr/local/openmoko/arm/lib /usr/local/openmoko/arm/bin/opkg-cl -f /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/etc/opkg.conf -o /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi' which means by opkg-target we can add the packages we need into the toolchain directory. at the moment the content of /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/etc/opkg.conf is incorrectly pointed to local directories in build host. if we replace it by the corresponding URIs such as http://buildhost.openmoko.org/daily-feed/ http://buildhost.openmoko.org/daily-feed/all http://buildhost.openmoko.org/daily-feed/armv4t http://buildhost.openmoko.org/daily-feed/neo1973 http://buildhost.openmoko.org/daily-feed/om-gta01 then _theoretically_ we can just do opkg-target update opkg-target install libjana-dev I haven't tried this approach before because OE suits me just fine. however, for those who just want to make apps I think it's an right way to start. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Meta Toolchain Release (2008 May)
On Thu, May 29, 2008 at 06:44:42PM -0700, Pranav Desai wrote: On Wed, May 28, 2008 at 9:34 PM, John Lee [EMAIL PROTECTED] wrote: libjana isn't packaged in toolchain by default. the default compopents are: libmokogsmd2, mokoui2, mokopanelui2, mokojournal2 and dependencies. we cannot package everything or it's going to be a huge toolchain. however, there are 2 interesting aliases in environment-setup: I understand, and you don't have to include all the libraries, but atleast the prerequisite for building a standard openmoko app should be included. That is exactly the problem. You see, if we put april software update into consideration (these are standard openmoko apps as well), the prerequisite will not be small for a toolchain. I'm still thinking about this out of my personal interest. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Meta Toolchain Release (2008 May)
On Sun, May 25, 2008 at 04:19:37PM -0700, Pranav Desai wrote: I am still having trouble building openmoko-dialer2 with the toolchain. I can build openmoko-sample2 just fine. The toolchain seems to be missing libpulse. Initially, om-conf openmok-dialer2 gave both libebook and libpulse as missing. I found that libebook is present in the toolchain, but was missing the .pc file. After adding that it went ahead and only complained about libpulse. So I started building pulseaudio-0.9.10 with the toolchain. After resolving some dependencies like liboil and libsndfile, I was able to build libpulse. But now I stuck at libjana. checking pkg-config is at least version 0.9.0... yes checking for DIALER... yes checking for JANA... configure: error: Package requirements (libjana libjana-ecal libjana-gtk) were not met: No package 'libjana' found No package 'libjana-ecal' found No package 'libjana-gtk' found Any ideas, suggestions or can anyone provide with the required libraries ? Thanks -- Pranav libjana isn't packaged in toolchain by default. the default compopents are: libmokogsmd2, mokoui2, mokopanelui2, mokojournal2 and dependencies. we cannot package everything or it's going to be a huge toolchain. however, there are 2 interesting aliases in environment-setup: alias opkg='LD_LIBRARY_PATH=/usr/local/openmoko/arm/lib /usr/local/openmoko/arm/bin/opkg-cl -f /usr/local/openmoko/arm/etc/opkg-sdk.conf -o /usr/local/openmoko/arm' alias opkg-target='LD_LIBRARY_PATH=/usr/local/openmoko/arm/lib /usr/local/openmoko/arm/bin/opkg-cl -f /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/etc/opkg.conf -o /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi' which means by opkg-target we can add the packages we need into the toolchain directory. at the moment the content of /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/etc/opkg.conf is incorrectly pointed to local directories in build host. if we replace it by the corresponding URIs such as http://buildhost.openmoko.org/daily-feed/ http://buildhost.openmoko.org/daily-feed/all http://buildhost.openmoko.org/daily-feed/armv4t http://buildhost.openmoko.org/daily-feed/neo1973 http://buildhost.openmoko.org/daily-feed/om-gta01 then _theoretically_ we can just do opkg-target update opkg-target install libjana-dev I haven't tried this approach before because OE suits me just fine. however, for those who just want to make apps I think it's an right way to start. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
support win mobile
Dear Community, A decision has been made _today_ that Openmoko is going to support Windows mobile. We, the distribution team, want to provide our customers the maximum freedom in choosing whatever platform they want, even the close source ones. We will make necessary modifications to wine, thus enable win mobile on neo. One specific Openmoko hardware is going to support Windows mobile. It's the Neo Pocky. A prototype has been made and placed in our meeting room for quite a while. Please check this url for intro and photos: http://walkingice.twbbs.org/blog/?p=336 Regards, John Lee ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qemu on GTA02, the problem still here
On Mon, Mar 24, 2008 at 02:12:00PM +0100, François TOURDE wrote: Le 13961ième jour après Epoch, John Lee écrivait: But it doesn't :(... In fact, the most_recent function in download.sh use alpha sorting to determine the most recent images, so in the list: u-boot-gta01bv4-1.3.1+svnr4223+gitb29661fc115106454288051bc9a488351ce8-r3.bin u-boot-gta01bv4-1.3.1+git0+b29661fc115106454288051bc9a488351ce8+svn4230-r3.bin the first one is the winner :( Perhaps renaming the file on the server is a good bypass, then modifying the most_recent proc. Hope this help... Seems I don't have enough files in my local deploy directory. :) Right now we have git hash in filename so the alpha sorting will not be correct, so the function needs to be updated anyway. Normally when I flash qemu I always modify openmoko/env to make sure it gets the file I wanted. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qemu on GTA02, the problem still here
On Sun, Mar 23, 2008 at 10:53:45AM +0100, Jens Fursund wrote: On Sun, 2008-03-23 at 02:55 +0300, Evgeny Ginzburg wrote: In current builds this bug exists, patch inserted in revision 4230, but i really don't know which revision OE use now how migrate to 4230. It's on buildhost already: http://buildhost.openmoko.org/daily/neo1973/deploy/glibc/images/neo1973/u-boot-gta01bv4-1.3.1+git0+b29661fc115106454288051bc9a488351ce8+svn4230-r3.bin the default env used by download.sh and flash.sh should be able to use the latest files automatically, so MokoMakefile will also work. I think you can use these images (u-boot, kernel, rootfs) first and update it by your ipkg/binary later to ease the trouble. Well svn up says revision 4241, and the bug is still there... :( No, it's not. Check console-ansi.patch http://svn.openmoko.org/trunk/src/target/u-boot/patches/console-ansi.patch svn update the openmoko directory under /moko is not equivalent to updating the package built from OE. maybe you can enable moko-autorev.inc or download from the uri above. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: openmoko-devel-image error
On Tue, Mar 11, 2008 at 08:39:43AM +0100, Javi Roman wrote: On Sat, Mar 8, 2008 at 11:46 AM, Javi Roman [EMAIL PROTECTED] wrote: I'm getting the following error building OM: ERROR: Openembedded's config sanity checker detected a potential misconfiguration Does anybody have the same error? Why it's so difficult to make openmoko image? Is there any policy for committing to openmoko repository? -Javi Roman. I decided to delete the whole directory build/tmp: it was a abi_version problem (I didn't express the question correctly). I don't know if it's the correct decision to delete the buld/tmp directory if abi_version file changes (0-1). Thanks. Hi Javi, FYI: http://lists.openmoko.org/pipermail/openmoko-devel/2008-March/002070.html Regards, John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Distribution weekly update
Hi, We're going to start a weekly report about what's happening inside the openmoko distribution. * cacao + swt make it possible to run things like jalimo-swt-example_0.1.0_all.ipk from http://jalimo.evolvis.org/repository/openmoko/all They are both included in OM feed now. Check https://wiki.evolvis.org/jalimo/index.php/Packages * `processing' can be run on neo with cacao + classpath-gtk but there are still many problems. * Thanks to Gernot Hillier. gpsdrive_2.10pre4 works on neo. http://bugs.openembedded.net/show_bug.cgi?id=3670 * multitap-pad: replaced the original matchbox-keyboard-inputmethod. Some might not like it but it's the first try and we'll keep working on it. * asterisk is included and should be available in a couple days. * biggest thing: Graeme successfully ported qtopia into OE and Rod has added it into MokoMakefile. Please tell us about the cool things we missed. Cheers, John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Toolchain alpha release
On Sat, Jan 05, 2008 at 10:59:39PM -0300, Werner Almesberger wrote:
I found one little problem with setup-env: when I try to build u-boot
or the kernel with it, ld fails due to the LDFLAGS, which are defined
as follows:
export LDFLAGS=-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib
-Wl,-rpath-link,${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-O1
Now, both u-boot and kernel invoke ld directly and not through cc
or gcc. Unfortunately, ld doesn't understand the option -Wl, so
it fails.
We couldn't just omit the -Wl, since gcc doesn't understand -rpath-link,
and we wouldn't want to unconditionally compile with -O1 anyway. But in
what scenario do we actually need to set these flags ? As far as I can
tell, just plain use of arm-angstrom-linux-gnueabi-gcc or
arm-angstrom-linux-gnueabi-ld gets all the search paths right.
If we do have to set LDFLAGS, I can think of the following ways to work
around breaking u-boot and kernel builds:
1) don't use setup-env but define only PATH (which is all kernel and
u-boot really need anyway)
2) make LDFLAGS= ...
3) LDFLAGS= make ...
What I don't like about 2) and 3) is that they make an already too long
command even longer, and that this may let more environment variables
slip through and cause subtle breakage. 1) looks much safer.
Would you agree that, if we have to keep LDFLAGS in setup-env, 1) best
reflects proper use of the toolchain in these cases ? If not, how would
you propose to solve this problem ?
Yes, I met this one before and I solved it by 1). This environment
setting is dumped and modified from OE but the way it uses LDFLAGS is
strange. However, if this got fixed, something other then kernel or
uboot might break, so I just leave it as it is.
I think if one wants to use toolchain this kind of problems will
always happen. To fully avoid it we have to use OE. For now the
users of toolchain will just have to customize it to fit their own
usage. I am thinking about dumping the run.* scripts OE generated
along with the source package to solve this but haven't got time to
really look at it.
- John
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Announce nightly build and source code packages
Hi, The nightly build is automatic now and could be found under http://buildhost.openmoko.org/daily/ It pulls from monotone.openmoko.org, which means it will be a couple days behind the mainline OE with some fixes to make sure OM builds. It will also have moko-autorev enabled so it will always build the latest OM related packages. So, if you want to use packages on the bleeding edge, you could direct your ipkg to pull from here. If a developer want to retrieve the source code of an existing application inside OM, he/she had to check the OE recipes to find out the exact download location, version and the patches on it to fix bugs/compiling errors before. Now the orig and diff source tarballs will be generated along with the nightly build. They could be found under http://buildhost.openmoko.org/daily/tmp/deploy/glibc/source/ Please report any bugs/feedbacks. Thanks! Regards, John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Toolchain alpha release
Hi, i686 version is released as well. http://downloads.openmoko.org/toolchains/ On Wed, Dec 05, 2007 at 02:07:59AM +0800, John Lee wrote: Hi, Please check http://downloads.openmoko.org/toolchains/openmoko-x86_64-arm-linux-gnueabi-toolchain.tar.bz2 It's the alpha release of a lean toolchain built on debian lenny, x86_64. The source of openmoko-sample2 is included so you could compile and install it on your neo. The tarball must be extracted to '/' , and please read /usr/local/openmoko/arm/README . As the name suggests, it's really in alpha stage, so please give your feedback/ flame. Thanks! The wiki page http://wiki.openmoko.org/wiki/Toolchain is not updated yet since we got (temporary ?) connection problems here in Taipei. Regards, John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Toolchain alpha release
On Mon, Dec 10, 2007 at 09:55:00AM +0100, Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Lee schreef: Hi, i686 version is released as well. http://downloads.openmoko.org/toolchains/ As I pointed out to Mickey last week, you can't legally distribute that toolchain for a number of reasons: * You use autotools.bbclass almost verbatin, but don't include OE's COPYING.MIT * ipkg-utils is GPL, but there's no trace of that fact in the toolchain, even if you include files from it. Most toolchains I encounter come with a document detailing the include items and their licenses, dunno if that's mandatory, but it certainly would be nice to have. regards, Koen Hi Koen, Thanks for pointing out that. I have updated the tarballs in question and will consult someone appropriate to know if further modificaions are required. Cheers, John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Toolchain alpha release
Hi, Please check http://downloads.openmoko.org/toolchains/openmoko-x86_64-arm-linux-gnueabi-toolchain.tar.bz2 It's the alpha release of a lean toolchain built on debian lenny, x86_64. The source of openmoko-sample2 is included so you could compile and install it on your neo. The tarball must be extracted to '/' , and please read /usr/local/openmoko/arm/README . As the name suggests, it's really in alpha stage, so please give your feedback/ flame. Thanks! The wiki page http://wiki.openmoko.org/wiki/Toolchain is not updated yet since we got (temporary ?) connection problems here in Taipei. Regards, John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko OE repository not quite ready for MokoMakefile production usage
Hi Rod, The oe snapshots site: http://downloads.openmoko.org/OE/snapshots/ The monotone repository: monotone.openmoko.org I have done various tests on them such as run different versions of monotone againest the database files, build from scratch with these settings, etc. There might still be subtle problems in different usage scenarios, so please give feedback and I'll fix them asap. - John On Thu, Nov 29, 2007 at 09:14:15PM +1030, Rod Whitby wrote: There is one issue which means that MokoMakefile cannot change over to using the new area yet. I have discussed this with John, but am reporting here so people don't continually ask me why MokoMakefile hasn't changed yet. The issue is that new OpenMoko mtn database snapshot area at http://downloads.openmoko.org/OE/snapshots/ only contains a single unversioned mtn database. MokoMakefile currently identifies the user's monotone version, and downloads the correctly versioned mtn database from http://www.openembedded.org/snapshots/ (look there to see the naming convention and list of 6 different mtn versions that are supported). Only if it cannot match the exact version does it fall-back to using the unversioned snapshot. Unless OpenMoko is going to require a specific Linux distribution and monotone version for building the OpenMoko distribution, I would prefer to wait until OpenMoko replicates this facility for their developers before I change the MokoMakefile, otherwise we will have *many* new users having problems with monotone database migrations, and negating the ease of setup that MokoMakefile currently provides. I have given John details on how to do this - I'm sure Graeme or Mickey can get the older mtn binaries from Koen to implement it. I've asked John to let me know as soon as there are correctly labelled versions in http://downloads.openmoko.org/OE/snapshots/, and I will immediately update MokoMakefile to use the new area when that happens. -- Rod Whitby -- MokoMakefile author ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OpenMoko OE repository
Dear Community, The official OpenEmbedded repository to build the OpenMoko distribution can be found at monotone.openmoko.org. If you're using MokoMakefile, please refer to http://wiki.openmoko.org/wiki/MonotoneServer#Using_MokoMakefile for instructions about how to switch. Quotes from wiki page: Currently, monotone.openmoko.org serves the OpenEmbedded branch org.openembedded.dev. In contrast to the main OpenEmbedded server monotone.openembedded.org, the repository monotone.openmoko.org is a couple of days behind. This is to ensure that the metadata is always in a consistent state that allows you to build the OpenMoko distribution. This is part of the work from the tools team of OpenMoko, lead by Mickey. The current repository maintainer is [EMAIL PROTECTED] . Enjoy! Cheers, John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko OE repository
On Thu, Nov 29, 2007 at 10:32:33AM +0100, Jay Vaughan wrote: http://wiki.openmoko.org/wiki/MonotoneServer#Using_MokoMakefile Following these instructions to a tee I get the following result: fi mtn: misuse: database /home/j/hak/openmoko/OE.mtn is laid out according to an old schema mtn: misuse: try 'mtn db migrate' to upgrade mtn: misuse: (this is irreversible; you may want to make a backup copy first) mtn: misuse: database /home/j/hak/openmoko/OE.mtn is laid out according to an old schema mtn: misuse: try 'mtn db migrate' to upgrade mtn: misuse: (this is irreversible; you may want to make a backup copy first) make: *** [update-mtn] Error 1 I'm going to do the 'mtn db migrate' .. ; -- Jay Vaughan Yes, the monotone version problem... We need to provide mtn bz2 packages for different version of monotones. Working on that know... `mtn db migrate' is really slow. :p - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
