Re: qualitiy is important for tangoGPS
On Sunday 11 April 2010 19:42:23 Marcus Bauer wrote: On Sat, 10 Apr 2010 16:29:15 +0200 Sander van Grieken san...@3v8.net wrote: No. Just email your patches to Marcus Bauer. Expect no reply nor use of patches. But, you don't have the right to complain. You have the right to fork, though. Well, looks like you are a bit upset that your patch was not accepted Not at all, I don't care, I build my own tangogps. I just warning people what to expect. It's quite different from other GPLed projects. but quality is important for the longterm success of tangoGPS. Yes that's why GPL projects usually attempt to also build a _developer_ community. Criteria for software quality are (amongst others): * correctness (i.e. bug free) * maintainability * robustness Your patch about speed-up is very invasive in core parts of tangoGPS, was not well documented, not minimalistic and introduced several bugs. Yes all true, there were some issues still that needed attention, and I didn't expect you to merge it in. I expected some feedback on the direction though. Never got it (until now :) In general it falls in the category of premature optimisation which will cause enhancements like other map datums as WGS84 or other projections as Merkatoor significantly more difficult and error prone. Nonsense. I mean, reloading and parsing all PNG tiles on every map drag? come on, you can do better than that. And other projections? BS, you're just stacking tiles. That's not premature optimisation, that's called caching. There is plenty of documentation about how to contribute to open source projects and my advice is to check that first. Very funny. Where is the mailing list, where's the bugtracker, where's the public tree, where's the *feedback*? If you're really interested in the long-term success of TangoGPS I suggest you start building on the developer community aspects. I know it's hard to let other developers make changes to your project, but you're still the owner of your own tree, and decide what has high enough quality standards for you. For not-quite-ready patches (like mine), there's a thing called branches, which you can use to give other devs a place for their work. Another option is to use a bugtracker, where patches can be attached to bug descriptions. At least then developers don't get the impression that their hours of work fall into a deep black void. If you don't set up this critical infrastructure, or even have the courtesy to give feedback on patches, eventually all interested developers lose interest. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Where is the tangoGPS community? (was: TangoGPS font size for speed indicator)
On Saturday 10 April 2010 15:59:04 Joshua Judson Rosen wrote: I have a set of patches, already--what should I do with them? Where should I post them for posterity? Where is the mailing list? Is there an IRC channel? Is there a wiki? Is there a bug-tracker? Is there a public version-control archive? Where are all of these things? No. Just email your patches to Marcus Bauer. Expect no reply nor use of patches. But, you don't have the right to complain. You have the right to fork, though. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MC Navi
On Thursday 01 April 2010 10:31:12 Mike Crash wrote: Hello, I'm going to release new version of MC Navi and I want to make maps available for direct download. So I want to ask, what country do you need? Second question - what do you prefer, car navigation or outdoor navigation? Just to know, what to do next... Netherlands, car please :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-t] Big update, safe or not ?
On Thursday 18 March 2010 15:34:42 n...@el-hennig.de wrote: But today I've tried an 'opkg update' and now I see : $opkg list-upgradable | wc -l 682 Will such a big upgrade be ok or do I have to wait until Sunday (more time to fix borken things) ? You should consider to upgrade in more than one step, as space in /tmp is limited. Or simply create a tempdir on the SD card and upgrade using opkg -t /media/card/tmp upgrade ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-t] Big update, safe or not ?
On Thursday 18 March 2010 17:17:21 Martin Jansa wrote: On Thu, Mar 18, 2010 at 05:14:08PM +0100, Sander van Grieken wrote: On Thursday 18 March 2010 15:34:42 n...@el-hennig.de wrote: But today I've tried an 'opkg update' and now I see : $opkg list-upgradable | wc -l 682 Will such a big upgrade be ok or do I have to wait until Sunday (more time to fix borken things) ? You should consider to upgrade in more than one step, as space in /tmp is limited. Or simply create a tempdir on the SD card and upgrade using opkg -t /media/card/tmp upgrade or permanentrly update tmp_dir option in /etc/opkg/opkg.conf for better location if default /var/lib/opkg/tmp doesn't suit you Solutions above in increasing level of convenience :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MC Navi released
Hi All, I made a quick untested binary package for SHR-T, and I gotta run now so I can't test myself, but maybe it's of use to someone. see http://3v8.net/~sander/openmoko/mcnavi_0.2.4-r0.4_armv4t.ipk grtz, Sander On Friday 12 February 2010 22:37:16 Mike Crash wrote: Omlouváme se, ale tato sekce je p#ístupná pouze pro administrátory There is a flag to switch to english language on gps-routes.info Failed to fetch http://www.gps-routes.info/debian/pool/main/m/mcnavi/mcnavi_0.2.4.dsc Hash Sum mismatch Failed to fetch http://www.gps-routes.info/debian/pool/main/m/mcnavi/mcnavi_0.2.4.tar.gz Hash Sum mismatch I have uploaded dists directory to wrong directory on ftp server (to dists itself), so it doesn't match, I have fixed it and it should work now Is there any opkg of your program fot trying it on SHR? For SHR I have no binaries, it needs to recompile with different libraries. I work on Debian so I provide only Debian packages. I can't install it on qtmoko: You need E17 EFL's, it will not work on qtmoko Do you use the same bin format as navit? No, I'm using different, because it works entirely different than navit. It was my first attempt to speed up navit, but I have gave up - hard to change other's code ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth PBAP support for FSO
So is someone out there who owns a handsfree, car or sth else that supports showing contacts and/or missed calls over bluetooth? Anyone with a TomTom. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: [Shr-User] What's going on in SHR land
Thanks for the update! Ever since I saw that the SHR feeds didn't get updated for a while I compiled SHR myself from the shr/import branch, so I already knew that there was a lot of activity going on under the radar. For me the usage of opimd for contacts is the nicest new feature. It has a VCF backend, so I could just scp my Kaddressbook contacts over to the FR and have all my contacts available. nice! Graphic speed felt a little slower though, and the interfacing with FSO was broken in some places, like the power management. Also the power button didn't bring up the popup menu. But these are all findings of a few weeks back, so most will probably be long fixed already. Thanks again, looking forward to the next stable unstable release of SHR! grtz, Sander On Sunday 01 November 2009 17:04:30 Thomas Zimmermann wrote: For the SHR users that aren't reading the SHR mailing lists i'm forwarding this message from spaetz: Betreff: [Shr-User] What's going on in SHR land Datum: Sonntag 01 November 2009 Von: Sebastian Spaeth sebast...@sspaeth.de An: shr-de...@lists.shr-project.org, shr-u...@lists.shr-project.org Hi all, for those of you few that do not live 24/7 in IRC land, here is a not-so-brief update on what is happening in SHR land. No, we are not all dead :). There are a couple of major transitions that have slowed down new images or indeed any updates in the SHR feed. Let me try to sum up a few and I am sure others will chime in and list whatever I have forgotten: - Transition from the obsolete kdrive-glamo driver to a proper xorg server infrastructure. This took some time, but it appears that it is working fine now. Don't expect any (initial) performance boosts, but being on a regular xorg server and having a driver that is actually being developed and maintained is a good thing for the future (thanks to Weiss and others for some really hard work here). - More fso...d goodness. Rather than having Mickey Lauer's python prototyped phone backend, we are starting to his re-written bits and pieces (coded in vala, which should give us a nice performance boost over python). For the beginning we have the resource handling (fsoresourced) on board and look forward to the next bits and pieces. I know very little about the state of things here, so others might have more information. -New phone apps: As if that were not enough changes, the core team (mrmoku, tasn, dos1, and others?) has started to redevelop the frontend applications for SHR. the old ophonekitd was initially developed by a guy called quickev who has been missing in action since quite some months now. Don't ask ME why, but apparently the now design allows for better/quicker/whatnot development. I'll let one of them speak out for themselves about the motivations. Besides lots of work,this gives us also a chance to redesign the screens and make the UI better. So goodbuy ophonekitd and libphone-efl, welcome phoneui, and libphoneui-shr. -Bernd Prünzler(spelling?) is kind enough to help out with some theme development (BTW, you did know there is a theme contest going on, do you? So, go and design and submit something already!). The default theme has been designed for powerful desktops, and is using more transparency and other fancy stuff than the slow graphics can do. He is developing a theme that should be much faster on the Freerunner (but don't expect miracles, the hardware will still be barely able to drive a full VGA-resolution screen). So expect a big fight between dos1 (niebee theme) and bernd (gry theme) for the fastest performance (while retaining good looks). Last but not least: what we had done the last few months, is basically taking a fork of OpenEmbedded and developing from that. While this gave us the stability to code apps without having others break our stuff (we are quite capabable of doing that ourselves it seems :-) ), this led to a quickly diverging SHR and OE tree. It was decided that we really should include our stuff into OpenEmbedded proper, rather than just doing our stuff in parallel. So we had first put all the stuff into an SHR/import git tree which is in the openembedded code repository. Next, mrmoku created the shr/merge tree which is kept in sync with the OpenEmbedded tree and we ported all our enhancements there. The plan is to take our bits and pieces from here and merge them into OE over time. This is where we currently stand, we want to keep using the shr/merge tree which gives us a current OE tree, but of courseby using more updated components, lots of stuff was broken. The guys have fought really hard in the last days (and weeks) to overcome compilation errors, nonbooting phones, and crashing components. It seems we are now really close. The new images compile fine (yay!), the phone actually boots, and many of the crashes have been eliminated. AFAIK, we are currently still stuck with a segfaulting dbus. As soon as these
Re: Thanks for good work on the WIFI driver
Yeah, I haven't seen SHR-U updates for a while. Helge, is this with a self-built image? grtz, Sander On Wednesday 14 October 2009 17:20:56 Martijn van den Broek wrote: Is that kernel the one from first of september from below? http://shr.bearstech.com/shr-unstable/images/om-gta02/?C=M;O=D Or is there a more recent kernel available somewhere? On Wed, Oct 14, 2009 at 1:29 PM, Helge Hafting helge.haft...@hist.nowrote: Wifi used to be very unstable and quirky, but is much improved now. (I use the latest shr-unstable kernel) I can now run a script that powers up wifi, loads the kernel driver module, and then runs wpa-supplicant and udhcpc. And it works - everytime! I can even suspend and resume, and wpa-supplicant keeps managing the connection after resume. I had to restart udhcpc, but that is of course not a driver problem. Helge Hafting ___ 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: USB networking with Ubuntu 9.04
Why use a script that you need to run manually each time?
It can be done automatically just by putting the right stuff in
/etc/network/interfaces:
auto eth2
iface eth2 inet static
address 192.168.0.200
netmask 255.255.255.0
post-up iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE
post-up echo 1 /proc/sys/net/ipv4/ip_forward
post-up route add -host 192.168.0.202 dev eth2
post-up dnsmasq
pre-down echo 0 /proc/sys/net/ipv4/ip_forward
pre-down iptables -t nat -D POSTROUTING -s 192.168.0.0/24 -j MASQUERADE
pre-down killall dnsmasq
when you plug in the FR, eth2 will activate automatically..
grtz
Sander
On Thursday 08 October 2009 03:24:06 Cristian Gómez wrote:
Hi Tony, thanks for giving a try to the script. I'm glad it helped you. I
just create a sub-section on the wiki page [1] where I put the script to
help others to get connected easily.
Cheers
[1] http://wiki.openmoko.org/wiki/USB_Networking#Connection_Script
/***
* Don't Worry...Be Linux
* Cristian Gómez Alvarez
* Ingeniero en Sistemas y Computación
* Universidad de Caldas
* Comunidad de Software Libre Manizales
* IEEE/WIE Student Member
* Linux User #463617
* Mi Blog: http://cristianpark.sehablalinux.com/
/
2009/10/7 Tony Berth tonybe...@googlemail.com
On Wed, Oct 7, 2009 at 10:27 AM, Matthias Huber
matthias.hu...@wollishausen.de wrote:
Tony Berth schrieb:
Bingo. Thanks A LOT!
Is it possible to update the Wiki with that one. I think this will be a
great help to the whole community
if you would tell me wich of / or both tricks did it on your system ?
but i had to add this two lines to my /etc/ufw/ufw.conf
ufw allow from 192.168.0.202
ufw allow to 192.168.0.202
another trial with iptables needs to load some modules too:
#!/bin/sh
MOKO=192.168.0.202
echo 1 /proc/sys/net/ipv4/ip_forward
modprobe ipt_MASQUERADE
iptables -I FORWARD -j ACCEPT -d ${MOKO}/32
iptables -I FORWARD -j ACCEPT -s ${MOKO}/32
iptables -I POSTROUTING -t nat -j MASQUERADE -s ${MOKO}/32
what works was the script Cristian Gomez included in his reply!
Just for the records, the first time I run that script it does assign the
192.168.0.200 IP to eth1 but can't ping/access 192.168.0.202! Then:
- I disconnect Openmoko
- connect it again
- re-run the script and voila the connection is there!
Thanks
Tony
___
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: [SHR testing] intone requires different e17 lib name
On Saturday 22 August 2009 21:02:22 Sebastian Krzyszkowiak wrote: On 8/22/09, Marcel tan...@googlemail.com wrote: Am Samstag, den 22.08.2009, 20:48 +0200 schrieb Sebastian Krzyszkowiak: On 8/22/09, Marcel tan...@googlemail.com wrote: G'evening, I'm fiddling with SHR (some way to get paroli on it? .) and found that the opkg.org intone 0.66 package is linked against libe*-ver-svn-02.so.0 sonames but SHR testing contains libe*-ver-pre-01.so.0 libs. Could you do another special SHR testing build? (Symlinking all of them to -svn-02 is another solution, but kinda messy, too...) -- Marcel Could you use supported distro? SHR unstable is the way to go - it works even more stable than testing. And Intone is there by default :P SHR testing is unsupported, but unstable is? And the latter even more stable than testing? You SHR folks are strange... Okay, lemme reflash... There are just too less hands to work, and maintaining -testing is hard work. We hope to release new testing image soon, and support it constantly. But noone knows when it'll finally happen... Why not just ditch the current testing and stable branches and branch anew from unstable? This just keeps tripping up newcomers to SHR (I have seen at least 10-15 of these mails in the last few months?). At the very least, remove those branches that shouldn't be used right now anyway. Of course I agree that it's a lot of work to maintain multiple branches, but the least that should be done is to avoid partial merges (which takes effort) and instead do full merges (essentialy copies) from unstable revisions that are 'known to be good' (or as good as possible :). This way users (non-devs) can keep pace with recent fixes while at the same time avoiding the occasional breakage that occurs in unstable. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR testing] intone requires different e17 lib name
On Sunday 23 August 2009 21:09:04 Sebastian Krzyszkowiak wrote: On 8/23/09, Sander van Grieken san...@3v8.net wrote: On Saturday 22 August 2009 21:02:22 Sebastian Krzyszkowiak wrote: On 8/22/09, Marcel tan...@googlemail.com wrote: Am Samstag, den 22.08.2009, 20:48 +0200 schrieb Sebastian Krzyszkowiak: On 8/22/09, Marcel tan...@googlemail.com wrote: G'evening, I'm fiddling with SHR (some way to get paroli on it? .) and found that the opkg.org intone 0.66 package is linked against libe*-ver-svn-02.so.0 sonames but SHR testing contains libe*-ver-pre-01.so.0 libs. Could you do another special SHR testing build? (Symlinking all of them to -svn-02 is another solution, but kinda messy, too...) -- Marcel Could you use supported distro? SHR unstable is the way to go - it works even more stable than testing. And Intone is there by default :P SHR testing is unsupported, but unstable is? And the latter even more stable than testing? You SHR folks are strange... Okay, lemme reflash... There are just too less hands to work, and maintaining -testing is hard work. We hope to release new testing image soon, and support it constantly. But noone knows when it'll finally happen... Why not just ditch the current testing and stable branches and branch anew from unstable? This just keeps tripping up newcomers to SHR (I have seen at least 10-15 of these mails in the last few months?). At the very least, remove those branches that shouldn't be used right now anyway. Of course I agree that it's a lot of work to maintain multiple branches, but the least that should be done is to avoid partial merges (which takes effort) and instead do full merges (essentialy copies) from unstable revisions that are 'known to be good' (or as good as possible :). This way users (non-devs) can keep pace with recent fixes while at the same time avoiding the occasional breakage that occurs in unstable. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community There were tons of mails discussing how we should do testing and stable. On every possible maillist... And everything is discussed. To death. There was one brave enough, mrmoku (he's on vacations now), but he was doing it alone and he didn't finished yet (but i think we're close to). Unfortunately most of SHR devs are Python, C or Vala coders, not bitbake gurus :( I'm not reopening the discussion on that. But I think the stable and testing branches, images and feeds should go, because nobody uses them now (correct me if I'm wrong) and they basically lead to confusion. And I understand fully that there's just not enough manpower to maintain them actively, but then just accept that the only real flavor offered right now is the unstable branch. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Sunday 23 August 2009 09:36:44 Cristian Gómez wrote: Hi all, I were following this thread and I think that the most remarkable post is this one from Martin who resumes the most important things that we want to have in the showroom page. I made this Classes diagram [1] in DIA to make the basis for the development of the site. It's really basic but I think that it's a start point. I'm missing the cardinality and direction in the relations. Second, you should add a Release class (one-to-many) to distinguish versions of applications. Also abstract the File class to a Resource class (You can then subclass File from Resource to specialize), this allows you flexibility in the resource type (which could be a screenshot, like you modeled, but also for example a howto, FAQ, homepage whatever). Application has no 'belongs to' relationship to Distribution. Instead, Distribution has a 'provides' relationship to Application. The Application attribute 'multiplatform' is useless. 'provedOn', 'notWorkingOn', 'distribution' are all one-to-many associations and should be modeled in the diagram. 'author' should be a list or even an association, not a string. popularity is a derived attribute (pun intended) grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-testing] problem connecting to pc, and solution
On Sunday 19 April 2009 18:52:29 Previdi Roberto wrote: - if i set a different mac address for each one of my om distributions, could i assign a different ip address (from my pc side), in order to not have all the ssh key conflicts each time i reflash or just change my fr running distribution? i think it's matter of writing some configuration rules for ifconfig, but is there some example around? Why fiddle with the MAC address if you can give each distro a different IP address directly, in /etc/network/interfaces on the phone. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtExtended] latest andy-tracking kernel
On Tuesday 14 April 2009 21:54:53 Franky Van Liedekerke wrote: Maybe the latest version is ok again, but it is IMPOSSIBLE TO TEST since ssh no longer works. Surely somebody must notice this, or is nobody even using these images? Yeah I noticed too, but I assumed I b0rked my build system, since I tried to use the SHR overlay manually.. also, X didn't start anymore, that's when I noticed SSH didn't work. but, while waiting for the entire rebuild to finish, I'm taking a look at the commits since April 4 :) grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: IPv6 for minimo
wget http://www.ginguppin.de/files/minimo.tar.bz2 that would be mine :-) it's built a long time ago and i don't really recall what options i used. since i don't use opkg anymore, but debian, there's no chance it will ever be updated -- i removed the oe stuff from my pc and use either debian packages or build my own. you'd better look for dillo or midori, i don't even know if there's any development still going on with minimo. Hi, A week or so back I built a Minimo package for FSO and submitted it to opkg.org. I don't know if it has IPv6 support and it'll probably complain about dependency version numbers if you're on OM2008.x, but you could try to install it with -force-depends and see if it works. If it has no IPv6 support then let me know and I'll have a look at building a new package. Also be aware that Minimo has no bookmark management, which kinda sucks grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Allegro the game library
Hi, As some of you may know, there's a game library called Allegro. It includes support for graphics (3d, but not accelerated), sound, keyboard, mouse, etc. It works, among others, on Linux using xorg for graphics. Long time ago I've written a game that uses it, and I think this game would be really cool played on the GTA using accelerometers. I'm thinking about porting it, but I don't really know where to start with porting Allegro. Any hints on how to do this and how hard it might be? I've never done any development for GTA, hence this question. The main problem I think will be the floating point calculations, as it does 3d and sound, and armv4 has no floating point support... grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Has anyone tried Qi?
No DFU capable USB device found Can you please tell me how to transfer the boot loader and the kernel to the NAND? not the slightest clue, what you are talking about :-), but i think you can give the device id (see lsusb), too, to dfu-util. dfu-util should autodetect all DFU capable devices, so if it doesn't find one it is probably not DFU capable. I noticed this because my usb sound card was brutely reset when I tried to flash the FR ;) grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?
Hi, Fox Mulder quakem...@gmx.net writes: Paul Fertser wrote: Sander van Grieken san...@3v8.net writes: So the question is, when will the default kernel be replaced by the new 2.6.28 andy kernel so that userspace tools could be adapted to it? That would be my question as well. I only care for userspace to be adapted to test the suspend/resume functionality (on FSO, only frameworkd?). frameworkd newer than 31 Dec should properly support both kernels. I'm afraid it's not included in any images yet (please correct me if i am wrong). Latest fso-frameworkd in debian is 0.8.4.3-20081215-1 which is older than 31 dec i would guess. I hope a new version comes very soon so i can try to change from 2.6.24 to the new 2.6.28 kernel. :) Actually, you can try to change from 2.6.24 after applying an ad-hoc patch from http://trac.freesmartphone.org/ticket/293 even on old version that's provided by Debian (that's exactly what i did a month ago). Aah exactly what I was looking for, thanks Paul. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?
On Monday 05 January 2009 15:29:54 Fox Mulder wrote: David Garabana Barro wrote: On Monday 05 January 2009 14:45:26 Fox Mulder wrote: Hi all, many mails i read in the kernel mailing list show that newer patches should only be applied to andy-tracking kernel and no more to the old 2.6.24 om kernel. I forgot to say Please, try it and let us know if it solves also your problems. :) You mean i should try the never deep sleep thing? If you give me a hint how to activate this feature i will try it. But i have to say that most times i tried suspend zhone was not running and therefore my gsm wasn't activated. I see the same behaviour: suspend just after resume works, but if the FR is suspended for a longer time it does not always resume and the screen stays black. I have no SIM inserted so it should not be a Calypso problem. I was looking at the WSOD bug thinking it might manifest itself differently because I have no SIM, but I still have to check if ssh-ing works when this occurs. So the question is, when will the default kernel be replaced by the new 2.6.28 andy kernel so that userspace tools could be adapted to it? That would be my question as well. I only care for userspace to be adapted to test the suspend/resume functionality (on FSO, only frameworkd?). If one of the devs could give some pointers on what should change I can have a go at it :) grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[FSO/Illume] Program icons not showing up (FIXED)
On Monday 29 December 2008 12:13:14 Sander van Grieken wrote: On Sunday 21 December 2008 09:37:36 Ingvaldur Sigurjonsson wrote: Carsten Haitzler (The Rasterman) wrote: On Sat, 20 Dec 2008 23:01:51 +0100 Michael 'Mickey' Lauer mic...@openmoko.org babbled: This always happens when we're starting to stabilize for a release. Last time it was something with a missing mimetypes postinst. Raster, any idea what it can be this time? icons display for me on my illume images, on desktop etc. etc. - so i'm on the works for me bandwagon (thus not answering these as i have no 'why' as i never saw it break). svnr37919 is the last svnr i built with OE I'm having problems with the 'e-wm - 0.16.999.050+svnr37988-r0' build. FYI, I just tried EFL revision 38352 (instead of org.openembedded.dev's 37988) in sane-srcrevs.inc, rebuilt, reflashed rootfs, and that solves the icons issue. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/Illume] Program icons not showing up
On Sunday 21 December 2008 09:37:36 Ingvaldur Sigurjonsson wrote: Carsten Haitzler (The Rasterman) wrote: On Sat, 20 Dec 2008 23:01:51 +0100 Michael 'Mickey' Lauer mic...@openmoko.org babbled: This always happens when we're starting to stabilize for a release. Last time it was something with a missing mimetypes postinst. Raster, any idea what it can be this time? icons display for me on my illume images, on desktop etc. etc. - so i'm on the works for me bandwagon (thus not answering these as i have no 'why' as i never saw it break). svnr37919 is the last svnr i built with OE I'm having problems with the 'e-wm - 0.16.999.050+svnr37988-r0' build. I've been trying both fso-testing and fso-unstable, same results. Editing the .desktop files and removing all 'Name[xx]=...' did not help either. I even made sure there was only one line containing 'Categories=' (some with multiple values, separated by ';') to no avail. I'll continue to harden some bolts and loosen up some screws so I will report if I make any progress. Did you make any progress? I have the same problem. Also tried tweaking the .desktop files but no luck so far. I do get these errors in /tmp/x.log EDJE ERROR: file /usr/share/enlightenment/data/themes/illume.edj, group e/modules/kbd/base/default has a non-fixed part. add fixed: 1 1; ??? Problem part is: e.text.label Will recalc min size not allowing broken parts to affect the result. and K! 2 borders with same client window id in them! very bad! optimisations failing due to bizarre client behavior. will work around. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openttd is now in opkg.org!
On Sunday 07 December 2008 13:30:14 Robert Schuster wrote: Hi Aapo, Aapo Rantalainen schrieb: Openttd is now in opkg.org! I would like it better if the bitbake recipe changes can be moved into OE. That's theory. In practice, you submit the recipe plus patches in OE bugtracker and then it's forgotten about. I submitted 2 games there a couple of months ago and they're still not merged, and thus not available to the openmoko community, except in binary form from opkg.org I'd say, submit new recipies to the OM bugtracker instead of OE, maybe there's more chance they'll get merged. -Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: new Game for freerunner: xlogical
On Thursday 13 November 2008 13:45:28 Aapo Rantalainen wrote: c) dependeries: libsdl-image-1.2-0 my package: Depends: libsdl-1.2-0 (= 1.2.9), libsdl-image-1.2-0 (=1.2.3-r0) your package: Depends: libsdl-1.2-0 (= 1.2.11), libc6 (= 2.6.1), libsdl-image-1.2-0 (= 1.2.6), libsdl-mixer-1.2-0 (= 1.2.6), libstdc++6 (= 4.1.2), libgcc1 (= 4.1.2) Hmm I cannot set a runtime dep on older versions; the dependency on older versions in a bitbake recipe is only used at compile time. The package it produces still automatically creates a dependency on the version it was compiled against. This is the problem with posting binary packages. I compiled it using org.openembedded.dev branch, which uses a newer version of SDL than org.openmoko.stable So I'm not going to fix this. if you want to create a openmoko-stable compatible package you can use MokoMakeFile and use the recipe from http://bugs.openembedded.net/show_bug.cgi?id=4822 grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: new Game for freerunner: xlogical
Hi All, I just finished the recipe for Xlogical based on Aapo's patches and while we wait until the recipe gets merged to OE/OM, I've put a binary package online for you all to enjoy. I added music, sounds and a wrapper script that rotates the screen to landscape. Right now the music is enabled by default, but I can disable that if that is unwanted behaviour. package is here : http://3v8.net/~sander/openmoko/xlogical_1.0-8-r0.1_armv4t.ipk Let me know what you think. grtz, Sander On Friday 07 November 2008 13:47:16 Aapo Rantalainen wrote: I'll try to create a bitbake recipe for it so it can track the distro(s). Good Did you disable the sound because it was choppy? (like I experienced with Pingus) I did't even test sounds. I think games played on phone should be silent. (If somebody wants musics and sound effects, It can be default disabled, but player has option to enabel it.) -Aapo Rantalainen ___ 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: KDE4 on openmoko?
On Sunday 02 November 2008 07:59:14 Pietro m0nt0 Montorfano wrote: Leonti Bielski ha scritto: Hello! I've just seen this screenshot on scap.linuxtogo.org: http://scap.linuxtogo.org/files/a4100c3bb6a5f2c7d9789da03fc2caa3.png How does it work? Is speed acceptable or not? Thanks. Leonti No speed is not acceptable, is fun to show your FR to your linux friend saying hey i've got kde4 on my phone!! but if they ask you to open the menu or to start something, the magic is gone. It tooks about 6-7 mins to start kde and don't try to do anything at all if you don't want to wait for a long long time :D Those times are greatly exaggerated, or you've done something seriously wrong. Even on my 'old' neo1973 it took less than a minute to fully start plasma, and while slow, I think for many things the speed was quite acceptable on a neo freerunner. Running a full kde session (with kwin as window manager) doesn't make any sense anyway on such small screens, as kwin was never designed for something like that, but just running kde applications works quite well. Plasma would be great on the FR IMHO, and I wanted to experiment with that, but unfortunately qt4 doesn't yet build using openembedded. I also am unable to do a succesful build of FSO since upgrading to ubuntu 8.10. gcc-4.3 is unable to build OE's gcc-native, and after switching to gcc-4.2 I cannot get past compiling qemu-native. using ubuntu-provided qemu instead results in a crash. sigh. Very demotivating. Hope this will be fixed soon. Anyone else experiencing this in Ubuntu 8.10? grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Pingus ported
Hi All, I'm glad to report that I've managed to port Pingus, the free lemmings clone, for OE based distributions (it was already available on Debian). I have submitted the bitbake recipe and patches to Openembedded, but there's no need to wait while these trickle down the various branches. I have created the binaries for you. On both FSO and OM2008.8 you can install http://3v8.net/~sander/openmoko/libboost-signals1.33.1_1.33.1-r3_armv4t.ipk http://3v8.net/~sander/openmoko/pingus_0.7.2-r0_armv4t.ipk Also libpng3 must be installed, but I haven't been able to get the dependency right, so you'll need to do that manually. Note: for OM2008.8, you need to have the testing feeds to get recent enough SDL packages. more information is at http://wiki.openmoko.org/wiki/Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] Still no resume
2008/10/1 Sven Bretfeld [EMAIL PROTECTED] Suspend is broken again in the latest fso kernels. But with the latest openmoko kernel suspend works. But zhone is reacting a bit weird after resuming. ;) Do you know if they are different kernels, or different version of the same kernel tree? the latter. FSO has not yet bumped its SRCREV to point to the latest patch that fixes resume (hint!) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Looking for Debug board owner in The Netherlands
Hello, My FR suffers from the factory defect that my NOR is blank. I need a debug board to program it which I don't have and don't want to pay â¬100 just to use once. I am looking for someone who can help me, preferably around Eindhoven. Here is the deal: - I bring my FR, laptop and necessary software. - You bring the board. - I treat you a lunch while we flash my NOR. There's a 50/50 chance I'll be in Eindhoven next friday. mail me thursday/fridaymorning Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Ian-3 wrote: Qtopia sux, it's ugly and not pratical. We need absolutely the FSO with dialer, sms and contacts ( instead of zhone ) or SHR. I think Qtopia is beautiful and the most practical at the moment. But my biggest gripe is that it's not customizable and has no open development model. I agree that FSO provides the best foundation. I'd like to see a (non-nokia/tt) Qt based UI on top of that. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian/gta02v5] zhone suspend not working anymore
On Monday 29 September 2008 17:38:39 Thomas White wrote: On Mon, 29 Sep 2008 16:52:48 +0200 Fox Mulder [EMAIL PROTECTED] wrote: Since over a week suspend isn't working anymore for me. Perhaps this could be related to the recent re-opening of ticket #80: https://docs.openmoko.org/trac/ticket/80 - which reports problems with the wakeup reason stuff? I was previously using a (self-compiled) kernel built from the 'stable' git.openmoko.org kernel branch, revision a1e97c611. Last night I updated to a kernel built from the latest revision (968c41d0c), and I had similarly serious suspend problems (didn't seem to wake up at all). As far as I know, the latest OM kernel is still a1e97c611. So, on the (tenuous) assumption that all the problems described here are the same regression, I suspect either fix-one-mmc-race.patch or fix-glamo-idleclock-around-suspend.patch of breaking things. These are the two commits between a1e97c611 and the revision described in ticket #80 as causing trouble (ca19d1564). It isn't the idleclock-around-suspend patch. I tested that a while ago on FSO without any suspend/resume issues. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] How to develop with Qt
Hi Erin, Can I find these patches somewhere in a bugreport? Or do I have to wait 'till they trickle down through git? Sander On Sunday 28 September 2008 10:53:51 Erin Yueh wrote: Hi Nicola, I've sent some patches to our distro team and OE can use bitbake to build the latest qt4-x11-free to version 4.4.1. Since people from community like to try qt4 new features, I will send an email to our distro and they would help to put these packages to our feed. Then you can install them from installer, no need to build it by yourself. Also, not sure what you are interested in qt4? i am trying webkit features by python-pyqt. --Erin Nicola Mfb wrote: [] I'm still trying to get a working and safe oetree with qt library inside :). The first time i tried with the org.openembedded.dev branch and my typical angstrom configured local.conf file, but it got a compilation error on uicmoc4-native. After that i tried with the fso openmoko conf file, it failed again but i noted that the preferred version of qt4 there was 4.3.3 instead of 4.4.1. http://4.4.1. I remembered that in org.openembedded.stable there was 4.3.3 version, so i tried again with the stable branch. It compiled fine but did not create all the requested ipk (empty). I managed a bit on the qt_packaging.inc recipie and finally i got a working qt-oe-tree, i was able to compile a my application too. I bitbaked the last fso unstable image and flashed the phone with it, setupped a fake feed server on my oe tree, added it to feeds on the phone and did opkg update, opkg install qt4-x11-free, opkg install my-application, and after that i was able to start it adding a simple DISPLAY=:0. But i'm not very happy of this as it's not simple and i do not like to mix different branches. Please share your experience on this... Regards Nicola ___ 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: Debian fails to boot after some reboots
There is a problem with suspending causing the partition table to be corrupted on the SD card. There are some workarounds that seem to prevent this from happening, but I don't know whether they apply to Qtopia. See http://docs.openmoko.org/trac/ticket/1802 Yes this applies to all distributions. Once distributions will ship a kernel with this patch below, it should no longer be necessary to create the suspend and resume scripts anymore.. http://git.openmoko.org/?p=kernel.git;a=commit;h=ca19d156400f817960efe0d14680324b2ea34171 If you build your own image using MokoMakeFile you can define a more recent revision for linux-openmoko in conf/distro/include/sane-srcrevs.inc, otherwise you'll have to wait until OM bumps the rev on linux-openmoko for you. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Several stacks on one card
On Wed, Sep 3, 2008 at 5:04 PM, [EMAIL PROTECTED] wrote:
Hello, I am going to buy a new microSD card. I want to install Debian,
Qtopia and whatever other image appeals me.
Is it possible to make a dual-boot in the card?
Something like first a selecting if you boot the flash or the card, and
later wich partition in the card you boot.
Have I explained me?
Everything is explained on the wiki (partitionning, u-boot entries, ...)
http://wiki.openmoko.org/wiki/Booting_from_SD
I have created 2 ext2 partitions on the SD for both ASU and FSO, and modified
the uboot
menu to boot their kernels directly from ext2 (so no need for a separate FAT
partition).
Something I noticed is that these partitions have to be in the beginning of the
SD card.
I wasn't able to boot from partitions starting at the 7GB mark.
This reminds me of the old BIOS limitations on PCs and I didn't expect that to
be the
case on the freerunner :)
I don't know the exact bootable boundary, but with two partitions of 256M at the
beginning of the SD card I can boot into both ext2 filesystems.
Anyway, I used this u-boot menu on the NAND:
menu_1=
Boot from microSD (FSO/partition 1):
setenv bootargs
${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5
${mtdparts} ro;
mmcinit;
ext2load mmc MMC_NUM:1 0x3200 /boot/uImage;
bootm 0x3200
menu_2=
Boot from microSD (OpenMoko/partition 2):
setenv bootargs
${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5
${mtdparts} ro;
mmcinit;
ext2load mmc MMC_NUM:2 0x3200 /boot/uImage;
bootm 0x3200
Sander
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Fwd: Re: Building for FSO
.. forgot the list :) .. --- Original Message --- Subject: Re: Building for FSO From:Graeme Gregory [EMAIL PROTECTED] Date:Thu, August 28, 2008 12:00 To: Sander van Grieken [EMAIL PROTECTED] On Thu, 28 Aug 2008 11:48:01 +0200 (CEST) Sander van Grieken [EMAIL PROTECTED] wrote: On Thu, 28 Aug 2008 14:42:19 +0530 sparky mat [EMAIL PROTECTED] wrote: How do I build applications for FSO? Is it the same as mentioned in http://wiki.openmoko.org/wiki/Toolchain ? What about the GTK+ libraries? Are they available? Specifically, I am wanted to compile Claws Mail, Ice Weasel and Pidgin for FSO Milestone 2? Isn't it feasible to do so? If you use OE to build then these applications are already in OE and simple to build. http://wiki.openembedded.net/index.php/Getting_Started If I understood correctly MokoMakeFile also has support for FSO? There are 3 variables that can be uncommented to switch to OE.dev (the openmoko ones should then be commented of course). Does this work? Is this supported? Yes that should work perfectly, my lack of sleep made me forget all about MokoMakefile. Graeme ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU - out of memory?
On Friday 22 August 2008 02:59:25 Carsten Haitzler wrote: On Thu, 21 Aug 2008 19:54:26 +0200 Sander van Grieken [EMAIL PROTECTED] babbled: For a phone, the algorithm could be as simple as killing the process that has allocated the most memory. The essential system services and the basic UI applications usually have a small footprint, and the biggest consumer of memory is most likely a leaky UI app that's not part of the main system anyway. For a production server with large databases this doesn't work of course, but there you're already in big trouble if you have to fallback on the oom-killer. true - and the kernel oom killer should mostly handle this, BUT it is possible to do better. a userspace oom killer can trawl all .desktop files and thus know if the app is run by a user (base on command), or if its a system app that can be run, or if its installed later etc. etc. such a userspace oom isn't hard to do. it's pretty simple. Problem is, your might not have the memory to trawl those .desktop files. What about a malloc that's LD_PRELOADed in front of non-essential apps, that enforces a 5-10% available memory for essential system and phone apps? (or maybe some other hook mechanism if preloading is not feasible) Of course there also should be such wrappers for delegated allocators like the X pixmap example your mentioned earlier. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU - out of memory?
Tilman Baumann [EMAIL PROTECTED] writes: all the linux memory overcommit behaviour more or less depends on the fact that it can allways save it's ass by using swap. (Instead of helplessley crashing) Yes, or killing the application. Not having swap is nonsense;). If you are using swap something is wrong, right, but then you fix it. I find it strange that the debian install didn't make a little swap partition. How is having 256MB RAM without swap any different from 128MB RAM with 128MB swap? It's still 256MB (virtual) memeory in total. In other words, even WITH swap you dont solve the problem, you only postpone any problems until later, AND you lose some flash/sd storage room for swap permanently. It only makes sense to allocate swap if you know beforehand you'll need more than the available RAM. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU - out of memory?
On Thursday 21 August 2008 19:33:24 Steven Kurylo wrote: And come on. Software is not perfect. Sometimes we have to live with a dreamteam like (old) firefox and x11. I had times when they had both hundreds of megs virtual mem. But everything was fine because it all was just harmlessly been swaped away. I restarted them every weekend to not let it become worse. Not ideal, but should the system rather be unusable in this condition? You're assuming the system will be usable when an application misbehaves and 50mb gets swapped out. On a desktop, sure your points are valid. I'm not sure this is true on Freerunner. None of the embedded systems I've used have had swap. What happens when you haven't received a call for several hours and the application you're using forces it to swap out? Can you still answer a call in time? Exactly. I'd rather see a smart oom killer which will only kill non-essential applications. Adding 128mb of swap just pushes the problem back and slows down the entire phone. For a phone, the algorithm could be as simple as killing the process that has allocated the most memory. The essential system services and the basic UI applications usually have a small footprint, and the biggest consumer of memory is most likely a leaky UI app that's not part of the main system anyway. For a production server with large databases this doesn't work of course, but there you're already in big trouble if you have to fallback on the oom-killer. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FR at golem.de
On Wednesday 06 August 2008 15:19:32 Michele Renda wrote: I think that before to test something you must to know what are you testing. You can not to test a phone and than to say: Oh... it is stupid, it is not able to prepare me a coffee :) OM is just not there yet. Be fair, no excuses please :) *ducks* ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: bitbake and patches
On Wednesday 30 July 2008 13:29:26 Michael Kluge wrote: Hi, I am trying to create a bb recipe. I check out the sources I need per svn and need to apply some patches afterwars (copying files over to the svn tree). The patches (=new files) are sitting side by side within the same dir as the bb file. During do_patch there is no pointer to the directory with the bb files. How do I get my patches to the destination path with do_patch() ? I think you must create a real patch using diff. And you dont need an absolute path, the patch only needs to be relative to the code tree's root. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On 7/30/08 Jay Vaughan wrote: If you go read Morse Peckham's book http://www.amazon.com/Mans-Rage-Chaos-Biology-Behavior/dp/080520142 You will understand how museuems and gallery's function; and, Sean's words will strike you more deeply. Its all well and good when you're dealing with art students, but when you hope to sell 1,000 Freerunners as the base hardware platform for a multinational operation, it doesn't sell too well. Yes Jay. That is exactly the goal of this company. Sell 1,000 phones. They we all can retire. Come on now. If OM can only respond with hostile ad hominems to IMHO valid critisism, then I fear for the life of this 'community'. Without solid leadership this community will fragment (which, to some degree, it already has) and lose momentum. And that is hard to regain. And to stay with the museum/gallery metaphor; If you don't use high quality paint and canvas, it'll all fade away quickly. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
could anyone recommend a nice solder for such kind of work? (haven't bothered to buy one in the states... in ukraine at the university was using whatever was given ;-)) You will need 'flux core solder' (normal 'resin' electronics solder), with a low wattage soldering iron, like 15W. It also helps to apply the solder to all contacts first, before putting the capacitor in place. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: order from Pulster
Hallo, my excuses to each of you waiting for his order to be confirmed. Hehe I guess you mean 'apologies'? I know in german or dutch excuses means apologies, but in english it means something else, which might pzz off ppl :) We still work hard to come back to each of you. Anyway feel free to send another mail asking about the status of your order, I will check and come back in time now. Everybody who made an order based on our initial special offer of 299 EUR for a Freerunner will pay this discount price and no more. The stock situation is getting much better now, we have a new delivery on 15.08. and everybody who ordered a Freerunner will get one. I ordered when delivery was said to be 25-7. Can I expect the FR to arrive 1 or days later? Or has my order been delayed to 15-8? Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
On 2008-07-16, Jay Vaughan [EMAIL PROTECTED] wrote: Its really pretty important that the communication on this issue *not* diverge into hate and vitriol towards customers, because to those who are observing the OpenMoko project - not participating - the SD+GPS testing issue is a *huge* screw up. No, the SD+GPS issue is a bug. Context:SD+Glamo == No go. SD+GPS == No go. How many GTA02's have been shipped before this problem was discovered? How much time wasted trying to get GPS functioning so that development can continue? Admittedly a somewhat nasty bug, but nothing extraordinary. If I can't use SD+GPS, its a no-brainer: Freerunner is no longer qualified for my project. Having spent a year on OpenMoko, thats nasty. I was willing to give the SD+Glamo issue a slide, but .. It is ok that you think this way, but please don't post messages like this on the list now. I do not care if you think it is a no go or not. Complaining does not help to solve any problems. Be positive:) Also, SD+GPS will be possible. They are almost finished with the kernel patch:) Openmoko is damn lucky this problem can (allegedly) be solved by SW, otherwise everyone would have a good right to complain, even return the HW. But a big thumbs up to the communitymember that found the cause, and also a big thumbs up to the engineers working out a solution so quickly! Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner @ pulster.eu Shop
Hmm, I ordered the 28th and have not heard from them since the confirmation e-mail. I ordered the 27th and only received confirmation mail so far. Guess I was just too late for the first batch.. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: HP calculator on neo1973 - was: More HW from Openmoko
On Saturday 05 July 2008 09:34:55 Ken Young wrote: I've got the x48 HP 48 series calculator emulator running on my neo1973. It was very easy to port - I just had to re-arange the screen layout a bit to have it fit on a VGA window, and cross compile for the ARM CPU. A screen shot can be seen here: http://wiki.openmoko.org/wiki/Image:HP48OnMoko.png If you want a copy of this program, email [EMAIL PROTECTED], and I'll mail it to you. Great work! Maybe you can mail the patch to the (devel) mailinglist, or even create a bitbake recipe. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: internet connection via USB
On Saturday 05 July 2008 20:13:08 simarillion wrote: Hi, I'm trying to connect to internet via USB. I followed this howto http://openmoko.togaware.com/survivor/Network_Setup.html but unfortunately without success. No error appeared but I have no ping to the internet. I'm running Kubuntu 8.04. The router my Notebook is connected to has the IP adress 192.168.2.1 and my Notebook has 192.168.2.102. I don't know which addresses in the howto I have to change. Only the nameserver IP (copy that from the /etc/resolv.conf file on your notebook) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How Slow Is Fast?
Anyone who has paid attention to this mailing list over the last few months has seen the It doesn't have 3G, it's worthless messages about the FreeRunner. For me (And many, many others) having a fast, power-hungry wireless pipe to the phone isn't as important as everything else the FreeRunner brings to the table. But I do have a question: What kind of thru-put can we expect to see from the GPRS radio in the FreeRunner? Is it 2k/sec dial-up speed? I'm interested in any information about this radio, theoretical as well as experiential (Now that people are getting FreeRunners). I've got some grand plans in the works, which may or may not ever come to fruition, but some of the design considerations hinge on what kind of bandwidth the GPRS radio provides. AFAIK it is multislot class 10 which means 4 slots of 21.4kbit/s downstream, but in practice it is max 48kbit/s Also, and I know this has been talked about before, but is the final word that the GPRS can or cannot be active at the same time as the GSM (Class B or whatever it's called)? An ongoing GPRS connection would be really nice but if it can suspend/resume decently (Something like v.92 on modems if anyone remembers those). Yes, Class B. It means that when you're calling GPRS is disabled. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QVGA V/s VGA for GTA03 (was something about yummy CPU-GPU combos!)
On Friday 13 June 2008 21:22:12 Ben Burdette wrote: What would be cool would be a QVGA-to-VGA transition effect where a 'blurry' QVGA app comes into focus as you transition to VGA mode. So suppose you are in an application selection screen, you select an application and it 'zooms' to the app window - in QVGA mode. But the app you selected is marked as a VGA app, so after the zooming happens, there is a fade from the QVGA appearance of the app (actually drawn in VGA now) to the VGA appearance. Interesting proposal.. Might not be possible due to artifacts or noise when switching between the two modes, but it would be a leet hack :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: resolution preferences??
Honestly, if the freerunner did not have VGA screen but QVGA, I would not buy it ! For me, VGA is a must have feature. As other said, there are plenty of QVGA devices. I don't want one of them because of the resolution. I have a Dell Axim X5 and I'm really sad about the QVGA resolution (in addition of the windows OS :( ) Please, please ... keep the VGA screen ! Yeah, same here. Besides, OM was really advertising the DPI for a long time back in 2006/2007 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2.5mm or 3.5mm
Both! External adapters are a bad idea since it could put extra force on the jack socket. They could be located very close together so you cannot connect both at the same time. grtz, Sander Hi community! A short poll: on a future GTA0x (2), would you prefer to have A) standard 2.5mm headset (mic+phones) connector, where you have to buy a cheap adapter if you want to use your old headphones, (the way like it's for GTA01/02) or B) classic 3.5mm headphones Walkman(R) connector, where you have to DIY an adapter for any standard cellphone headset? (or does anybody know of 3.5mm headSET standards or adapters?) please hurry to vote, we have to make a decision. Thanks cheers jOERG Openmoko-HW-development ___ 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: 2.5mm or 3.5mm
I still think that wired headsets are not used by anyone out there. Even if every vendor adds a cheap wired headset to it's device I barely see anyone using it. Today bluetooth headsets are cheap and they are way more practical (and even have the better microphone placing, compared to the wired clip-micros. So I think there should be an 3.5mm to listen to music and use bluetooth for headsets. I'd rather not be forced to use bluetooth with a headset. My experience is that bluetooth interferes with wifi (same freq. band) and you'll have another battery to worry about. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Switch from GTK to QT (was: ASU software - pre-pre-releaseimpressions)
It is an extra magnitude of difficulty to get anything more then a few developers to code in a consistent style when working with C++. Requires strict discipline and coding standards. Without such things, it all de-generates at a rate proportianal to the number of developers and amount of code being writen. Yeah.. just like when working with C, Java, Python etc etc etc ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 99
On Monday 21 April 2008 02:39:38 Marco Trevisan (Treviño) wrote: steve ha scritto: I'll gladly put the price back to $650 which was the first price we released. LOL... BTW for me you can also put the price at 398 for staying a little more far from 399... :P I vote for 398 too, but I'll send you a postcard in return :-P ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: which applications are usable
On Friday 18 April 2008, Tim Shannon wrote: I love that the terminal is one of the requisite applications. This is definitely a phone I'm looking forward to. Indeed, just imagine running vi on a phone!! The ultimate! Eildert no, emacs! *ducks* ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Speeding up browsing and lightening the traffic load
On Monday 07 April 2008 12:13:17 Mikko Rauhala wrote: ma, 2008-04-07 kello 11:24 +0200, Erland Lewin kirjoitti: IMHO, the Opera Mini design (compressing and optimizing web pages before sending them to the phone) is excellent, because it saves traffic (=money) and speeds up loading. I'm not aware of any open source alternative with the same design. Over the last weekend, I've been working a bit on a prototype proxy doing streaming html/xml diffs (dubbed mldiffs) based on a shared cache, largely as described here: http://wiki.openmoko.org/wiki/Server:WebProxy Hi I wanted to let you know I added the following to your wiki entry: improvement: it would be better NOT to modify the client, but instead have a 'reassembly proxy' on the client, so that all http clients/user agents benefit without hacks. The reassembly proxy could then inject a cookie to keep track of page versions. Also, with pictures the proxy pair could detect on the second load it has already sent the 'crappified' image and send a diff with the next 'progression' of the image. That way the user can get the full quality image with 2 or 3 page refresh actions. Sadly, going by track record, I probably will not have the energy to productize the thing, but maybe it'll provide inspiration and/or a basis for someone to do so. I do intend to get at least the mldiffs going (currently just need to debug the interproxy communication, other stuff is done) and hopefully add rdiff support for non-ml content (during testing I found the mldiffs to be notably better for markup content so I started with that). Then I'll put the (python/twisted) source out there (if someone's really interested for it now, feel free to ask). I think it's a great idea! Image crappification support would be good, but I don't know, it would really require inserting javascript or at least mucking with the (x)html to work nicely with a browser knowing nothing of this. (You know, something along the lines of click the image the first time, and you'll get a better version; second time does what it normally does.) I'm not sure if that's something I want to tackle with. OTOH, simple crappification controlled from a configuration key on the client might be doable with my concentration levels, we'll see. No need for hacks with the two-proxy scenario It might even be extended to a session manager that keeps your (XMPP, IRC, etc) sessions open even when switching from Wifi to GPRS or vice versa. This would make possible 'handovers' when losing Wifi coverage. The server and client proxies just reconnect over the other channel while the endpoints will not disconnect. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: TomTom on Openmoko?
Dnia Thursday 27 of March 2008, joerg napisa³: Am Do 27. März 2008 schrieb Sebastian Hammerl: Hi, as far as i know on the TomTom go devices is running Linux. So would it be possible to rip out the TomTom applikation and get it to work on Openmoko phone? It would be a great GPS application. Suggest this to TomTom, they probably can do it in a few days. Surely it's not feasible for anybody outside, you have to *compile* the app for NEO! Compilation is not required probably -- most of TomTom devices use ARM920T like Neo do... Nope, but we need a compat layer to provide ABI compatible symbols for the (older) libraries and kernel they use. Also, the tomtom license agreement states you may only use the software on 1 device, so you'll need to remove it from the original tomtom device.. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: TomTom on Openmoko?
On Thu, Mar 27, 2008 at 2:51 PM, Marcus Bauer [EMAIL PROTECTED] wrote: And working phone operating systems can be bought from Symbian, Apple and even Microsoft. And yet we develop a new one! The whole point of Open Source is the freedom (and fun) to participate. That's why I am opposed to running TomTom software on the Freerunner. I know their software, and I know their maps, but closed source and closed data will not help us forward... I disagree. There's a difference between free speech and free beer, and you want the latter. I am willing to pay for high quality maps, because it takes considerable amount of work to create them and keep them up-to-date, AND it doesn't impair my 'free speech' freedoms. I'd rather use an open source navigation software together with commercial maps than use the tomtom navigation software, because that WOULD impair my 'free speech' freedom. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Freerunner available soon!
..enough with that 'delayed by 6 months' thread already, it's making me nervous! ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Price of the Freerunner published?
On Wed, Mar 19, 2008 at 12:10 PM, Steven ** [EMAIL PROTECTED] wrote: Was reading Planet OpenMoko and found the following at http://www.vanille-media.de/site/index.php/2008/03/18/from-switzerland-to-brazil/ : The price range for the Neo FreeRunner has been published, it's going to be less than 400 USD which is quite a substantial improvement over the estimated 650 that was published last year. Was the price range really published? Where is it? Equally important -- is that the stock unit price or the dev kit? The latter would be fantastic, but I fear it's just the former. If I recall correctly, the initial Freerunner pricing was $450 for the device and $600 for the devkit. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About ipkg on Openmoko
On Sunday 02 March 2008 08:32:42 ian chu wrote: After I did these steps , I can ping outside IP successfully! But when $ ipkg update , it still failed like previous what should I do to make my Openmoko download ipkg update ? or I can only copy the file and update locally copy your PC's /etc/resolv.conf to your phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: openmoko banner
We don't yet but we'll look into it. Sounds like a good idea. Maybe it's also a good idea to update the neo1973 images on the various openmoko pages (especially the Products page) with the new (2007.2) user interface. IMHO that looks much better. Michael Javi Roman wrote: Hi all, I wonder if OpenMoko has a banner advertisement (web banner, animated gif, ...) to promote in personal web sites. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
I think that we all agree here that the patent system is completely broken. By filling patent, even for defense only, you are playing the rule. What I've seen so far is that small companies that cannot afford a lawyer department simply choose to ignore the rules and just ignore completely the patent system. In the essence of the law, as long as you don't obviously *stole* an idea, you 've nothing to fear. But the system has becomed crazy when you can infringe a patent without even knowing it. That's completly wrong with the moral behing patent itself ! Have you already tried to fill a patent ? Have you tried to make a study on prior art ? I did for a few weeks and I didn't succeed. All is patented ! All, completely ! Patents are as general as possible and cover everything you could believe. It's nearly patents for things that do stuffs. So whatever you do, you could be sued. I don't know the ressources of OpenMoko but patenting, writing and submitting is a full-time job ! It would be shame (IMHO) to waste ressources in this way. More : you have to fill the patents in different countries !!! As OpenMoko does Free software, doing this, even for defensive purpose, will have a terrible PR impact in the Free Softwware community. You have the opportunity to just move, to ignore those silly things and to build something new. On the other hand, if you are under a patent attack without any patents, I think that the Free Software Fundation gives legal help in that kind of case. I really hope that OpenMoko will not be covered by any patents. (but I'm sure that there's a patent for a device allowing wireless communication somewhere) I totally agree with Lionel here. It will be bad PR wise and it's very difficult to enforce. Openmoko hardware and software are already covered by copyright, and I think a patent doesn't add any protection. Even if parts will be covered by a patent, chances are that some smart company can circumvent it by making small changes/improvements. Besides, what's there to patent? If I understand correctly, anything that's published (or available publicly) before the patent cannot be patented anymore, so that would include all openmoko software up to today, the CAD design for the casing, ideas on the wiki etc. grtz, Sander ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debugboard option?
Does anybody know if there will be an option to buy the Debugboard only once the Freerunner is released? If I recall correctly there will be a new improved version of the debugboard when Freerunner is released. I´m really looking forward to the release of the Freerunner to get one. I think I´ll go for the Base Kit as I presume I won´t need a Debugboard at first, but it is possible that after a time I want to do something with my Neo that needs the use of a Debugboard. I would like to know if there will be the possibility to buy a Debugboard in the case I need it and not have to buy the whole Advanced Kit to get one. Judging from the current GTA01 offerings there wont be separate debugboards. And if it will be possible, you'll probably miss out on the cool suitcase that comes with the advanced package :) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ATT is cruising for a bruising
On Monday 10 September 2007 12:47:26 Giles Jones wrote: Alexey Feldgendler [EMAIL PROTECTED] wrote : This not because Apple or ATT are evil. It's actually a bug (or call it a design shortcoming) and could happen to anyone. I'd actually call it ignorance or lack of information from Apple. Apple like to make things simple even though the underlying technology is complex, this minimalistic approach often results in lack of feedback to the user. OpenMoko should probably include some system-wide network access management that avoids huge roaming bills. Yes, actually the network access management is one of the most complex things to do right on a mobile device. Quite simply, build in a data counter that you can enter the cost of a data unit and have the phone show you your costs incurred. But also be able to deny access to all or specific applications. Nah it should be more advanced than that. GPRS+roaming - only check mail once a day, only download headers. no images download when browsing GPRS+no roaming - check mail 4 times a day, download full mail but skip attachments 2MB Wifi+at home - no limits public wifi - use VPN/SSH tunneling wifi+in china - use Tor etc --- G O Jones ___ 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: Login Manager
On 5 Aug 2007, at 16:11, Nkoli wrote: I think your implementation is great; it's logical and clean. The only thing I would change is the first boot part. Most phones, if not all, allow security conscious users to set some kind of password/pin to lock their phones. It should also be an option on the Neo, not a requirement. Example, at first boot, user is asked whether they wish to set a password, Yes or No. If yes, password is set per your implementation and becomes a requirement each boot. If no, remind the user they can still set a password from fill in the blank and leave it at that. Passwords and pins are pretty fiddly, even tedious to enter. There was some research into using pictures of faces which you click a few of to log in. Now it would be hard to get such images of faces for our use, but I'm sure symbols or colours would do? This would be pretty cool! A hash of the symbol sequence could also be used as an encryption key, to store personal information but also the SIM's PIN, so authentication using pictures/symbols will transparently authenticate to the SIM. See also : http://csrc.nist.gov/publications/nistir/nistir-7030.pdf ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
iPhone has built in spyware module?
Worrying news, if this rumour is confirmed, although it might be positive PR for open phones.. http://vsiphone.blogspot.com/2007/07/iphone-has-built-in-spyware-module.html ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: X Server MultiTouch Support
On Saturday 14 July 2007 21:47:28 Brandon Kruse wrote: I agree Joshua. Have seen this vid awhile back, it would be great. We all the onscreen keyboard wont be so great with single touch, its just a fact. Something like this would change everything, and, as mentioned in the article, would make it so that you could use compiz also? A cube on your phone? It would be just plain insane. I would rather see a more integrated approach, like clutter based widgets. (see also the flickr example app those guys made). Applications are usually fullscreen on a PDA/phone, which makes a window manager (and effects on that level) much less prominent. However, it would be useful for alpha blended menus and dialog screens, and an Expose-like taskswitcher would be great of course! ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: rough seas
2007/6/20, Sean Moss-Pultz [EMAIL PROTECTED]: In less than a week, we will update you about what's going on at FIC/ OpenMoko, the status of GTA01/02, and our plans for selling these neos. One week has passed silently... Well, technically you posted your message 9 hours too early ;) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
I think (hope?) it is the new appearance of Savaje platform (+ JavaFX scripting). That's correct. This is going to be very cool stuff. And the Neo is definitely very high on the list of devices I want to see this running on. If I understand correctly, JavaFX Script is going to be open source, but JavaFX Script is not the whole of the 'JavaFX family'. Does this mean there will be non-open sourced parts in the stack necessary to use JavaFX Script? ./Sander ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Sander van Grieken wrote: I think (hope?) it is the new appearance of Savaje platform (+ JavaFX scripting). That's correct. This is going to be very cool stuff. And the Neo is definitely very high on the list of devices I want to see this running on. If I understand correctly, JavaFX Script is going to be open source, but JavaFX Script is not the whole of the 'JavaFX family'. Does this mean there will be non-open sourced parts in the stack necessary to use JavaFX Script? Sun has already said that JavaFX Mobile (the stuff you need for the phone) will be GPLed. So.. no. Well, this is not exactly true. Sun indeed said explicitly that JavaFX-Script will be GPLd, but regarding JavaFX-Mobile, I read the following : JavaFX Mobile, Sun's software system for mobile devices, is available via OEM license to carriers, handset manufacturers and others seeking a branded relationship with consumers source : http://www.sun.com/software/javafx/index.jsp ./Sander ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Sander van Grieken wrote: I think (hope?) it is the new appearance of Savaje platform (+ JavaFX scripting). That's correct. This is going to be very cool stuff. And the Neo is definitely very high on the list of devices I want to see this running on. If I understand correctly, JavaFX Script is going to be open source, but JavaFX Script is not the whole of the 'JavaFX family'. Does this mean there will be non-open sourced parts in the stack necessary to use JavaFX Script? Sun has already said that JavaFX Mobile (the stuff you need for the phone) will be GPLed. So.. no. Well, this is not exactly true. Sun indeed said explicitly that JavaFX-Script will be GPLd, but regarding JavaFX-Mobile, I read the following : JavaFX Mobile, Sun's software system for mobile devices, is available via OEM license to carriers, handset manufacturers and others seeking a branded relationship with consumers source : http://www.sun.com/software/javafx/index.jsp ./Sander ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
Does this mean there will be non-open sourced parts in the stack necessary to use JavaFX Script? Sun has already said that JavaFX Mobile (the stuff you need for the phone) will be GPLed. So.. no. Well, this is not exactly true. Sun indeed said explicitly that JavaFX-Script will be GPLd, but regarding JavaFX-Mobile, I read the following : JavaFX Mobile, Sun's software system for mobile devices, is available via OEM license to carriers, handset manufacturers and others seeking a branded relationship with consumers source : http://www.sun.com/software/javafx/index.jsp Of course it is, since Sun owns the Copyright, they can distribute non-GPL versions of the code to those who want them (and are willing to pay.) MySQL does this too. OTOH: Sun will ship a pre-integrated, GPL-licensable, Linux- and Java-based operating system software reference design for mobile phones, it announced at its JavaOne conference today in San Francisco. All JavaFX products will be available under the GNU GPL, Sun said. http://www.linuxdevices.com/news/NS7539760574.html Excellent, this is very reassuring. I did some searching, but didn't find any explicit statements regarding the whole FX stack, but this definately answers my question. And you could have *AT LEAST* quoted the entire paragraph of the press release: http://www.sun.com/aboutsun/pr/2007-05/sunflash.20070508.1.xml I didn't quote the press release but the JavaFX product page. Since GPLing the stack is a selling point (at least, from my perspective), Sun should mention that right there. However, thanks for pointing me to the press release. It makes the issue very clear. Me, I think Java is a four-letter word yeah, it means Just Another Vague Acronym, right? :) Or, you could listen to/watch the webcast where Rich Green is talking all about how they prefer the GPL and then segues into announcing that Java has been open sourced (under the GPL), being a developer, I kinda hate ambiguity. I interpreted this as 'the VM/JDK has been open sourced'. That doesn't necessarily mean technologies on top of that are open sourced. Or you could continue to FUD. With the 20/20 hindsight of history, it turns out that ESR was wrong about many things, including being dead wrong about Sun. well it was not my intention to spread FUD, but since this is the Openmoko mailing list, it should be very clear what the degree of openness is. ./Sander ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Size and weight considerations for future Openmoko devices
Dr. H. Nikolaus Schaller wrote: That's not solely robustness though, air resistance helps lots too. Hmm do you propose a furry casing? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Audio Jack 2.5 mm
There are adapters for 2.5mm - 3.5mm. Which are either one long bit of plastic that lever the jack off the PCB, or a cable to tangle. However, availability of 3.5mm headsets may be an issue. I think an adapter is somewhat impractical (and will probably break the solder at some point), but I'm planning on A2DP (eventually) anyway. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: built-in scripting languages.
I would like to propose a number of bindings a preferred scripting language should have - Bluetooth bindings - Webservice bindings, 'lightweight' request/response access to networked services - Persistence bindings, optimized access to large datasets (sqlite?) On Tuesday 03 April 2007 21:54:26 Bryan Larsen wrote: A scripting language should be chosen as the default. Yes, it'll be a hard choice, but there's also no 'wrong choice' (except for none). I've put a lot of work into http://wiki.openmoko.org/wiki/Wishlist:BuiltInScriptingLanguage. Please comment here or on the discussion page. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: openmoko articles
On Friday 16 February 2007 15:03:16 denis wrote: Are there some high definition photos of the Neo available ? It would be nice to have some high def. pictures in the wiki and in the articles. (in the especially for the basic users section, these need some eye candy ;) ) Regards, Denis Harald has some very cool ones here: http://people.openmoko.org/laforge/photos/ The dialer. I like. http://people.openmoko.org/laforge/photos/gta01bv2_omoko/img_5400.jpg ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: R: Camera and MMS
On Tuesday 13 February 2007 10:26:32 Michele Manzato wrote: [...snip...] MMS seems to be a problem. Apparently there is no MMS standard, or the standard itself is said to be horribly broken (see http://lists.openmoko.org/pipermail/community/2007-February/002787.html) or it is tweaked to peculiarities of the Mobile Network Operator in order to discourage migration between providers (MNOs fear open standards!). Someone is already talking about an OpenMoko integrated messaging application that abstracts on the specific media (e-mail, SMS, MMS) so, perhaps, sending/receiving MMS can just become a matter of implementing proper abstraction layers. It's not so much the standard that is broken, but more so the terminals (phones) that are non- or semi-compliant. My experience with low-level MMS dates back to 2004, so it might be that modern phones are much better at presenting and supporting the full range of content types and SMIL elements, but back then you could only assume plain text + jpeg/gif image on the first 'slide' would be properly supported (that's what 99% of all MMS messages consist of anyway). Anyway, I can see some benefit in supporting basic MMS, since ppl like to send each other camshots through MMS. Supporting anything beyond this simple scenario would be overkill IMHO. grtz, Sander ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
