Re: [Shr-User] Quick e-mail poll: Still using your Freerunner?
Risto H. Kurppa wrote: > Do you use FR as your daily/primary phone? > YES. It's my only phone for over a year. I did the buzzfix and gps cap myself and got no complaints there. Adjusting the call volume is a sorely missed feature, though. But the slowness of the software does tend to screw up things when more than one thing happens at the same time (simultaneous incoming calls, etc.) > Do you use FR as your primary PDA? > YES. GPS, password vault, the occasional Mokomaze. GPRS and WIFI are too unstable for any real connection, so no web or email. And bluetooth is just not there (no GUI == not there for the user). Does anyone else have trouble doing opkg ugrade over gprs? mine hangs after a bit. > What distribution you run most of the time? > SHR-U (currently the old one from September, which works stable enough as a phone.) The new Testing is quite broken, and I couldn't understand why the new Unstables where older than the Testing ones. Now that I see a lot of people is using the Unstable, it's probably meant to be like that -- and just opkg upgrade all the time. Will try it today... > If you don't use FR as your daily phone/PDA, what phone did you change > over to, and why? > I haven't switched out because it is good enough as a simple working phone and a very basic GPS. Other than that, it is crap. I don't blame the community for the state of things; I think that Openmoko.com started by biting off much more than it could chew, failed to build a solid community, then realized the dead end which they put themselves into, and backed out on all of us into "plan B". I understand the economics that forced OM to reboot and start over with the Wikireader, but I will always resent the fact that I spent 300 EUR on a badly designed and even worse tested hardware. I cannot forgive them for releasing this HW into the public without a fully patched kernel and drivers and a full list of known caveats after an honest effort to completely test the device. They somehow thought that time-to-market was more important than quality and reliability. Personally, I think there is no forgiveness for them because of this. Having said that, I am admired at this community that still keeps kicking the dead horse with a passion, and there is a small thread of hope inside my heart that this brick will someday fulfill at least half of its promises. And if it does, it will all be due to the work of these last few heroes - and I thank you so much. The Openmoko project is to me a disappointment as big as the cancellation of SG-1 and Firefly: there was still so much to do and say, but economics had the last word. Well, at least there are positive things left behind like the FSO and the colorful ecosystem of other distros and apps. Have a nice 2010 everyone!! :D May the source always be with you. > > Thank you :) > > > r > > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: future phones that you can hack. news.
I do understand the skepticism, but thinking about the apparent success a pseudo-open platform like Android is having near the manufacturers and users, I'd say there is a very good chance something groundbreaking (in terms of market attitude) may actually happen. Android is fierce competition, and others may take the plunge into "openness" just to fight it. It's a "lesser evil" choice for the manufacturers (or in this case, a "lesser potential for losses in the near future"). Carry on, people!! :) Just don't let them twist your values. ;) Fabian Schölzel wrote: 2009/11/18 Carsten Haitzler : Who it is - will wait for future announcements. What, when and where will also need to wait. How open it is, will also need to wait. But you can guess that if we are fiddling with it - it's already partly open. Sounds interesting! Please keep us informed! Cheers, Fabian ___ 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: Centralization of graphical awesomeness
Downgrading to QVGA is something that should have been done a long time ago. There's no point in trying to force a badly designed system. How do we do it? Which files must be changed? Citando Carsten Haitzler : > On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin > > said: > >> 2009/10/26 Carsten Haitzler : >> > you want speed? you will need to give up something. if you still >> want it to >> > look nice, then drop pixels. its the simplest and easiest >> solution. its the >> > right resolution for that cpu anyway. the glamo will still hurt you, but >> > not as much. >> >>I'm sure everybody who has any professional connections with >> Freerunner+Glamo development already took all possible measures to >> solve this problem. But what concrete steps were taken to ease Glamo >> bottleneck? If its throughput is so narrow, can we lower amount of > > none. it's a hardware issue. you simply cant read or write to video > ram faster > than that. andy tried timing stuff all that happened was instability from > memory. glamo is most likely also the cause for the cpu runnig at 400 not > 500mhz. the extra load on the memory bus (because glamo is hooked there > externally providing another addressable chip) probably caused the > instability. > remove it and there is a big change the cpu could run at 500mhz > instead of 400. > it's rated to do 500. (yes power consumption would go up - but it'd > only be up > while its on. when suspended it wont matter). > >> data flowing through it? There's one neighbor unanswered thread with a > > render on the device - and this will then limit what you can render. > evas can't > be fully accelerated by the glamo. it has too many opretations. a bit like > asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx > chip ever was designed to do and you will hit software fallbacks. evas has > multiple engnines. software (which is what is used - the 16bit renderer as > opposed to the full 32bit one). it has xrender - if xrender were fully > accelerated this should be better, but glamo cannot fully accelerate all the > ops evas uses, so... it will rely on software fallbacks. thus slow > down. my bet > is you'll end up same speed as the pure software engine, or worse. aftera > bunch of hard work you'll have gone nowhere. evas also has a gl and gles2 > engine - but thats no use on glamo. it's gles1.1 and very limited > (from memory > texture size is 256x256 which is pretty useless for 2d as most data you deal > with breaks these bounds). > >> question on how to start the kernel with qvga resolution. Aside of > > no need to do that - just configure x for qgva. :) > >> this, what can be reduced, for example amount of available colours >> (256 or even 16)? And if this [too] low throughput only of video >> memory channel? > > 256 won't help. it increases complexity and really reduces display quality > through the floor. the best best is qvga 16bpp. its simple. it > doesn't require > any hard work. it is actually the most common resolution for most phones and > devices out there so the software is more portable if you work on that (and > then higher). but... in the past everyone has moaned and complained > and refused > to use it, and insisted on their vga resolution... and then complained about > speed. > > if people don't believe me that the gta02 is just plain a "bad bit of > hardware and you have few choices" here's some examples. here'es an ooold efl > demo app i did: > > http://www.rasterman.com/files/eem.avi > and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash, > qvga(240x320). > it's from like 2001/2002 (from memory). its ancient. and watch it run evas: > http://www.rasterman.com/files/eem-live.avi > > here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m > ram, and 800x480 (higher res than gta02): > > http://www.rasterman.com/files/ello-elementary-smartq5.mp4 > > everywhere i look... theres much better hardware. if you look at > performance vs > age of hardware (when it was released) gta02 is almost at the bottom of the > pile. :( you simply have a bad piece of hardware if you want graphics > performance. as soon as you acknowledge that and either downgrade the device > resolution for example to bring it in line with its performance, or just use > different hardware, the better life will be :) > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.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: Qi doesn't read my /boot/append-GTA02
Then I'd say this is a very desirable feature (kernel parameters when booting from flash), if and when anyone tinkers with Qi again. Citando Paul Fertser : > Vasco Névoa writes: >> I'm booting from Flash, not SDcard. >> Shouldn't the /boot/append file work the same? If it doesn't, where >> are the kernel parameters defined? > > Qi can't read jffs2, in this case kernel parameters are hardcoded. > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR clock reset
I've started experiencing the same in the last few days. The Neo's clock had always been impeccably correct, until now. Now it was half an hour late and I set it by hand. It appears the clock is drifting, and otimed isn't keeping it in sync with the GSM. The only hints in frameworkd.log are: 2009.10.01 18:05:25.88 otimed INFO loaded timesources [, ] 2009.10.01 18:05:25.124 otimed INFO loaded zonesources [] 2009.10.01 18:05:25.138 frameworkd.subsystem INFO subsystem otimed took 1.53 seconds to startup 2009.10.01 18:06:27.163 otimed INFO GSM: multiple zones found 2009.10.01 18:06:27.357 otimed INFO GSM: multiple zones found 2009.10.01 18:16:39.457 otimed INFO GSM: multiple zones found 2009.10.01 18:16:49.835 otimed INFO GSM: multiple zones found 2009.10.01 19:18:44.462 otimed INFO GSM: multiple zones found 2009.10.01 19:19:20.392 otimed INFO GSM: multiple zones found 2009.10.01 19:19:48.627 otimed INFO GSM: multiple zones found 2009.10.01 19:20:40.194 otimed INFO GSM: multiple zones found 2009.10.01 19:20:58.312 otimed INFO GSM: multiple zones found 2009.10.01 20:49:58.117 otimed INFO GSM: multiple zones found 2009.10.01 20:53:14.628 otimed INFO GSM: multiple zones found 2009.10.01 22:18:28.542 otimed INFO GSM: multiple zones found 2009.10.01 22:48:41.491 otimed INFO GSM: multiple zones found Does this "GSM: multiple zones found" situation create a problem? I looked at the hwclock, but it seems it's not even in use / not related to the time shown to user: r...@om-gta02 ~ $ hwclock -l Thu Oct 1 21:52:35 2009 0.00 seconds r...@om-gta02 ~ $ date Thu Oct 1 23:15:20 WEST 2009 Any hints on what the problem is? Vikas Saurabh escreveu: Timezone from GSM is already implemented for ages ;) I have often got wrong timezones reported by cell (thereby resetting my phone's clock and making me reach late somewhere :(...but thats a different story) I was wondering if shr-settings can get something like: Use cell timezone: * yes * no * ask --Vikas ___ 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: Qi doesn't read my /boot/append-GTA02
I'm booting from Flash, not SDcard. Shouldn't the /boot/append file work the same? If it doesn't, where are the kernel parameters defined? Paul Fertser escreveu: Vasco Névoa writes: I'd like some help here, please. dmesg doesn't give me any clues. I removed the "quiet splash" from /boot/append-GTA02 and added "glamo_mci.sd_drive=5", but none of it is sticking. It's ignoring the file altogether, AFAICT. Are you sure you're booting from SD? And that all you parameters are on the first line in that file? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Qi doesn't read my /boot/append-GTA02
I'd like some help here, please. dmesg doesn't give me any clues. I removed the "quiet splash" from /boot/append-GTA02 and added "glamo_mci.sd_drive=5", but none of it is sticking. It's ignoring the file altogether, AFAICT. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How does well does this community work?
That's a though question, especially due to the differences between a car and a phone. :) When it comes to pure Community building, IMHO the leaders seem to be Ubuntu; so you should probably talk to Jono Bacon or read his book. ;) Regarding the Openmoko community, I think it works better now that we don't expect anything from Openmoko the company -- this has freed everybody to assert their own targets and roads, and get down and dirty instead of waiting for the next disclosure. So, not having a "benevolent dictator" over the community makes it proliferate and flourish. On the other hand, we now have almost as many distributions as we have phones out there. ;) And many of the applications are being redundantly developed in parallel, instead of collaboration. So, my humble advice to you: if 40fires wants a coherent community, focused on a small set of defined goals, you must be the benevolent dictator and you must have a single communication channel that is extremely clear (see linux or perl); if on the contrary, you seek variety, chaotic innovation, and surprise, then just throw it up on as many channels as you like and watch the feeding frenzy. :) BTW, congratulations on the project. The world needs it. Roland Whitehead escreveu: > I am working with the 40 Fires Foundation [http://www.40fires.org] to > try to build a framework for the development of open source hardware. > You might have heard that the first project is the "hyrban" car - a > car powered by a hydrogen fuel cell - the prototype of which was > revealed by Riversimple [http://www.riversimple.com] earlier in the > summer and whose designs have been licensed to 40 Fires. We have had > input from Mozilla and other software foundations but of course the > design of something like a car is a little harder to manage as an open > source project. Openmoko.org is frequently raised in discussions and > has lead me to push forward a wiki, mailing list and nabble based > forums. Before we commit to this, how well do you think that this > technology serves the Openmoko community? If you had the chance to > build a community for the development of the Openmoko (hardware as > well as software) what would you do and why? > > TIA > > Roland > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR - Latest unstable] opkg not found!
Ok, then, I apologize. Citando Sebastian Krzyszkowiak : > On 8/11/09, Vasco Névoa wrote: >> Some genius in a high ground took upon himself to rename it "opkg-cl", >> therefore breaking our beloved scripts. >> Seek and ye shall find. > > That's not renaming by some genius. That's just bug about missing opkg > symlink to opkg-cl. opkg binary was in fact always named "opkg-cli", > with "opkg" symlink pointing to it. > > It will be fixed soon. > > -- > Sebastian Krzyszkowiak > dos > > ___ > 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 - Latest unstable] opkg not found!
Some genius in a high ground took upon himself to rename it "opkg-cl", therefore breaking our beloved scripts. Seek and ye shall find. Citando Tony Berth : > Hallo, > > I got the latest SHR unstable and when trying to run 'opkg' I get: > > > r...@om-gta02 ~ $ opkg > -sh: opkg: not found > --- > > How come? > > Thanks > > Tony ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Jokes updated
I couldn't resist the current talk about #1024 and capacitors... I made an update on the "Jokes"page of the wiki: Q. It looks like every HW problem in the Freerunner is solved with a larger capacitor. What do you think went wrong in the design process? A. I think it was a lack of capacity. :P ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fixing bug #1024 successful reports?
I've been following this discussion from a distance, not paying much attention, but I'd like to warn that this fix is better done by replacing the original capacitor. One should avoid putting wires inside an RF can, especially if they run towards the outside of the can. It ruins the can shielding purpose... you're probably setting yourself up for some other different problem derived from RF interference after you do that... Citando Thomas HOCEDEZ : > Nice a picture is universally understandable ! > > Just a doubt I still have: why did you draw the c1009 outside the GSM > antenna. regarding to this picture : > http://n2.nabble.com/attachment/2971067/0/GSM_Modem_rework_try.JPG It is > inside ... > I'm a bit upset ... > > Bernd Prünster a écrit : >> >>> Hi, >>> >>> We (french FR comunity) are trying to solve the #1024 bug. I put a >>> 10uF SMD cap inside my GSM can, and I saw an increased battery life. >>> your way to solve it is not as clear as I understand it. >>> Correct me if i'm wrong : you only soldered the (+) of the c1009 cap >>> to the GND ? or other way my english tell me you did : on wire on >>> the (+) of the cap, on on the (-), and the two wires on the GND of >>> the phone ? >>> >>> By advance thanks a lot. >>> >>> Thomas >>> openmoko-fr.org >>> freerunner.daily.free.fr >> maybe i screwd the description up >> >> i attatched a pic describing how i did it. >> basically solder a lacquer wire to c1009's (+) wich you will fit >> through the shielding can so you can add another c in parallel which >> can be any kind of tht electrolyte capacitor small enought to fit in >> the gsm antenna. ofcourse this c also needs to be connected to gnd, so >> take another peice of lacquer wire to connect the other capacitors (-) >> to gnd. >> >> hope it helps (pics will be postet within the next days) >> >> br >> >> >> >> > > > ___ > 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: Freerunner audio channels
I think you're all missing the point. David's initial post is a breath of fresh air into a long debated but (AFAIK) non-resolved issue. I deeply welcome his investigation into this subject, and support his questions (which I also would like to see answered). Although the issue of low playback volume is rather well controlled in our FRs, the issue of low recording volume for GSM transmission remains - with callers still complaining and going "what? I didn't hear you..." now and then, especially in (even slightly) noisy environments. The whole "audio settings for GSM" issue is _not_ cut and dried, in my view. I still have to go into frameworkd.conf every time I flash the phone and set the DSP to "long-aec" to avoid echo and sporadic audio clipping, as well as raising the volume in playback and mic in gsmhandset.state... and I'm still not satisfied with audio quality. So, can someone please humor David and me and explain this sidetone channel business? Thanks. Vasco. Citando Sebastian Krzyszkowiak : > On 8/7/09, Marcel wrote: >> Am Freitag, 7. August 2009 16:29:24 schrieb Sebastian Krzyszkowiak: >>> On 8/7/09, David Fokkema wrote: >>> > - Why exactly are FR's different while I've never heard of Nokia >>> > users needing to tweak mixer settings. >>> >>> WTF? Every phone user tweaks mixer settings by using volume up and >>> volume down buttons during call... In Freerunner we only miss good UI >>> (from user point of view) and infrastrucuture behind it (from >>> programmer point of view). >> >> Afaik, my Nokia 3510i doesn't even have such buttons and I never missed >> them... > > I'm pretty sure in Nokia 3510i up and down buttons control volume > during call, as in Nokia 3310 and Nokia 3410. And most of users just > set volume once, when they can't hear something or they think volume > is too loud, and then they forgot about it - but it's still volume > tweaking, and exactly the same is possible in Freerunner, just > software is missing! > > > -- > Sebastian Krzyszkowiak > dos > > ___ > 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: Visit at Openmoko
Hey, take it easy, stop going berserk, and wait for the announcement. They will talk to us when they're good and ready, so save your energy for then, and stop raising confusion. Be civilised. Be smart. Be silent (until necessary). Citando Moko Mania : > "we are very much alive and well -- That's official. Thanks for caring" is > this MokoSarcasm? According to Whoiswho on the wiki almost everybody got laid > off. Is the design team behind the layoffs? Are you part of the design team > that took our raster already? If it's true then there is no more kernel > support, no more software releases. How about customer support? Who is > alive and well? The design team that cannot even design a simple functioning > phone UI? Is your statement the only official statement we will hear for how > long? Please don't tell me that everybody who ever did anything good for the > community was fired. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Citando Ed Kapitein : > > Does anyone know a program/script that converts the dbus messages to gpx > format? > Now i us gpspipe to get nmea and gpsbabel to create gpx files. > Ideally, _someone_ should join the effort in FSO and expand "fso-gpsd" to produce GPX output... ;) (I'm presuming gpspipe is just a dumb socket listener). V. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Citando KaZeR : > > Indeed, stopping fso-gps made it work, thanks for the hint. The drawback is > that you loose all the benefits of fso's gps handling : on demand statup, > shared access, etc. > That's more or less true. You see, when you stop the fso-gpsd, you only stop the "gpsd compatibility layer" daemon. The framework is still working. This means that if you connect to DBUS Gypsy service the framework will open the device again. "fso-gpsd" is just another client for the Gypsy service. However, if you are in fact reading directly from /dev/ttySAC1 and simultaneously try to read from Gypsy DBUS, the info probably will get mangled for both clients. Besides, I forgot to mention this: the framework talks binary UBX with the chip, so reading from /dev/ttySAC1 at the same time gives you UBX binary garbage, not NMEA ASCII text. So the current workaround that allows us to fully control the chip and have NMEA output is to stop fso-gpsd _and_ any other DBUS listener so that the framework releases the device; then we can power it off and on via /sys to reset the default config (NMEA mode) just in case; and then we can safely play around with "cat" and "tail" and "/dev/ttySAC1". But as soon as any other app requests the Gypsy DBUS service, hell brakes loose. V. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Citando Helge Hafting : > Ouch. > Having the framework _managing_ the gps (turn on/off, configure,...) is > fine. But why regenerate the data, what is wrong with pass-through? The > more cpu work, the more delays. And the gps may very well be used for > real-time purposes. And of course, 100% of the cpu is not available, so > it is hard to know how much extra work is "too much". > >> You could try uninstalling fso-gpsd, installing "normal" gpsd and >> somehow persuading frameworkd to not touch the gps (don't konw if >> setting the GPS to off is enough...) > > And the ideal fix would be framework support, so you just tell it you > want 4HZ updates and from then on you get that. > Helge, you're quite right, but gpspipe is a legacy application, and the preferred way is to sit on the DBUS interface for signals. I'm just using gpspipe because I already had a nice script to import data in NMEA format. ;) I suppose the FSO people will "strongly suggest" that users stick to the DBUS instead of consuming NMEA text, and that's what makes sense (even according to your own optimization rationale). So, asap, I'm going to code my app in python to use DBUS and avoid all this NMEA nonsense from the start. But the problem remains: ogpsd does not accept more than one position change per second and so I opened the ticket. http://trac.freesmartphone.org/ticket/431 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
I don't have much of a problem there... see this: http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS#Configuration_for_a_higher_sampling_rate However, you must remember that frameworkd sends a lot of configurations into the chip, and it keeps talking to it, so it might be a bit of a hassle to get the chip to listen to you without shutting down the framework. Usually, I just do "/etc/init.d/fso-gpsd stop" and avoid launching any GPS application. This makes sure the frameworkd shuts down the GPS chip and lays off it. Then I can send in UBX packets into /dev/ttySAC1 and "tail -f /dev/ttySAC1" without problems. Citando KaZeR : > > > Hello list, > > I also noticed last time i tried that i wasn't able to filter GPLL, GPGSA > and friends using the ubxgen script from the wiki. > Is it related? > > -- > View this message in context: > http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2888680.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: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Thanks for the hints, GUYS.
Yes, I usually do disable all the message types I don't need, leaving
only GPRMC and GPGGA. :)
I think I've found the bottleneck on this issue, and filed bug #431 on FSO.
http://trac.freesmartphone.org/ticket/431
Citando mqy :
>
> read this: http://www.nabble.com/GPS-at-4-Hz-td17096809.html
>
> NOTE about "baud rate". If you can't change it, you can disable some NMEA
> messages to make sure
> the default baud rate (9600) is ok for 4hz rate.
>
> On page 106, u-blox5_Protocol_Specifications(GPS.G5-X-07036).pdf says:
>
> "... The calculation of the navigation solution will always be aligned to
> the top of a second."
>
>
> Vasco Névoa wrote:
>>
>>
>> I've tried configuring (via frameworkd's om.py) the chip with a 3000ms
>> period between samples, and sure enough gpspipe is outputting only one
>> set of messages per every 3 seconds - so this proves my CFG-RATE
>> message is correctly delivered.
>>
>> However, I also see that the gpspipe output is... chaotic. Although
>> the NMEA timestamps are always correct (they skip 3 seconds),
>> sometimes the messages are delayed and then delivered in batches. For
>> example, there is nothing for 6 seconds, and both messages are
>> delivered together.
>>
>> If I set the period to 5.25 seconds, I can see that all the timestamps
>> coming out of gpspipe end with ".00", which is obviously wrong.
>> Many of the sentences are repeated, like the SW couldn't wait for the
>> next UBX data block and just repeated the last data block.
>>
>> Who is doing this sample mangling?
>>
>>
>>
>> Citando Vasco Névoa :
>>
>>>
>>> Hi all.
>>>
>>> I'm used to putting the GTA02's ublox chip into 4Hz sample mode for my
>>> research projects, but ever since I started using FSO and derivatives
>>> I can't get it to spit out anything other than 1Hz samples - so I just
>>> stop "fso-gpsd", configure the chip at my own will, and read directly
>>> from /dev/ttySAC1.
>>> However, this is the unfriendly way to do it, and I'd like to
>>> integrate this option with FSO.
>>>
>>> So I found the initialization sequence inside
>>> "/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/om.py"
>>> and added this to the end of "def initializeDevice", just before the
>>> "self.huiTimeout = gobject.timeout_add_seconds( 300,
>>> self.requestHuiTimer )":
>>> # increase sample data rate to 4Hz:
>>> self.send("CFG-RATE", 6, {"Meas" : 0x00fa, "Nav" : 0x0001,
>>> "Time" : 0x})
>>> Unfortunately, it doesn't change anything. "gpspipe -r" will still put
>>> out a single set of messages per second, even though the GPS chip is
>>> (hopefuly) configured for 4 sets per second. When used with the
>>> original gpsd in other older distros, this didn't happen; gpspipe -r
>>> outputs whatever the the gpsd delivers. So the problem is most likely
>>> in FSO's ogpsd implementation.
>>> Sending a u-blox binary string into /dev/ttySAC1 with the same config
>>> message while fso-gpsd is working also doesn't work out (I've tried
>>> many times just in case I'm racing with the framework and messages get
>>> mangled).
>>>
>>> I've combed the framework code in that folder trying to find any 1s
>>> cycle hardcoded, but everything looks as it should: event-triggered by
>>> available data.
>>> So the 1M€ question is: where the heck is this 1s polling cycle
>>> defined? How can I get the ogpsd framework to output 4 samples per
>>> second instead of 1?
>>>
>>> Any hints will be appreciated.
>>>
>>> Thx,
>>>
>>> V.
>>>
>>> ___
>>> 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
>>
>>
>
> --
> View this message in context:
> http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2886833.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: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
I've tried configuring (via frameworkd's om.py) the chip with a 3000ms
period between samples, and sure enough gpspipe is outputting only one
set of messages per every 3 seconds - so this proves my CFG-RATE
message is correctly delivered.
However, I also see that the gpspipe output is... chaotic. Although
the NMEA timestamps are always correct (they skip 3 seconds),
sometimes the messages are delayed and then delivered in batches. For
example, there is nothing for 6 seconds, and both messages are
delivered together.
If I set the period to 5.25 seconds, I can see that all the timestamps
coming out of gpspipe end with ".00", which is obviously wrong.
Many of the sentences are repeated, like the SW couldn't wait for the
next UBX data block and just repeated the last data block.
Who is doing this sample mangling?
Citando Vasco Névoa :
>
> Hi all.
>
> I'm used to putting the GTA02's ublox chip into 4Hz sample mode for my
> research projects, but ever since I started using FSO and derivatives
> I can't get it to spit out anything other than 1Hz samples - so I just
> stop "fso-gpsd", configure the chip at my own will, and read directly
> from /dev/ttySAC1.
> However, this is the unfriendly way to do it, and I'd like to
> integrate this option with FSO.
>
> So I found the initialization sequence inside
> "/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/om.py"
> and added this to the end of "def initializeDevice", just before the
> "self.huiTimeout = gobject.timeout_add_seconds( 300,
> self.requestHuiTimer )":
> # increase sample data rate to 4Hz:
> self.send("CFG-RATE", 6, {"Meas" : 0x00fa, "Nav" : 0x0001,
> "Time" : 0x})
> Unfortunately, it doesn't change anything. "gpspipe -r" will still put
> out a single set of messages per second, even though the GPS chip is
> (hopefuly) configured for 4 sets per second. When used with the
> original gpsd in other older distros, this didn't happen; gpspipe -r
> outputs whatever the the gpsd delivers. So the problem is most likely
> in FSO's ogpsd implementation.
> Sending a u-blox binary string into /dev/ttySAC1 with the same config
> message while fso-gpsd is working also doesn't work out (I've tried
> many times just in case I'm racing with the framework and messages get
> mangled).
>
> I've combed the framework code in that folder trying to find any 1s
> cycle hardcoded, but everything looks as it should: event-triggered by
> available data.
> So the 1M€ question is: where the heck is this 1s polling cycle
> defined? How can I get the ogpsd framework to output 4 samples per
> second instead of 1?
>
> Any hints will be appreciated.
>
> Thx,
>
> V.
>
> ___
> 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
[FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Hi all.
I'm used to putting the GTA02's ublox chip into 4Hz sample mode for my
research projects, but ever since I started using FSO and derivatives
I can't get it to spit out anything other than 1Hz samples - so I just
stop "fso-gpsd", configure the chip at my own will, and read directly
from /dev/ttySAC1.
However, this is the unfriendly way to do it, and I'd like to
integrate this option with FSO.
So I found the initialization sequence inside
"/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/om.py"
and added this to the end of "def initializeDevice", just before the
"self.huiTimeout = gobject.timeout_add_seconds( 300,
self.requestHuiTimer )":
# increase sample data rate to 4Hz:
self.send("CFG-RATE", 6, {"Meas" : 0x00fa, "Nav" : 0x0001,
"Time" : 0x})
Unfortunately, it doesn't change anything. "gpspipe -r" will still put
out a single set of messages per second, even though the GPS chip is
(hopefuly) configured for 4 sets per second. When used with the
original gpsd in other older distros, this didn't happen; gpspipe -r
outputs whatever the the gpsd delivers. So the problem is most likely
in FSO's ogpsd implementation.
Sending a u-blox binary string into /dev/ttySAC1 with the same config
message while fso-gpsd is working also doesn't work out (I've tried
many times just in case I'm racing with the framework and messages get
mangled).
I've combed the framework code in that folder trying to find any 1s
cycle hardcoded, but everything looks as it should: event-triggered by
available data.
So the 1M€ question is: where the heck is this 1s polling cycle
defined? How can I get the ogpsd framework to output 4 samples per
second instead of 1?
Any hints will be appreciated.
Thx,
V.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] kernel with working g_ether to Windoze connection?
Thanks, Paul. I ended up upgrading from shr-testing to shr-unstable, and the problems are gone. So, the non-functional kernel+g_ether must have been: http://shr.bearstech.com/shr-testing/images/om-gta02/uImage-2.6.28-stable+gitr0e5fe639e234cdeb11d8441f19c5b3109a8b6a17-r2-om-gta02.bin And the current working one is: http://shr.bearstech.com/shr-unstable/images/om-gta02/uImage-2.6.29-oe10+gitr119805+f656a97d946a2529630c9770a72c10a24dc397f9-r3.4-om-gta02.bin I was just surprised to see the problem getting fixed and lost and refixed at least 2 times in a row. It feels like someone made a patch and it just doesn't stick - maybe it didn't make it upstream and sometimes it isn't appllied? I don't know the kernel source stream from vanilla down to SHR, so I'm talking out of my... imagination. ;) Anyway, I'm glad it is solved, and I hope it doesn't come back so easily again. Citando Paul Fertser : > Vasco Nevoa writes: >>> Why don't you just specify which kernel revision works and which >>> doesn't? How any kernel dev is supposed to solve your problems if you >>> even don't properly describe it? Why don't you use the kernel that >>> worked on your FR in the meantime? >>> >>> >> If I knew, I wouldn't have a problem, would I? :) > > At least you know the date (and the place you downloaded) the kernel > had no problems and the problematic revision you use now, but you > don't specify it. > > The kernel commit that finally fixed RNDIS issues was > f63e59c84aa21d2745f115209bf949eca27008b1 and it was added to > andy-tracking branch on Mar 16. I don't see anything related since > then. Since you don't specify what revision you use now, i'm unable to > even say if your rev includes the commit or not. > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] kernel with working g_ether to Windoze connection?
I would, but I don't think my employer would agree. :) I use nothing but FLOSS everywhere, except of course at work, where I have to use the "official workstation software"... :P And it is very handy to hack the latest tweaks on my neo while waiting for a compilation to finish... ;) Right now, the Neo is networkless with SHR-testing in a Windows environment: - wifi is no good; - bluetooth way too complicated; - USB doesn't work; - GPRS stalls and doesn't allow opkg update, so forget upgrade SO GIMME THE WORKIN KERNEL ALREADY!!! :D I just find it strange all this back and forth, one version it works, the next it doesn't, then it works again, then not is that patch so difficult to keep alive?? Citando jeremy jozwik : > switch to linux! or do a dual boot. i dont know how anyone could > manage to do anything with an openmoko without some kind of linux box. > > plus its free : ) > > 2009/5/6 Vasco Névoa : >> >> Hi folks. >> >> The opkg upgrade broke the USB connectivity to Windows boxes once again. >> >> Can anyone tell me which kernel versions have this running? >> >> Thx. >> >> V. >> >> ___ >> 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
[shr-testing] kernel with working g_ether to Windoze connection?
Hi folks. The opkg upgrade broke the USB connectivity to Windows boxes once again. Can anyone tell me which kernel versions have this running? Thx. V. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-testing 2009-05-02 broken?
I had to reflash because DBUS wasn't running the way it should and so all the phone apps were broken. :( But now the new kernel broke the windows USB connectivity again!!! Aaarrgghh!! Citando Robin Paulson : > 2009/5/4 Vasco Névoa : >> That's not all that broke. >> I "opkg upgrade"d today, and shr-testing wouldn't launch X11 after a reboot. >> It is looking for a bunch of modules named >> "/usr/lib/evas/modules/*/*/linux-gnueabi-arm-ver-pre-01/module.so", >> but the only ones that exist are >> "/usr/lib/evas/modules/*/*/linux-gnueabi-arm/module.so" >> So I linked the directories that do exist with the names that it is >> looking for, and it is working again. >> >> Why is X11 looking for "linux-gnueabi-arm-ver-pre-01" instead of >> "linux-gnueabi-arm", and why doesn't my system have it? > > someone upstream changed the name of the e packages, and opkg update + > opkg upgrade is now broken. > > apparently the only way to get the new shr-testing is to re-flash, or > do what you've done > > or wait till it's fixed by shr > > ___ > 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 2009-05-02 broken?
That's not all that broke. I "opkg upgrade"d today, and shr-testing wouldn't launch X11 after a reboot. It is looking for a bunch of modules named "/usr/lib/evas/modules/*/*/linux-gnueabi-arm-ver-pre-01/module.so", but the only ones that exist are "/usr/lib/evas/modules/*/*/linux-gnueabi-arm/module.so" So I linked the directories that do exist with the names that it is looking for, and it is working again. Why is X11 looking for "linux-gnueabi-arm-ver-pre-01" instead of "linux-gnueabi-arm", and why doesn't my system have it? Citando Angus Ainslie : > On Mon, 2009-05-04 at 17:11 +0300, Yogiz wrote: >> Thank you both for the information. I'll use this chance to check out >> the new Openmoko 2009 testing image and I'll return to SHR once the >> problem gets sorted out. >> > > Om2009 has the same problem as the issue is with e upstream. We are also > waiting/looking at a fix. > > Angus > > > ___ > 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-unstable]Blinking AUX button LED
Possible errors that lead to that situation: - bad rootfs kernel parameters in u-boot environment; -> check if you need to change them; - missing kernel modules for the specific filesystem you have formatted; -> either mismatch between rootfs and kernel images, or just plain bad kernel image; - corrupt root filesystem, flash it again -> pay CLOSE attention to the dfu-util parameters if you are new to this. Good luck!... :) Citando Davide Scaini : > uhm... > ... > ... > I can't give you an answer 'cause I get a kernel panic... and i can't connect > to the fr... ;-) > d > > On Thu, Apr 30, 2009 at 11:04 AM, Timo Juhani Lindfors > wrote: > Davide Scaini writes: > i do not boot at all... but > the message is > > Kernel panic - not syncing: VFS: Unable to mount root fs on > > unknown-block(31,6) > Your kernel lacks mtdblock support then? > > (ls -l mtdblock6 shows 31, 6) > > > ___ > Openmoko community mailing list > commun...@lists.openmoko.org[3] > http://lists.openmoko.org/mailman/listinfo/community Ligações: - [1] mailto:timo.lindf...@iki.fi [2] mailto:dsca...@gmail.com [3] mailto:community@lists.openmoko.org___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] 4-16 shr-testing is pretty good!
That explains it. :) Well, Xavier, I gave up on my Portuguese accentuated characters a while ago. Since I only use the keyboard's dictionary for SMS messages, it's ok (kids today are writing a lot worse on SMS than just a few missing accents...) ;) It would be good to have someday, but I won't bother opening a ticket when there is much bigger fish to fry first. Citando Paul Fertser : > Xavier Cremaschi writes: >> Vasco Nevoa a écrit : >>> And Raster's keyboard finally works the way it >>> should (fast and clean). >> >> With utf-8 support or not ? If I wrote 'ete' with my french dictionary, >> will it propose me 'été' ? >> Because IIRC, it was an utf-8 patch that made it very slow in the old >> SHR-testing... > > Without, the patch was reverted. > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.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: How to fix missing icons in SHR-Unstable
Removing e-wm-utils and installing it again, plus your file, worked for me (after today's update). Thanks all! :D Citando The Digital Pioneer : > Ahh, so I guess I halfway fixed it without noticing... OK, so reinstall > e-wm-utils and then fix applications.menu? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Detecting ethernet gadget connections
I opened a ticket on that a while ago... https://docs.openmoko.org/trac/ticket/2178 No progress in 3 months... Citando Daniel Benoy : > I'm working on a script that will detect which network interfaces > are connected and mess with the routing accordingly, but I'm having > trouble detecting whether my USB ethernet gadget connection is up or > down. > > > ethtool when it's up: > lisa:~# ethtool usb0 > Settings for usb0: > Link detected: yes > > ethtool when it's down: > lisa:~# ethtool usb0 > Settings for usb0: > Link detected: yes > > > Unlike on the host side, the usb0 interface doesn't appear and > disappear, allowing udev scripts to bring up/down the interface. > > Anyone know if there's a way to detect that a network connection has > actually been established? > > -- > Daniel Benoy > http://daniel.benoy.name > > ___ > 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 unstable] no USB networking (with Windows)?
There is also a closed ticket for the same bug (with different symptoms, but that should be a Windows problem I guess): http://docs.openmoko.org/trac/ticket/1279 It looks like this patch is going in and out, or something... the problem comes and goes depending on kernel version... Citando Paul Fertser : > Vasco Névoa writes: >> Second, a weird problem I'm having... I updated my system with opkg >> yesterday, and a bunch os problems were corrected (yay!) and I'm using >> the phone in "everyday life", but now I can't login via SSH on my >> windows box. > > http://docs.openmoko.org/trac/ticket//2211 > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR unstable] no USB networking (with Windows)?
Thanks Paul, that's exactly it. So, it's most probably a 2.6.* USB driver problem and we'll have to wait for the kernel folks to get it right... Citando Paul Fertser : > Vasco Névoa writes: >> Second, a weird problem I'm having... I updated my system with opkg >> yesterday, and a bunch os problems were corrected (yay!) and I'm using >> the phone in "everyday life", but now I can't login via SSH on my >> windows box. > > http://docs.openmoko.org/trac/ticket//2211 > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR unstable] no USB networking (with Windows)?
Hi folks. First off, a BIG THANKS to the SHR team; this is the best distro I tried for GTA02 in a long while. :) Second, a weird problem I'm having... I updated my system with opkg yesterday, and a bunch os problems were corrected (yay!) and I'm using the phone in "everyday life", but now I can't login via SSH on my windows box. This works just fine if I reboot into the "Hackable:1" distro on the card and also worked fine with the OM2008.12/testing distro previously on flash. The "g_ether" module is loaded and the usb0 interface is UP and configured with the correct IP... but the Windows box just doesn't connect anymore. I don't have a Linux box here, I'll have to try much later on. Hints, anyone? Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: password vault?
Thanks Rainer & Angus!! :) Citando Fox Mulder : > I'm useing KeepassX [1] which is opensource and available for windows, > linux, handy java j2me, on usb-sticks and many more. The database is aes > encrypted and is compatible between all these keepass versions. It is > available in the openmoko debian repo. > > Ciao, > Rainer > > > [1] http://www.keepassx.org/ > > Angus Ainslie wrote: >> Try Pyring it's on opkg.org >> >> On Jan 9, 2009, at 7:24 AM, Vasco Névoa wrote: >> >>> Hi all. >>> >>> Does anyone know a good "password vault" application that we can use >>> in OM? >>> >>> Thanks, >>> >>> Vasco. >>> >>> ___ >>> 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 > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
password vault?
Hi all. Does anyone know a good "password vault" application that we can use in OM? Thanks, Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Car Charger?
Citando Rui Miguel Silva Seabra : > Shouldn't it have to be 2A ? Why should it? If the FR can charge at 3 different rates (100, 500, 1000mA), any charger that can give 500 or 1000mA is good enough... it all depends on how much time you want to wait for a charge... ;) I tested it right now, and it does charge. The problem is that this "Trust" car cigarette lighter USB charger does not have the "ID pin" resistor [1]. Even when using a standard USB-to-miniUSB cable the FR recognizes the charger as a 100mA "host" port (and charges at 100mA, which is not good enough). So I used the sysfs entries in [2] to force it to 500mA and 1000mA and all went well - it can charge just fine, but has to be forced because there is no auto detection. So now I just install the usb charging control scripts in [2]... :) [1] http://wiki.openmoko.org/wiki/USB_charger [2] http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode Happy hacking! Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Car Charger?
Well... not exactly. I bought a "Trust" car lighter adapter (5V/1A) with its own cable, and it doesn't charge the freerunner. After reading all this, I think it must be the cable. I'm going to try with a standard cable instead of the supplied one. The supplied cable is very handy, it has all kinds of optional plugs for many kinds of phone and gadget; because of this, it has only power lines going through it, and no data lines at all (it's got a small plug with only 2 contacts where the other adapter plugs connect). I'll let you know... Citando Gothnet : > > Thanks for all the answers guys, looks like I can grab any old USB charger, > 5V/2A being preferable. > > And a GPS style wndscreen mount would be useful. I'm sure I can find > something though. > -- > View this message in context: > http://n2.nabble.com/Car-Charger--tp2106770p2112932.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: gsm0710muxd and OM 2008.12
I had a few problems with that myself, but they ended when I simply
removed all gsm0710muxd links from /etc/rc*.d/.
I think it gets launched on demand when you call it via dbus... and so
the 89qtopia line does the trick.
If you let it launch via 2 different ways at the same time, there
seems to be a race for modem control and QPE ends up loosing the battle.
This is working for me.
Citando Ed Kapitein :
> Hi Jan,
>
> I had the same problem and found an even dirtier sollution ;-)
> I found that sometimes gsm0710muxd will give an /dev/pts/X but you can
> not use it, there is no response from the modem.
> And sometimes even stopping gsm0710muxd and starting it again would not
> help.
> so in order to have it working all the time i modified
> /etc/X11/Xsession.d/89qtopia
>
> just below
> export QTOPIA_PHONE_MUX=ficgta01
>
> i added:
> #---
> echo 0 > /sys/devices/platform/neo1973-pm-gsm.0/power_on
> sleep 2
> /etc/init.d/gsm0710muxd stop
> sleep 2
> killall -9 gsm0710muxd
> sleep 2
> echo 1 > /sys/devices/platform/neo1973-pm-gsm.0/power_on
> sleep 2
> /etc/init.d/gsm0710muxd start
> sleep 2
>
> identvar=$(date +%s)
> ptsvar=$(dbus-send --system --print-reply --type=method_call
> --dest=org.pyneo.muxer /org/pyneo/Muxer
> org.freesmartphone.GSM.MUX.AllocChannel string:$identvar | grep string |
> awk -F '"' '{ print $2 }')
>
> export QTOPIA_PHONE_DEVICE=$ptsvar
> echo $QTOPIA_PHONE_DEVICE
> #---
>
> (the ptsvar line is one long line, it might be chopped up in the mail)
> In my opinion, this will reset the modem no matter what.
> and i removed gsm0710muxd from all run levels
> ( update-rc.d -f gsm0710muxd remove )
> I am using stock 2008.12, nothing from another repro.
> So far this is working flawlessly for me.
>
> Inspired by the [FSO/SHR/debian] SMS location app, i wrote some scripts
> to check for an incomming SMS and send me the GPS location of my FR.
> So i needed the gsm0710muxd to read the SMS, while still being able to
> use the phone.
>
> Kind regards,
> Ed
>
>
> On Mon, 2008-12-29 at 14:07 +, Jan Henkins wrote:
>> Hello Eldon and Olivier,
>>
>> Eldon, I've been scratching my head on this very same issue.
>>
>> On Sun, December 28, 2008 08:31, Olivier Berger wrote:
>> > Eldon Koyle writes:
>> >
>> >> I just spent a while tracking down an issue with 2008.12 and
>> >> gsm0710muxd. I upgraded an FDOM image, so I'm not sure if anyone else
>> >> will see this problem, but just in case I thought I'd send this to the
>> >> list.
>> >>
>> >> 2008.12 was starting xserver-nodm before gsm0710muxd, so the dbus call
>> >> added in /etc/X11/Xsession.d/89qtopia started a separate gsm0710muxd
>> >> process without any args before gsm0710muxd was started by init which
>> >> caused gsm0710muxd to fail to work.
>> >>
>> >> A quick fix is to change xserver-nodm from S04 to S23 (gsm0710muxd is
>> >> 22) or so in /etc/rc5.d .
>>
>>
>> Hmm, a dirty fix, but something I will try out. I will let you know if it
>> succeeded. BTW, I'm using the stock 2008.12 image with Illume (ASU *very*
>> broken...).
>>
>>
>> > Well... and would you mind to share with us the problem you're trying
>> > to solve ? It's far from obvious what this gsm0710muxd may be doing,
>> > and how it's missing ;)
>>
>> Olivier, it would seem to me that the issue is the following:
>>
>> xserver-nodm starts up before gsm0710muxd. The problem comes in that qpe
>> needs to connect to a device, which is supposed to be created by
>> gsm0710muxd. This is neccessary in order to multiplex gsm and gprs,
>> otherwise you have an either/or situation (better to have both voice and
>> gprs, at least it is for me! ;-) Now, qpe complains that it cannot find
>> the device as configured in the 89qtopia file, and then dies. This is true
>> even if you launch qpe with app-restarter like this:
>>
>> /usr/bin/app-restarter "$QTOPIA_MESSAGE" qpe 2>&1 | logger &
>>
>> Doing a dirty fix like Eldon suggested *might* help, I will try and
>> confirm this on my FR.
>>
>> > Btw, did you file a ticket in the bug tracker ?
>>
>> It seems to be a bit more complicated than simply filing a ticket, since
>> it is a strange situation to debug. To compound the issue, it would also
>> seem that gsm0710muxd might be the faulty link in the chain, since I could
>> not get it to work properly. Furthermore, I've been reading about random
>> hassles with gsm0710muxd on a few blogs here a there, where it is
>> reccommended to use the gsm0710muxd from the Angstrom repo instead of the
>> 2008.x version. I found this to be a dicey route to follow, since
>> everything in Angstrom is newer than 2008.12, and you will end up having
>> to update just about the entire base due to dependencies. Ouch...
>>
>> Maybe somebody else have experienced the same issue with gsm0710muxd in
>> 2008.12? Please let us know. If we can get parity on actual version
>> numbers and replicate the problem between two or mo
RE: New 2008.12 Release
Citando KaZeR : >> Strange, I have an OM2008.9 fully updated with "testing" and >> my bootup time is 30 seconds more than that... anyone can >> explain this? > I have double checked: 39s > Note that i'm talking of time to destktop, at that point for example gsm > hasn't registered to network. With OM2008.9/testing and ASU theme + gsm0710muxd service, it' definitely around 60 seconds. > It's the faster i have seen on FR currently. Yep. :) > Maybe it's partly because (thanks to ;) ) QI? That should only make a difference in the first part of boot (until the first kernel line) I think... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: New 2008.12 Release
Citando KaZeR : > Pro : > - OMG fast boot time (press power for 8 seconds (boring, why so long?), > start stopwatch at first line of text. Time to desktop : 38s! Strange, I have an OM2008.9 fully updated with "testing" and my bootup time is 30 seconds more than that... anyone can explain this? > - Phone goes to suspend even if you have usb connected. So, you loose the > network connection. But that has always been like that, right? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New 2008.12 Release
That's strange, I didn't get the announce mail... Citando Rui Miguel Silva Seabra : > On Fri, Dec 19, 2008 at 12:25:19PM +0200, Yogiz wrote: >> >> > > Good news. I'll still wait for the announcement and for some >> > > feedback before I roll it on. I've spent too much time >> > > customizing my 2008.9 to mess with it. >> > > >> > I've received the official announcement around 30 minutes ago. >> In this list or where? >> >> Could someone point out the biggest changes? > > OpenMoko announce list. > > http://lists.openmoko.org/pipermail/announce/2008-December/28.html > > Rui > > -- > P'tang! > Today is Pungenday, the 61st day of The Aftermath in the YOLD 3174 > + No matter how much you do, you never do enough -- unknown > + Whatever you do will be insignificant, > | but it is very important that you do it -- Gandhi > + So let's do it...? > > ___ > 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: Answer from Joerg (was: Re: Crackly Calls and Battery Tips! A5/A6 rework. Corrected URL)
I did the big-c buzzing rework myself, with the precious help of a much more smd-experienced colleague. It was very difficult to replace the resistor because of the proximity of the components around the mic. A very sharp soldering iron is critical. I used a 1k resistor (didn't have a 2k2 of the same size at hand), and a 100uF/10V tantalum capacitor. So far, so good! The buzz seems to be gone for good. :) One caller has reported that I sounded like "at the bottom of a pit", but this can be the other older issue... Citando Paul Fertser : > Joel Newkirk writes: >> Still waiting for an answer from OM. (I posted a question in this thread >> Friday regarding Tanatalum instead of Ceramic cap - the difference being >> $0.25 vs $2 each in qty 100, and my radio guy thinks Tant is a good choice >> for filtering, but waiting for word from Steve or Jeorg) > > Joel, Joerg overlooked your question on the community mailing list, > you should have asked at hardware list instead. I asked him on IRC: > here's the answer: > > 12:57 < PaulFertser> DocScrutinizer: could you please answer a > question wrt capacitor type for the gsm buzz fix? Joel Newkirk asks > whether he can use tantalum instead of ceramic ones as tantalum are > much cheaper and he's going to perform a rework on a reasonable > quantity of units (IIRC). > 13:00 < DocScrutinizer> PaulFertser: we don't have any tantalum caps > here, and I would guess they are just too big. I was about to suggest > a free caeramic cap for everyone asking for it. actually I'll bring a > handfull of those to Germany on Sunday > 13:00 < DocScrutinizer> PaulFertser: technically there is nothing > wrong with tantalum > 13:01 < DocScrutinizer> though I'd guess they are somewhat harder to > solder, as they're basically electrolytic caps and so won't stand much > heat > 13:01 < PaulFertser> DocScrutinizer: if you don't mind, i'm going to > post your answer on the community mailing list in the corresponding > thread. > 13:02 < DocScrutinizer> go ahead, you're welcome > 13:02 < DocScrutinizer> just quote this dialog is fine > 13:04 < DocScrutinizer> also, to whom it may concern, I plan to join > 25C3 congress in Berlin, and maybe rework a couple of devices there > for free, or at very least give away caps > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.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
[OM2008] USB events -> scripts?
Hi all. I want to run a script automatically every time the USB is plugged or unplugged. Where should I hook in the scripts? /etc/apm/?/... or somewhere else? I've looked into using the /etc/network/interfaces, but this doesn't work because usb0 does not get "downed" on unplug - so it is always "up" since booting... Thanks, Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Android] Converting a brick into a phone
I'm kinda confused here... is this "buzz issue" the one where the caller (not the neo) hears the GSM buzzing? The one that has a SOP repair paper with the "Big C"?... or is it something else? Citando Michel <[EMAIL PROTECTED]>: > Steve Mosher wrote: > > Hi Steve, > >> A list on the wiki of all severe problems and the end user details >> would be great, especially for future reference. Some of the problems, >> like Buzz, 1024 (recamp) seem to happen to some people and not others. >> I never had the buzz problem, go figure. > > I've created the page. > >> 1. problems: WSOD, recamp, Buzz, echo ( insert gripe) >> 2. End user data: >> a. email (optional) >> b. Date code on phone ( under battery) >> c. s/n >> d. p/n >> e carrier. >> f. 900Mhz or 850? >> g distro etc... > > The page links from > http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware_Issues#Poor_Audio_Quality > > And you can find it here: > > http://wiki.openmoko.org/wiki/Buzz_or_not > > Please ad fields if necessary > >> anything else? It might be nice to know what band the phone is operating >> on ( 900/1800/1900) if that's possible. > > Tell me how I can find that info on the phone :) > >> Steve > > Regards, > Michel > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > ___ > 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: Crackly Calls and Battery Tips! A5/A6 rework. Corrected URL
I'd really like pictures with better focus and a little more light... especially the last one, which is very blurred! Citando Steve Mosher <[EMAIL PROTECTED]>: > Sorry, > >I pulled the old copy. See below > > SOP paper (draft3, 2008-12-10 19:00) placed here: > > http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP__DRAFT3__.pdf > > > Please have a look and report on any mistakes or things that need > improvement. > > Thanks > jOERG > > Neil Jerram wrote: >> 2008/12/10 Steve Mosher <[EMAIL PROTECTED]>: >>> The DRAFT fix for the buzz problem is here: >>> >>> C&P of joerg's mail. >>> >>> >>> http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP__DRAFT!!__.pdf >> >> I'm getting 404 for this URL. >> >> 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 > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.8][testing] qpe no longer respects QTOPIA_PHONE_DEVICE ?
There is no problem with QPE and the QTOPIA_PHONE_DEVICE var. The problem is that gsm0710muxd gets started twice (via rc.d init scripts AND the dbus request inside 89qtopia) and QPE gets a bogus ptsvar and falls back to /dev/ttySAC0. I removed the rc.d startup of the muxer because dbus is capable of launching it upon request: update-rc.d -f gsm0710muxd remove And it all works (GSM+GPRS)! :) Citando William Kenworthy <[EMAIL PROTECTED]>: > I'm also noticing today that the batget utility is blocking (using top), > sometimes several instances get caught up and the phone starts to slow. > removed the battery module (its utterly useless in illume anyway) and > things run much better. > > Overall though, there are fewer problems than 2008.9 :) > > BillK > > On Fri, 2008-12-05 at 11:42 +, Vasco Névoa wrote: >> After today's testing upgrade, QPE is ignoring env var >> QTOPIA_PHONE_DEVICE and going right for "/dev/ttySAC0" instead of a >> /dev/pts* like I want it to. >> What is the new way to make it pick another device? >> Surely you devs haven't forgotten there are people using gsm0710muxd?... >> >> ___ >> 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
[OM2008.8][testing] qpe no longer respects QTOPIA_PHONE_DEVICE ?
After today's testing upgrade, QPE is ignoring env var QTOPIA_PHONE_DEVICE and going right for "/dev/ttySAC0" instead of a /dev/pts* like I want it to. What is the new way to make it pick another device? Surely you devs haven't forgotten there are people using gsm0710muxd?... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
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?
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 "
Re: [OM2008.x] praise for the new testing image
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... 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
Re: Raster keyboard on daily testing
See: http://wiki.openmoko.org/wiki/Keyboard_Debate#How_to_install_the_illume_.28Raster.27s.29_keyboard_.3F Beware: at least on my system, when I replace the base "asu" theme with the "illume" theme, Enlightenment crashes a lot. Citando Armin ranjbar <[EMAIL PROTECTED]>: > How to get raster keyboard working on daily testing images ? > > > -- > Armin ranjbar , System Administrator > > ___ > 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
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 > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
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: [OM2008.x] praise for the new testing image
Another 2 positive points I forgot to mention: - the UCSD messages are now correctly displayed (yay, I can see my account balance!!) - the illume resume bug (on first tap) is finally gone! (yay, no more danger of running out of battery during the night if an SMS or call comes in). Citando Vasco Névoa <[EMAIL PROTECTED]>: > > I've followed the "community update" tip and upgraded from OM2008.8 > "stable" to "testing". After a little havoc caused by the previously > installed gsm0710muxd, I finally got it to work on the GTA02v5. > I've only had it for a day now, but already I am very pleased with the > results! > Reduced boot time, volume control during calls, and apparently a very > well optimized energy consumption (still evaluating that). > "Jolly good show, lads"!! :D > Keep hacking that kernel, you're definitely in the right track now. ;) > I can't wait for WiFi to get on track... :) > > My only gripe is the absence of Raster's keyboard, that I haven't been > able to recover after the update... what's the magic there? > > Happy Hacking, > > Vasco. > > ___ > 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
Citando William Kenworthy <[EMAIL PROTECTED]>: > Can you confirm that you can receive an SMS after being *suspended* for > ~10 minutes or so? For me the phone comes out of suspend, but I have to > reboot (or restart X) to get at the message, and twice the phone (not X) > crashed after I accessed a message. > Looking for confirmation I am not the only one seeing this with the > update ... No problem so far over here, sorry!... I just got a couple of messages a few minutes ago, and it was definitely sleeping... Make sure your home files (if they are on card) that are acessed by QPE are not a problem. Search in logread for any binary compatibility qtopia problems; I remember there are some "registry" files that qtopia keeps that maybe out of synch with the real libs installed... Something that happened to me was that QPE was exiting because some file-indexing thread was dying... it works fine now that I disabled sd-card (home) indexing in /opt/Qtopia/etc/default/Trolltech/Storage.conf. > I got rasters keyboard - in fact I cant get rid of the bloody thing! - I > would like to just have terminal and none of the others as they keep > changing back and forward halfway through typing messages :) You're right, it is a PITA. Do you have QTOPIA_NO_VIRTUAL_KEYBOARD=1 inside /etc/X11/Xsession.d/89qtopia ? Happy Hacking! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
Citando Tony Berth <[EMAIL PROTECTED]>: > didn't you get WSOD? No, I never got it, with this image or with any other. I suppose it is HW-related?... probably one of those HW tolerances that is triggered by bad SW habits... :( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[OM2008.x] praise for the new testing image
I've followed the "community update" tip and upgraded from OM2008.8 "stable" to "testing". After a little havoc caused by the previously installed gsm0710muxd, I finally got it to work on the GTA02v5. I've only had it for a day now, but already I am very pleased with the results! Reduced boot time, volume control during calls, and apparently a very well optimized energy consumption (still evaluating that). "Jolly good show, lads"!! :D Keep hacking that kernel, you're definitely in the right track now. ;) I can't wait for WiFi to get on track... :) My only gripe is the absence of Raster's keyboard, that I haven't been able to recover after the update... what's the magic there? Happy Hacking, Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] gsmspeakerout.state
I really don't like the fact that the state files have ALL the controls in there. Can't we eliminate the unnecessary controls inside each file? I don't see why a "speakerout.state" file should have microphone settings... it just adds to the confusion, and creates competition between apps. Citando Alastair Johnson <[EMAIL PROTECTED]>: > Matthias Apitz wrote: >> El día Wednesday, November 19, 2008 a las 08:46:27AM +0530, Carl >> Lobo escribió: >> >>> I think you need to restore the gsm*.state files only when you are on >>> call. the ringing from speaker requires mappings from stereoout.state. >> >> Ok, I think that without deeper knowledge about the files I'm lost. Can >> some kindly soul sheet a bit light into this darkness? I.e. >> - Why there are different files? > > Because depending on what you are doing you want to send sound to > different places, and with different levels. It is simpler to have a > small set of files containing the mixer states for known situations than > it is for every app to store all the mixer settings itself. > >> - Which process is reading them, in which order and when? > > Anything that wants to, whenever it wants to, more or less. Essentially > if an app wants to use a particular mixer state then it makes a call to > set the mixer to that state. FSO has a dbus API to make this a little > more orderly, and qtopia may have something similar, but this doesn't > prevent an app setting things directly. > > Because it is up to the app to do the setting you may find that an app > doesn't switch to the state you want, for example when you answer a call > the phone app may switch to the gsm-handset state even though you have > the headset plugged in. > >> The Wiki http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem >> speaks about 'states' like 'State: GSM <-> Built-in Handset (file >> gsmhandset.state)', but does not explain what a given 'state' is and how >> the transit between them happens... >> >> Thx >> >> matthias >> > > ___ > 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: New home for the New FDOM
I've also tried FDOMizer yesterday, and I had to patch it by hand in a few cases. Mainly, I had to update a few download links from angstrom-distribution.org . Citando Jonathan Schultz <[EMAIL PROTECTED]>: > I just tried updating my FDOM using FDOMizer from the 20080927 > version and have had some gains but a few losses and problems. > > Some of the applications work but others (notably GnuChess and > Openmoocow) don't. In particular GnuChess just goes and consumes > all available CPU without apparently doing anything. OpenMooCow > doesn't appear to do anything either but at least doesn't take any > CPU time. > > I'm guessing here but I'd think that all those forced dependencies > are likely to be causing problems. For example I only have gtk+ v > 2.10.14-r2 instead of 2.12.11; libglib-2.0.0 v 2.6.16.1-r4 instead > of 2.16.4; libcairo2 v 1.4.10-r0 instead of 1.6.4. Should I be > using a different repository here? > > There were a couple of files that the script attempted to download > from angsgtrom that weren't available. Curiously enough the files > that are available are older versions than those requested by the > script. These are: > > http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/libpurple-protocol-msn_2.5.1-r0.1_armv4t.ipk > http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/libpurple-libjabber_2.5.0-r0_armv4t.ipk > > There was something funny about the rc.local file, which the script > update-rc.d expected to find in /etc/init.d but which were in /etc > I copied it then re-ran update-rc.d and things looked a bit better. > > I suspect that I'd be better off abandoning the FDOMizer script and > reinstalling the latest version, which seems a pity because update > scripts are a great idea. > > Cheers, Jonathan > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
Citando Kishore <[EMAIL PROTECTED]>: > Since i got my neo rather recently, i have only tried 4.4.1. Is 4.3 still the > better choice? A couple of days ago i lost my daily use phone > (motoming A1200) > and so i now need to use the FR as my daily phone. I've been using ASU (OM2008.9) since the beginning as my daily and only phone for months now, without great problems. It stinks for SMS texting, and it is a PITA to find a contact on the list (both of these are bad designs of Qtopia), but otherwise it does the job well. The only big problem is a "denial-of-service" that happens because os resume problems... sometimes I get an SMS or some other event that wakes up the phone, and if I don't touch the screen, it stays awake until the battery dies. This is why sometimes I wake up to a dead phone, even though I went to bed leaving it almost fully charged. :( ___ 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?
John, this new Update is an excelent move in several aspects. Keep it going, and thank you very much!! Citando John Lee <[EMAIL PROTECTED]>: > 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 > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Community newsletter, October 4th to 19th
Excellent report, Minh! I've been having too little time to follow the traffic, you're a life saver! :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flashing in (K)Ubuntu Linux 64bits
That's very strange to me... I've got Ubuntu 64bits, and no such problems. I just turn on the FR in the NOR bootloader (AUX->POWER, not POWER->AUX), and then go right ahead and use dfu-util without having to specify the device number... if the machine does not detect it, relaunch dfu-util. Maybe you guys have some USB hardware inside your machines that is capable of DFU (weird, but possible on laptops)... try "dfu-util -l" without the FR plugged in. Citando Patrick Beck <[EMAIL PROTECTED]>: > Hello jotalix, > > i think you have the same problem as me, when i start to flash my > Freerunner. dfu-util has detected two devices (./dfu-util -l) so i have > to select one with the parameter --device. For example => > > ./dfu-util -a rootfs --device listed-id -R -D image.rootfs > > with kind regards > > Patrick > > Am Donnerstag, den 16.10.2008, 04:13 -0700 schrieb jotalix: >> Kubuntu, 64bits >> >> Hi, >> >> I am able to browser inside Neo Freerunner gta02, i do ssh >> [EMAIL PROTECTED], and do whatever i need inside. >> >> But i want to flash it to a recent version, and here comes the problem, i >> can only use dfu-util with my Neo on bootloader ,and while on bootloader >> kubuntu dont recognize it as a USB device whatever,... so how can it be >> possible to flash it? >> >> best regards, >> jotalix > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the basics: improving user experience
I can see there are at least 2 distinct types of user of OM: A - "I need a working phone now, the uber-cool PDA stuff can wait"; B - "OM is a groundbreaking project, I don't care about telephony, let's press the revolution!" As much as I am divided among the two views, I think OM must oblige to its responsibility towards the users who have paid for their hardware, and keep its promise of a working phone. I don't think that making the core system work (including a little hacking of the Qtopia stuff) is a waste of time; any insight that is gained here can immediately be applied to FSO. OM2008.x will simply serve as a real-world testbed (one that is everyday usable!). When FSO comes along, it will already have the necessary corrections... Citando Didier Raboud <[EMAIL PROTECTED]>: > Vasco Névoa wrote: > >> >> I agree with you partly; the main efforts should go into getting the >> new framework out - *as long as it runs on a rock-solid core system*. >> So I support the idea of accelerating the FSO integration... but in >> the meantime people have to use the sucking Qtopia ware in their >> everyday life, because there is no realistic alternative. FSO is still >> very incomplete at the user level. >> >> Today, the "complete" system is not reliable and the reliable system >> is not complete at all. >> >> If you fix the core and qtopia now, everybody gets a working phone, >> and FSO gets a more reliable development core. You favor the users, >> which are the noisier people. ;) >> If you jump start FSO into main distro, there will still not exist a >> complete system that can be used everyday. You favor the developers, >> who could wait a little more (but not long!) and ARE ALSO USERS. >> >> So please just make it work solidly, and then integrate FSO. :) > > Well... I would rather let a bit more freedom to the team : > > if you (as in "the team which will make the iFoan obsolete") think that > breaking useability or functionality or anything else could serve the > cause : do it ! > > Please decide your roadmap and make it public ! > > I (personnally) don't care if I am not able to use my Neo as a phone (and > anything else possible) for 2-3-4-5 months : I have a working phone. BUT, > what I would like to know is _when_ I will get _what_ functionality. > > I you think that breaking the whole stuff for a moment will serve a precise > goal, please do it ! > > Regards, > > OdyX > -- > Swisslinux.org - Le carrefour GNU/Linux en Suisse - > http://www.swisslinux.org > > > ___ > 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: Back to the basics: improving user experience
I agree with you partly; the main efforts should go into getting the new framework out - *as long as it runs on a rock-solid core system*. So I support the idea of accelerating the FSO integration... but in the meantime people have to use the sucking Qtopia ware in their everyday life, because there is no realistic alternative. FSO is still very incomplete at the user level. Today, the "complete" system is not reliable and the reliable system is not complete at all. If you fix the core and qtopia now, everybody gets a working phone, and FSO gets a more reliable development core. You favor the users, which are the noisier people. ;) If you jump start FSO into main distro, there will still not exist a complete system that can be used everyday. You favor the developers, who could wait a little more (but not long!) and ARE ALSO USERS. So please just make it work solidly, and then integrate FSO. :) Citando Neil Jerram <[EMAIL PROTECTED]>: > 2008/10/16 Riccardo Centra <[EMAIL PROTECTED]>: >> 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. > > I agree that you should not spend time on Qtopia. Even though I use > Qtopia most of the time, I would prefer you to focus all your efforts > on the lower levels (up to and including the FSO dbus interfaces) > until they are rock solid. > >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
Re: OpenMooCow 0.1
Lightsaber??? yuck, no way, the ayeFone has it already!!! :P We're better than that!!! Hey, Senkerik, how's the "Accelerometer Game" coming along??... Citando "Risto H. Kurppa" <[EMAIL PROTECTED]>: > On Thu, Oct 16, 2008 at 1:12 PM, Nishit Dave > <[EMAIL PROTECTED]> wrote: >> We want Teh Lightsaberz!! > > Yes, lightsaber was the first application I was able to think of when > I heard that a phone would have accelerometers. > > Anyone? > > > r > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > 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: Back to the basics: improving user experience
An important note to the people who are experiencing all-round instability: I haven't had many problems with phone calls or SMS. I believe the critical point was to disable QPE's file search upon bootup [1]. Before I did that, I had all kinds of mysterious problems (including PIN), derived from the fact that the Neo's CPU was starving for cycles. To make matters worse, it would suspend before the indexing job was done, and so the Neo would not have enough CPU power to correctly process incoming calls and messages when it resumed. After disabling that QPE stuff, it basically works. [1]: http://n2.nabble.com/No-pin-dialog--qpe-tp685679p685679.html Citando John Lee <[EMAIL PROTECTED]>: > > What do you want us to work on? > Prioritized: 1 - Solve the call quality problems (echo, buzzing, volume) for 99% of the users. 2 - Solve the illume resume problems. They have been talked about over and over, but unfortunately the information is scattered and imprecise. the tickets themselves have misleading info (I should know, I helped confuse you...), so maybe this deserves a new single ticket, where everyone contributes with more exact information; 3 - Get the wifi driver corrected, so that it does not create link association and stability and problems; 4 - Finish/validate implementation of the networking stack (all the way up to resolv.conf and friends); 5 - Merge the GPRS muxer into the stable distro, so that it works out of the box; 6 - Integrate the main applications with the power management: if QPE wants to index the whole friggin' filesystem right after boot, then give it time to do so before going into suspend; if you don't, it just bogs down the CPU for many suspend/resume cycles, creating all sorts of problems, and we don't know what is going on... 7 - Accelerate Qt applications - they respond so slowly that a normal user will shoot itself in the foot everyday (i.e. pushing the "Answer" button twice because it didn't appear to respond, effectively killing the call; or taking the phone to the ear after pushing "Answer" and having it rind loudly one last time in the ear); 8 - Work with the people of FDOM to integrate the best workarounds and hacks - they did the work already, just use it. 9 - Get all the bluetooth support organized out-of-the-box. I haven't played with it in a long time, but it looked like black voodoo to get a simple pairing and OBEX exchange going... forget about PAN!... 10 - Put a "speaker" button on the dialer app. This is my only GUI desire for now... Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] How to export Vcf Contacts from FR?
Great! Now I know which client to use, let's play!!! :)
I've spent 15 minutes reviving my SQL (which I had forgotten for at
least 5 years), and this is what I have so far:
*
sqlite3 /home/root/Applications/Qtopia/qtopia_db.sqlite 'Select distinct
nickname, title, firstname, middlename, lastname, suffix, profession,
b_webpage, company, office, department, jobtitle, default_email,
phone_number, h_webpage, spouse, gender, birthday, anniversary from
contacts, contactphonenumbers where
contacts.recid=contactphonenumbers.recid;' | sed 's/|/\t/g' >
addressbook.txt
*
This creates an addressbook "tab-delimited-file" with all the fields I
thought where important for each contact (some info may be missing,
check the columns and tables).
Each contact that has more than one phone number will appear multiple
times because I haven't yet come up with a clean way to show the "join"
between the "contacts" and "contactphonenumbers" tables, so for now it
just duplicates the whole line, with the only difference being the phone
number.
Anyone versed in SQL will be able to hack this into a full VCF file
generator... or you can just go the Python way (but I prefer to use the
nice tools already in place) :)
Your turn! ;)
Paul wrote:
> Hey Vasco,
>
>>> You mean creating VCF's from the sqlite-data in a backup?
>>> Would be interesting to play with. I could envision a slq-script that
>>> dumps the data into a file and then a bash or python script that puts
>>> things in the proper format. That's not too difficult, if sqlite plays
>>> nice.
>>>
>>>
>> I had thought about that too, but I can't find an SQLite client in OM
>> repos to create the necessary script.
>> How can we talk to SQLite on OM without going the full C/C++ and
>> respective libs way? Python maybe?...
>>
>>
>
> I found sqlite3 on my desktop pc, which makes things a lot easier. I
> think that is included on anyone's Linux box these days, and on
> www.sqlite.com/download there are also precompiled binaries for Mac and
> Windows. You need sqlite version 3 for the .sqlite files on the FR.
>
> I've been playing a bit with it: copied a .sqlite file from the
> Freerunner to my machine and using sqlite3 I can pull information from
> it quite easily:
>
> echo ".tables" | sqlite3 qtopia_db.sqlite
> appointmentcategories contactpresence mimeTypeMapping
> appointmentcustom contactspimdependencies
> appointmentexceptions content servicehistory
> appointmentscontentPropssimcardidmap
> callhistory currentsimcard simlabelidmap
> callhistorytimezone databaseProperties sqlsources
> categories defaultMimeApplication syncServers
> categoryringtoneemailaddresses taskcategories
> changelog favoriteservicestaskcustom
> contactaddressesgoogleidtasks
> contactcategories locationLookup versioninfo
> contactcustom mapCategoryToContent
> contactphonenumbers mimeTypeLookup
>
> echo ".dump contactphonenumbers" | sqlite3 qtopia_db.sqlite
> BEGIN TRANSACTION;
> CREATE TABLE contactphonenumbers ( phone_number VARCHAR(100) NOT
> NULL, recid INTEGER, phone_type INTEGER, FOREIGN KEY(recid)
> REFERENCES contacts(recid) );
> INSERT INTO "contactphonenumbers" VALUES('04x875',83886113,1);
> INSERT INTO "contactphonenumbers" VALUES('07x693',83886209,1);
> INSERT INTO "contactphonenumbers" VALUES('+3167678',83886277,257);
> INSERT INTO "contactphonenumbers" VALUES('049275',83886193,1);
> INSERT INTO "contactphonenumbers" VALUES('118',83886361,1);
> INSERT INTO "contactphonenumbers" VALUES('+316244',83886365,1);
> INSERT INTO "contactphonenumbers" VALUES('+3162233',83886357,1);
> CREATE INDEX contactphonenumbersbytype ON contactphonenumbers
> (phone_type, phone_number);
> CREATE INDEX contactphonenumbersindex ON contactphonenumbers (recid);
> CREATE INDEX contactphonenumbersnumbers ON contactphonenumbers
> (phone_number, recid);
> CREATE INDEX contactphnenumberscontacts ON contactphonenumbers (recid,
> phone_number);
> COMMIT;
>
> I can imagine a python script on the desktop/laptop that would read all
> the dumps, disect all the insert statements, combine the information
> based on the recid attribute and after pulling all that together, write
> out Vcards.
>
> Note that I am using qtopia. I am not certain if the structure on
> OM2008.x is identical. If that is the case, I can imagine a config file
> per distribution, mapping attribute-names to the necessary Vcard
> entries. (I have a lot of imagination.) You'd then run the python script
> with a parameter telling it what config/mapping to use.
>
> I am sure I can write something like that. I am however not sure how
> long it would take me, as
Re: Weekly Engineering News 41/2008: back to the basics
You, me, and Schindler makes 3. I guess by the time this actually happens, it'll be a large party!! :) Citando Rui Miguel Silva Seabra <[EMAIL PROTECTED]>: > On Wed, Oct 15, 2008 at 02:01:01PM +0100, Vasco Névoa wrote: >> The day I see my Neo booting in 5 seconds or less with a rock-solid >> audio and networking stack (including wifi) and no standby/resume >> problems... Woohooo, I'll fly from Portugal to Taipei myself and pay a >> round of beers to the OM people!!! :D :D > > I'll join you! That way even more rounds of beer happen ;) > > Rui > > -- > Wibble. > Today is Pungenday, the 69th day of Bureaucracy in the YOLD 3174 > + No matter how much you do, you never do enough -- unknown > + Whatever you do will be insignificant, > | but it is very important that you do it -- Gandhi > + So let's do it...? > > ___ > 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: Weekly Engineering News 41/2008: back to the basics
I couldn't be happier!!! OM is listening indeed. :D I know a few people will probably be disappointed because the eye-candy won't get much attention for the next few months, but I know that as soon as everybody start reaping the benefits of the Neo as a lean-and-mean-robust-machine then our love for the OM project and the faith on OM products will grow exponentially, not only inside the community, but also outside. We will finally be able to show the public what this project is about, without suffering inappropriate comments such as "what, you can't pick up a call on your new phone??"... ;) People often fail to see the beauty when in presence of a small spec of dirt. The day I see my Neo booting in 5 seconds or less with a rock-solid audio and networking stack (including wifi) and no standby/resume problems... Woohooo, I'll fly from Portugal to Taipei myself and pay a round of beers to the OM people!!! :D :D Citando "Risto H. Kurppa" <[EMAIL PROTECTED]>: > Hi! > > Just want to make sure everyone knows that the weekly engineering news > has been released again, see > http://lists.openmoko.org/nabble.html#nabble-td1336450|a1336450 > > I want to highlight this: > "We decided to focus our > engineering on just the basics, even less eye candy: Robust kernel, > fast boot time, basic telephony with great audio quality, powerful > configuration from the command line, hardware quality. That's it. > We will stop working on our Installer, Locations, Diversity and > Settings applications. We will get back to all this when the rest is > rock solid, but now is not the time. Feel free to pickup any of these > projects in the meantime" > > I suppose this is generally a good thing to let the community do what > it can do (as long as community has the tools and so on to do it) and > Openmoko focus on the core stuff. > > Comments? > > > > r > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > 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: Echo issue on OM2008.08 solved
Thanks Treviño!
However, qpe complains of binary compatibility:
Coult not load "/opt/Qtopia/plugins/phonevendors/libficgta01vendor.so"
errorString() "The plugin
'/opt/Qtopia/plugins/phonevendors/libficgta01vendor.so' uses
incompatible Qt library. Expected build key "arm-angstrom-linux-gnueabi
What can I do to make QPE take the new library?
Citando Matthias Apitz <[EMAIL PROTECTED]>:
> El día Wednesday, October 15, 2008 a las 08:18:40AM +0200, "Marco
> Trevisan (Treviño)" escribió:
>
>> Here you are [1]. It includes also the mwester fix for re-registering
>> network and my workaround for GSM firmware crash. I hope it won't have
>> any incompatibility with your installed Qtopia...
>>
>> [1]
>> http://downloads.tuxfamily.org/3v1deb/openmoko/libficgta01vendor-echo-cancellation.so.tar.gz
>
> Thanks for this. I've installed it this way:
>
> # cd /opt/Qtopia/plugins/phonevendors/
> # mv libficgta01vendor.so libficgta01vendor.so.orig
> # mv ~/libficgta01vendor.so .
>
> # /etc/init.d/xserver-nodm restart
>
> interestingly the restart did not asked again for the PIN of the SIM (a
> full re-boot does);
>
> during outgoing call one now hears some noise like you have sometimes
> when radio wafes of a GSM is affecting a normal phone call;
>
> when I change in gsmhandset.state the section 'control.4' to values
>
> control.4 {
> comment.access 'read write'
> comment.type INTEGER
> comment.count 2
> comment.range '0 - 127'
> iface MIXER
> name 'Speaker Playback Volume'
> value.0 127
> value.1 127
> }
>
> the outgoing RING tone nearly killed my ear; with 111 for value.[01] it is
> fine, but with the above described noise; what is your
> gsmhandset.state file for
> this? thx again
>
> 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: Accelsense.org (accelerometer-based gestures)
I forgot to mention: 7 - device rotation (for screen orientation and OpenMooCow) :) Citando Vasco Névoa <[EMAIL PROTECTED]>: > Hi Paul. > Your tenacity is indeed an example. Congratulations on the fusion of > your academic and hacking lives! :) > I don't want to burden you even more, but I'd like to remind you of a > couple of details that may turn out to be important in the long run. > One thing I would like to see come true is the implementation of an > accelerometer framework that is flexible enough to accommodate all > kinds of usage, not just gestures, and you are basically sitting on it > (horay!!!). :) > Examples: > 1 - human gestures; > 2 - seismic vibrations (distributed earth quake detection), see [1]; > 3 - travel "dead reckoning", whether of humans, human-powered > vehicles, or motorized vehicles; > 4 - road comfort level and trail quality level assessment (Z-axis > vibration for geo map tagging); > 5 - morse tapping (for awkward emergencies, you never know...); > 6 - anything else you may think of in the future... > > My point is, please at least _try_ to include in your design some kind > of easily extensible framework, possibly allowing dynamic plugins or > at least compile-in modules, and package your specific gestures work > as the first modules. And obviously, the ability to support multiple > kinds of listener clients at the same time. I know it is a lot to ask, > but I think it is very well worth it. > The future community will thank you very much! :) > > Happy hacking!!! :D > > [1] > http://n2.nabble.com/Idea-for-Openmoko-application%3A-seismic-sensor-network-tp1106366p1106366.html > > Vasco. > > Citando "Paul V. Borza" <[EMAIL PROTECTED]>: > >> Hi everyone, >> >> A couple of people asked me whether I will or won't continue my >> project on accelerometer-based gestures. >> My answer was always yes, and to make that clear, I've bought >> accelsense.com, and accelsense.org. >> The code has moved from http://code.google.com/p/accelges/ into a GIT >> repository located at http://repo.accelsense.org. >> >> I'm now in the first year of masters, and I've managed to get two of >> my courses into the accelerometer-based gestures (i.e. to implement >> this as homework). >> From now on, my professors require me to use SOMs (i.e. >> self-organizing maps, a type of neural networks), instead of hidden >> Markov models. >> >> A couple of you guys asked whether the efficiency and speed can be >> improved using HMMs. Again, the answer is yes, just that I don't have >> time to work on the HMM implementation anymore. >> >> Just wanted to let you know that from now on, I'll focus exclusively >> on working with the Neo, rather than the Wii to test the gestures; and >> make them smooth and natural. >> Nokia is using SOMs for gesture recognition in mobile phones, so we >> should be on the technology wave as I can tell (still, I'm just one >> guy). >> >> What I'll focus on in the 0.2 release: >> * use some code from the rotate application that is flying around. >> * keep the current Dbus system for interaction. >> * 10% of CPU (it's now using 20%), and yes it's doable. >> * no GUI, but change the text console UI to be something like 'top', >> and not just printf hundreds of xyz data. >> * reintegrate with matlab-compatible diagrams. >> * will still be in C99 and under LGPL. >> * math formulas that are used in code will have a link to >> http://wiki.accelsense.org/wiki/ and the formula will be written >> in LaTex. >> * some of you gave me advices on how to improve the organization of >> the project, will also do that. >> * some dependencies aren't checked, there are too many you say, will >> be removed. >> * integration with the freesmartphone.org Dbus FSO communication >> system (I've seen that it grew since I last checked it). >> * implementation of self-organizing maps. >> >> Bottom line: I'll be trying turn it in a mature project ;) >> >> You can do interesting things with SOMs, like Nokia was doing: >> detecting when the user climbs down, up or walks, just using an >> accelerometer. >> >> Thanks, >> Paul >> >> ___ >> 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: OpenMooCow 0.1
I'm getting this error on OM2008.9 stable: openmoocow: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory Solved with "opkg install libsdl-1.2-0" Thanks for this cute toy!!! :D Remark: shouldn't it "moo" both ways (up and down)? presently it only "moos" when I turn it back to upright position... :( Citando Thomas White <[EMAIL PROTECTED]>: > I'm pleased to be able to announce version 0.1 of my "advanced > accelerometer and audio framework testing system", OpenMooCow. > Available from http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/ > > When installed and run, OpenMooCow displays an artistic rendition of > a fine specimen of Friesian dairy cattle. Invert the device and return > it to an upright orientation to experience the pinnacle of audio > rendering "kwality". > > The sound effect can be altered by putting a suitable WAV file > in /usr/share/openmoocow/moo.wav. A credit is due to Chris Hendricks > who is the author of the original sound file (obtained from > www.flashkit.com). > > Comments/abuse to this address. > > Tom > > -- > > Thomas White > Department of Materials Science and Metallurgy > Electron Microscopy Group (PhD Student) > University of Cambridge / Downing College > > ___ > 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: Accelsense.org (accelerometer-based gestures)
Hi Paul. Your tenacity is indeed an example. Congratulations on the fusion of your academic and hacking lives! :) I don't want to burden you even more, but I'd like to remind you of a couple of details that may turn out to be important in the long run. One thing I would like to see come true is the implementation of an accelerometer framework that is flexible enough to accommodate all kinds of usage, not just gestures, and you are basically sitting on it (horay!!!). :) Examples: 1 - human gestures; 2 - seismic vibrations (distributed earth quake detection), see [1]; 3 - travel "dead reckoning", whether of humans, human-powered vehicles, or motorized vehicles; 4 - road comfort level and trail quality level assessment (Z-axis vibration for geo map tagging); 5 - morse tapping (for awkward emergencies, you never know...); 6 - anything else you may think of in the future... My point is, please at least _try_ to include in your design some kind of easily extensible framework, possibly allowing dynamic plugins or at least compile-in modules, and package your specific gestures work as the first modules. And obviously, the ability to support multiple kinds of listener clients at the same time. I know it is a lot to ask, but I think it is very well worth it. The future community will thank you very much! :) Happy hacking!!! :D [1] http://n2.nabble.com/Idea-for-Openmoko-application%3A-seismic-sensor-network-tp1106366p1106366.html Vasco. Citando "Paul V. Borza" <[EMAIL PROTECTED]>: > Hi everyone, > > A couple of people asked me whether I will or won't continue my > project on accelerometer-based gestures. > My answer was always yes, and to make that clear, I've bought > accelsense.com, and accelsense.org. > The code has moved from http://code.google.com/p/accelges/ into a GIT > repository located at http://repo.accelsense.org. > > I'm now in the first year of masters, and I've managed to get two of > my courses into the accelerometer-based gestures (i.e. to implement > this as homework). > From now on, my professors require me to use SOMs (i.e. > self-organizing maps, a type of neural networks), instead of hidden > Markov models. > > A couple of you guys asked whether the efficiency and speed can be > improved using HMMs. Again, the answer is yes, just that I don't have > time to work on the HMM implementation anymore. > > Just wanted to let you know that from now on, I'll focus exclusively > on working with the Neo, rather than the Wii to test the gestures; and > make them smooth and natural. > Nokia is using SOMs for gesture recognition in mobile phones, so we > should be on the technology wave as I can tell (still, I'm just one > guy). > > What I'll focus on in the 0.2 release: > * use some code from the rotate application that is flying around. > * keep the current Dbus system for interaction. > * 10% of CPU (it's now using 20%), and yes it's doable. > * no GUI, but change the text console UI to be something like 'top', > and not just printf hundreds of xyz data. > * reintegrate with matlab-compatible diagrams. > * will still be in C99 and under LGPL. > * math formulas that are used in code will have a link to > http://wiki.accelsense.org/wiki/ and the formula will be written > in LaTex. > * some of you gave me advices on how to improve the organization of > the project, will also do that. > * some dependencies aren't checked, there are too many you say, will > be removed. > * integration with the freesmartphone.org Dbus FSO communication > system (I've seen that it grew since I last checked it). > * implementation of self-organizing maps. > > Bottom line: I'll be trying turn it in a mature project ;) > > You can do interesting things with SOMs, like Nokia was doing: > detecting when the user climbs down, up or walks, just using an > accelerometer. > > Thanks, > Paul > > ___ > 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.9][GTA02] a simple and quick GPS logger
I noticed the webmail interface screwed up the line breaks, so this time the scripts are attached. Here comes version 2. Changes: - Configured the u-blox chip to send only relevant messages; - Configured the u-blox chip to send 4 measurements per second instead of just one; - Don't try to power on or reconfigure the chip if it is already on; - Filter invalid messages (without a fix) out of the log files. To know how to generate the "*.ubx" files I use here, visit the wiki [1]. [1]: http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS#Configuration_for_a_higher_sampling_rate Enjoy. GpsLogOn.desktop Description: application/desktop GpsLogOff.desktop Description: application/desktop om_suspend_functions.sh Description: Bourne shell script log_gps_track.sh Description: Bourne shell script CFG-MSG-GPGLL-OFF.ubx Description: Binary data CFG-MSG-GPGSA-OFF.ubx Description: Binary data CFG-MSG-GPGSV-OFF.ubx Description: Binary data CFG-MSG-GPVTG-OFF.ubx Description: Binary data CFG-MSG-GPZDA-OFF.ubx Description: Binary data CFG-RATE-2HZ.ubx Description: Binary data CFG-RATE-4HZ.ubx Description: Binary data ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] How to export Vcf Contacts from FR?
Paul wrote: > Timo Jyrinki wrote: > >> Does anyone know how to not only make a backup, but to export back to >> VCF format from Qtopia/Om2008.8? I now added a section for it at >> http://wiki.openmoko.org/wiki/Import_Vcf_Contacts - the 2007.2 section >> has a script that handles it. >> >> I wouldn't want to actively change the addressbook if I cannot export >> from it to some standard format if I eg. change to FSO (or even back >> to 2007.2 / SHR!). >> >> > > You mean creating VCF's from the sqlite-data in a backup? > Would be interesting to play with. I could envision a slq-script that > dumps the data into a file and then a bash or python script that puts > things in the proper format. That's not too difficult, if sqlite plays nice. > > Paul > > I had thought about that too, but I can't find an SQLite client in OM repos to create the necessary script. How can we talk to SQLite on OM without going the full C/C++ and respective libs way? Python maybe?... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.8 default dialer crash on # or *
Treviño, can you please attach whatever patch you have for this on the Trac ticket (#1832, I think)? There are at least 3 tickets open with relation to this problem, and Holger is asking where is the patch... please put it up, even if it is not finished. I'm sure he will know what to do. :) Thanks! Marco Trevisan (Treviño) wrote: > Holger Freyther wrote: > >> On Thursday 18 September 2008 19:05:51 Marco Trevisan (Treviño) wrote: >> >> >>> Ok, I was right... The latest upgrade to phonevendor plugin in git >>> blocked it [1] >>> >>> Grab this [2] and put it in /opt/Qtopia/plugins/phonevendors. Restart >>> the phone (reloading qpe wasn't enough to me) and it should work. >>> >>> [1] 563d5f4c781efe1a11680c6a055b409034b528ab >>> [2] >>> http://downloads.tuxfamily.org/3v1deb/openmoko/qtopia-ussd-support-phone-ve >>> ndor.tar.gz >>> >> Source? Patch? GPL? >> > > You're right. Completely. I generally never release binaries without > diffs, but the patch I've with me is so bad and I'm so busy with my > personal tasks that I had no time to upload anything in the last days. > > I'll try to do this as soon as I can. > Sorry! > > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: accelerometer jitter
Joel Newkirk wrote: > Sorry. ;) Near-stationary, power consumption immaterial, as accurate as > possible. As a project to get my feet wet doing ground-up development > (probably Python, which I need to learn) for the Freerunner (instead of > just cross-compiling and fixing issues therein) I wanted to write a > software 'bubble-level' tool. Laid flat on a surface you see a bubble, > off-centered as a 'real' bubble-level would be to indicate pitch. More > generally, held with the side or back against a vertical or horizontal > surface to display an indication of how close to level (or vertical) the > surface is. Lots of incremental additions and changes possible, like > Have you looked at the "Accelerometer Game"? It would maybe give you a good jump start. http://projects.openmoko.org/plugins/scmsvn/viewcvs.php/?root=accelgame I have the first version installed and it pretty much covers the basic functionality of a bubble-level, but has momentum and bouncing. Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Idea for Openmoko application: seismic sensor network
Now that our phones have accelerometers and are Internet capable, how about contributing to the "Quake Catcher Network"? http://qcn-web.stanford.edu/Overview.html It is based on an open source project called BOINC (http://boinc.berkeley.edu/) and therefore I think OM would be a very nice addition to the sensor network. Maybe the "Gestures Daemon" could be expanded into something a little more generic (preferably integrated into FSO's Dbus API) and could filter the information, separating events by classes, like "Rotation of the Down vector", "Gesture", and "Seismic Vibration" (which are all mathematically different)... and so each client app (Rotate, Gestures Listener, BOINC, etc.) would pick up on the desired class of data. Just an idea... :) Vasco Névoa. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About OpenMoko Rotate
I haven't looked at the code yet, but my instinctive approach would be to calculate the direction of the "down" vector (constant 9.8m/s2 acceleration) and then compare that to the phone's "down" direction. It is the difference between these two vectors that I am referring to. Even if the error is great, surely it is not superior to 45 degrees (a quarter turn)? Is this not the way it is done? Fox Mulder wrote: > This is not so easy to do. The rotation comes out of a calculation of > the values from acceleration sensors. There are no "angle" sensors for > this operation. So there is no way of exactly say which angle the neo > currently has instead these are just aproximations. > > Ciao, > Rainer > > Vasco Névoa wrote: > >> That's very cool. I appreciate the mod. :) >> I'm seeing something that looks like a bug (in both versions)... but I'm >> not sure if the accelerometers require calibration or something. >> With the FR in vertical position, if I tilt it counter-clockwise, it >> takes just over 90 degrees to get 'accel-rotate' to change the >> orientation; but if I tilt it even less than 10 degrees clockwise after >> that, it reverts back to the original orientation. >> Shouldn't the threshold be set at the midpoint angles (45, 135, 225, 315 >> degrees)? >> Anyway, good work to both coders, it's just what I wanted. :D >> Maybe someone cares to extend this simple app to use some kind of sexy >> morph instead of the disruptive xrandr rotation? 8-) >> >> Rui Miguel Silva Seabra wrote: >> >>> Done. I've added a reference to it at http://wiki.openmoko.org/wiki/Rotate >>> but my page about it is at >>> http://blog.1407.org/2008/09/20/openmoko-rotate-now-using-libxrandr/ >>> >>> Users of Rotate, I've patched it so it doesn't use system+xrandr but >>> simply call directly the xrandr function using libxrandr. >>> >>> This means: >>> * quicker >>> * less battery consumption >>> >>> Best, >>> Rui >>> >>> On Fri, Sep 19, 2008 at 10:13:29AM +0100, Rui Miguel Silva Seabra wrote: >>> >>> >>>> Hi, >>>> >>>> I'm preparing a patch for using xrandr api directly in Rotate instead of >>>> system(). It's almost done but I can only code it at home time (which, for >>>> me, starts again in about 9 hours) :) >>>> >>>> This will be much better in terms of speed and battery life! >>>> >>>> Best, >>>> Rui >>>> >>>> >>> >>> >> ___ >> 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: About OpenMoko Rotate
That's very cool. I appreciate the mod. :) I'm seeing something that looks like a bug (in both versions)... but I'm not sure if the accelerometers require calibration or something. With the FR in vertical position, if I tilt it counter-clockwise, it takes just over 90 degrees to get 'accel-rotate' to change the orientation; but if I tilt it even less than 10 degrees clockwise after that, it reverts back to the original orientation. Shouldn't the threshold be set at the midpoint angles (45, 135, 225, 315 degrees)? Anyway, good work to both coders, it's just what I wanted. :D Maybe someone cares to extend this simple app to use some kind of sexy morph instead of the disruptive xrandr rotation? 8-) Rui Miguel Silva Seabra wrote: > Done. I've added a reference to it at http://wiki.openmoko.org/wiki/Rotate > but my page about it is at > http://blog.1407.org/2008/09/20/openmoko-rotate-now-using-libxrandr/ > > Users of Rotate, I've patched it so it doesn't use system+xrandr but > simply call directly the xrandr function using libxrandr. > > This means: > * quicker > * less battery consumption > > Best, > Rui > > On Fri, Sep 19, 2008 at 10:13:29AM +0100, Rui Miguel Silva Seabra wrote: > >> Hi, >> >> I'm preparing a patch for using xrandr api directly in Rotate instead of >> system(). It's almost done but I can only code it at home time (which, for >> me, starts again in about 9 hours) :) >> >> This will be much better in terms of speed and battery life! >> >> Best, >> Rui >> > > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ASU 2008.9] Is it required to reflash, or opkg update & upgrade is enough?
Alasal wrote: > I think (by looking at the bugs that are fixed and aren't fixed) that the > om2008.9 is the same as om2008.8 updated between 16 september and 18 > september. Because on 18 september there were updates for the om2008.8 that > aren't included by default in 2008.9. But the updates are also available for > the 2008.9. So If you install om2008.9 you can directly update it. > > So this review is valid for the om2008.9: > http://onlinedev.blogspot.com/2008/09/openmoko-om20088-status-review_16.html > And if you update your om2008.9, this review is valid: > http://onlinedev.blogspot.com/2008/09/openmoko-om20088-status-review_18.html > > Bottom line: > - an updated 2008.8 is the same as an updated 2008.9 > - an 2008.8 updated on 17 September is the same an an 2008.9 > > I'm not sure I trust that line of logic enough... Is there a way to check if we have the latest? If the opkg feeds have not changed, then it is logical that updated2008.8 = 2008.9 ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: (Wiki)(GTA02) Freerunner should have its own audio system wiki page
The page is started. I'll keep working on it as time permits. Please criticise/correct/add if needed. http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem Vasco Névoa wrote: > I think the page (1) has grown too much and too messy. Maybe it's time > to break it apart into 1973 & FR variants. > I know that both systems have a lot in common, but unfortunately they > are NOT equal. > I propose that the info about the FR is moved into a new page > (Neo_Freerunner_Audio_Subsystem) and that any common parts stay in the > present page, being referenced by the new page. > > An example of different info between both devices is the alsa state > files and alsa control channel numbers and names... this alone justifies > a new page to avoid the confusion. > > So, if you can help me by replying with the best known good alsa state > files and all other important audio info about the FR, I can quickly > write the new page. Yes, I will filter the lists in search of this info, > but I bet I will miss something important (I haven't been hacking the > audio system), so please help me out as well if you can. > > Any other suggestions are welcome. > > (1) http://wiki.openmoko.org/wiki/Neo_1973_audio_subsystem > > Cheers, > > Vasco. > > ___ > 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
(Wiki)(GTA02) Freerunner should have its own audio system wiki page
I think the page (1) has grown too much and too messy. Maybe it's time to break it apart into 1973 & FR variants. I know that both systems have a lot in common, but unfortunately they are NOT equal. I propose that the info about the FR is moved into a new page (Neo_Freerunner_Audio_Subsystem) and that any common parts stay in the present page, being referenced by the new page. An example of different info between both devices is the alsa state files and alsa control channel numbers and names... this alone justifies a new page to avoid the confusion. So, if you can help me by replying with the best known good alsa state files and all other important audio info about the FR, I can quickly write the new page. Yes, I will filter the lists in search of this info, but I bet I will miss something important (I haven't been hacking the audio system), so please help me out as well if you can. Any other suggestions are welcome. (1) http://wiki.openmoko.org/wiki/Neo_1973_audio_subsystem Cheers, Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
(OM2008.8-update) (audio/GSM) alsamixer names
Hi. Some callers have been complaining my GSM microphone level is low, so I've been reading the threads about echo cancellation and alsa state files, but every time I walk into alsamixer I get lost. I'd like to suggest different names for the Alsa controls, because quite frankly I cannot relate to the ones I see in alsamixer. But first I'd like to ask you guys if you feel the same need as me. Do you feel comfortable with the present alsa channel names, or would you like them to be clearer? I think that these names are confusing and sometimes even misleading. They should be closer to the user... like for example, from (1) we know that the "Voice" interface is connected to the bluetooth interface; why not call it "bluetooth"?? The same goes for PCM; I know "everybody" knows that PCM means "Pulse Code Modulated" and that can only come from the CPU, but can't we make life easier on ourselves and call it CPU or SoC or System or something more obvious that says "this is Linux's sound card"? The Mic1 and Mic2 could be called HeadMic and BuiltInMic or something. This would make it clearer for everyone messing with these settings, and so would help accelerate the troubleshooting of this complex system. As to the more obscure controls, like the MUXers and the intermediate routing volume levels, I'd like them to be less distracting and more accurate; they are used for several things, so they should not be named for external objects; how about calling them their wolfson datasheet names, like "LMSEL"?... this way we wouldn't need to constantly try to "decode" the meaning of each of these things, we'd just open up the picture (1) and everybody would know precisely what is being talked about... Basically, I'm trying to propose a naming scheme that separates "high-level stuff" (like plain Headphones and Microphone volume) from "low-level stuff" (like routing in the mixers). This would allow us newbies to play in alsamixer without fear of breaking some obscure routing that may later come back to bite us in the ear. Does anyone know where the alsa channel names are defined (which file)? Oh, and I think I see a bug: the channel names "Headphone" and "Speaker" are exchanged, as far as I can see. Phone call volume is controlled via "Speaker" and SoC music play is controlled via "Headphone"; Isn't this supposed to be the other way around? Please confirm/deny. (1): http://wiki.openmoko.org/wiki/Neo_1973_audio_subsystem#ALSA_Channels Vasco Névoa. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[OM2008.8-update] latest image + old /home/root = no GSM [solved]
I've been using my uSDcard as /home. So far, no problem, I reflash the device and mount it as /home and there it goes. I've done this with "testing" and "update" images without much problems. But today I was surprised to see that after reflashing I had normal GSM network, and after mounting my card's old /home/root and rebooting it became impossible to get the phone working. I reverted back to the original /home, and it worked again. In the "logread" I found a few Qtopia messages complaining about wrong plugin versions. I ended up doing "cp /home/root/.config/Trolltech.conf /media/card/root/.config/" and it solved it (qtopia keeps the lib versions inside this file). After restoring the card as /home in /etc/fstab and rebooting, the phone worked again. Hope this helps someone. vnevoa. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: context sensitive menus
Matt wrote: > Michael 'Mickey' Lauer wrote: > >> Am Saturday 06 September 2008 03:01:33 schrieb Matt: >> >>> On Windows Mobile (pocket pc), a long tap is like a right click; it >>> invokes a context sensitive menu. >>> If text is selected, there are options for copy/paste/cut. >>> >>> Are there plans for something similar for OM ? >>> >> We had this in OM2007.1, but lost it on the way. >> >> I'm not sure how generally useful this feature is. >> >> > > I think having an easy, intuitive, constant way to copy/paste text on a > device with no keyboard, will always be useful. > > Furthermore, I'd like to know that a long tap on a phone number will > always offer to Call Number, SMS, Lookup Contact, Add to Contacts. > > A long tap on selected text should offer to Save Note, Send SMS, Send EMail. > > A long tap on text which includes a date/time should offer to add an > event in the calendar too. > > A long tap on an address should offer to find it on a map. > > I'm sure there are many other instances where a long tap on 'something' > should allow an action to be performed with it. > People should chime in if they support it. > > At the moment, the FR is bearly able to compete with an old Palm Vx in > terms of intuitiveness. > > Yes, these are the things I miss the most after dumping my Windows Mobile for OpenMoko. We desperately need, at the very least, the copy-paste function. The phone & message related functions are a must, and the location-related functions are a very desirable (but still a novelty to design) feature. > ~ Matt > > ___ > 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: [2008.8][testing][kernel] image and modules not in sync?
Now in ticket: https://docs.openmoko.org/trac/ticket/1967 [EMAIL PROTECTED] wrote: > I've followed the discussion about dual booting, kernel packaging, and > kernel vs. distros, and the conclusion I reach is that the devs are > inclined to use (mostly-)monolithic kernels, leaving just the "extras" > out in the sysfs "modules" dir. > This is fine by me, but there seems to be a little mess here. > There are modules in the file system that are not loadable because > they are already built in. > This is not a good thing, because it induces the user in error - I > thought there was something wrong with the kernel or with the modules, > when the problem is just a question of cleaning up the repository & > filesystem images. > If the modules are built-in, they should not be present in the > filesystem, IMHO. > If a user follows the wiki howtos about networking, she may be trying > to modprobe bnep for example, and scratching her head because > "bluetooth" and "l2cap" won't load (let alone "bnep"). Only after > grepping /proc/kallsyms I understood these modules where already > built-in. duh! total time loss. > So please clean up a little, ok? At least the fs images on the > downloads server should be consistent with the given kernel. If an > update breaks things, that another issue entirely. > Thank you! Keep up the good work. > > ___ > 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: [2008.8/testing] where is pand?
This is now being discussed in the support list. pand has been removed, dbus support is in place. Vasco Névoa wrote: > Am I the only one to find that "pand" (the Personal Area Network daemon) > is missing and that it is no longer possible to establish a bluetooth > network connection with OM2008.8?... > > Vasco Névoa wrote: > >> Up-to-date 2008.8/update with "testing" feeds here. >> I can't find the "pand" to establish a bluetooth network connection. >> Can anyone tell me which package installs it? >> Thx. >> >> ___ >> 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: [2008.8/testing] where is pand?
Am I the only one to find that "pand" (the Personal Area Network daemon) is missing and that it is no longer possible to establish a bluetooth network connection with OM2008.8?... Vasco Névoa wrote: > Up-to-date 2008.8/update with "testing" feeds here. > I can't find the "pand" to establish a bluetooth network connection. > Can anyone tell me which package installs it? > Thx. > > ___ > 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
[2008.8/testing] where is pand?
Up-to-date 2008.8/update with "testing" feeds here. I can't find the "pand" to establish a bluetooth network connection. Can anyone tell me which package installs it? Thx. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: illume-config-illume on 2008.8-updates
Thanx Raster!! Finally got a decent keyboard. :) Geoff Ruscoe wrote: > > > Thanks Raster > > > > I also want to send thanks to the Rasterman! You've done so much to > help us all out. It is very appreciated. I now have a full keyboard > and wrench (and screen saver too). > > thanks again! > > > > ___ > 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: saving and restoring GPS data for U-blox chip quicker startup
digger vermont wrote: > On Sat, 2008-08-30 at 10:59 +0200, Abdelrazak Younes wrote: > >> There is at least two that I know of, some ruby script: >> http://docs.openmoko.org/trac/browser/developers/alphaone/u-blox >> >> And some python script in the FSO framwork. Look >> "framework/subsystems/ogpsd/" >> > > I just looked. It's in ubx.py. There was also recently a warmstart > patch committed. > > digger > > Nice! but that patch you mention is for FSO only, right? No ASU benefits there... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: saving and restoring GPS data for U-blox chip quicker startup
Abdelrazak Younes wrote: > There is at least two that I know of, some ruby script: > http://docs.openmoko.org/trac/browser/developers/alphaone/u-blox > > And some python script in the FSO framwork. Look > "framework/subsystems/ogpsd/" > Cool. What's the requirements to get alphaone's ruby scripts working in OM2008.8? Aside from "opkg install ruby"... >> I'd like to see the freerunner's GPS do the same any other GPS device >> does: save the almanac/ephemeris data to storage upon shutdown and >> restore it upon powerup. > Right. I just receive my freerunner today. So I may start my own plan > this week :-) > > Excellent. :) >> So, I took the protocol datasheet >> (http://www.u-blox.com/customersupport/gps.g3/ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm) >> and tried to coerce the chip into vomiting the stored information (we >> should take care to do it after working for at least 2 or 3 minutes with >> a good reception level). >> > > A better solution would be to just configure the Ublox to send the > ephemerises and almanacs as soon as they are received. I didn't know that was even possible... great! > A simple daemon > would watch for these messages and store them appropriately when they > are received. > > Makes sense. > Yes. The FSO is capable of doing that AFAIU. I have some code that do > that in C++ already, I'll publish them as soon as I port them to the FR. > My code will be able to read and decode a number of messages, including > raw data (pseudorange measurements). > > Wonderful. Just make sure you're not duplicating efforts with someone else... :) >> 2 - a simple hook into the UI gps on/off button script, forcing process >> (1) to ask for info and store it on file upon gps shutdown, and to >> rewrite that info into the chip on startup. >> > > I don't think we need any manual intervention here. The above described > daemon should just be reading only the device. Another program should be > responsible of writting the aid data as soon as the GPS is started. > Ideally this program could also be able to write manually encoded > messages based on commonly used formats for ephemerises (RINEX) and > almanacs (Yuma). > > >> Who's working on this? I'd happily beta-test it. >> > > I will, hopefully in the coming weeks :-) > > Fine. Keep us posted! > Abdel. > > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
saving and restoring GPS data for U-blox chip quicker startup
Hi all. I don't know how far anyone has gone in this subject, so I took the liberty to experiment. I'd like to see the freerunner's GPS do the same any other GPS device does: save the almanac/ephemeris data to storage upon shutdown and restore it upon powerup. I don't know much about GPS, but I imagine this would accelerate the startup, and it wouldn't hurt much if the device has changed geographical location in between (like after a plane trip, for example.) So, I took the protocol datasheet (http://www.u-blox.com/customersupport/gps.g3/ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm) and tried to coerce the chip into vomiting the stored information (we should take care to do it after working for at least 2 or 3 minutes with a good reception level). Basically: # Listen to the GPS port. Don't use gpspipe or any other "complicated" stuff because of internal filtering cutting the binary messages. U-blox binary protocol messages start with 0xB5 0x62. [EMAIL PROTECTED]:~# hexdump /dev/ttySAC1 | grep 62b5 # If you're suspicious of this, take a look at the direct output of "cat /dev/ttySAC1" and you'll be convinced when you see the ASCII output temporarily replaced by binary garbage. :) # Ask the u-blox chip for it's stored gps data, by sending the AID-DATA poll message (equivalent to sending AID-INI + AID-HUI + AID-EPH + AID-ALM, we could send each one alone if desirable): [EMAIL PROTECTED]:~# ./ubxgen.py 0B 10 00 00 > AID-DATA.ubx [EMAIL PROTECTED]:~# cat AID-DATA.ubx > /dev/ttySAC1 # out pours the requested data... (down at the end of this message) Now, this is just a start for a "proof of concept", and I think it has potential. The output is already in the same format it takes for input, and is separated into 4 different message categories, allowing us to modify some of the data if needed. So, what would be needed for this feature to be implemented? 1 - some process capable of writing and reading "ublox-binary" at /dev/ttySAC1; 2 - a simple hook into the UI gps on/off button script, forcing process (1) to ask for info and store it on file upon gps shutdown, and to rewrite that info into the chip on startup. Who's working on this? I'd happily beta-test it. My data (not really relevant, and probably incomplete because of the grep) 4c0 3030 2c38 3030 302c 2a30 4236 0a0d 62b5 500 4ba0 62b5 020b 0048 550 0007 d55d 62b5 310b 0008 0001 560 f745 62b5 310b 0008 0002 570 ff46 62b5 310b 0008 0003 580 0747 62b5 310b 0008 0004 590 0f48 62b5 310b 0008 0005 5a0 1749 62b5 310b 0008 0006 5b0 1f4a 62b5 310b 0008 0007 5c0 274b 62b5 310b 0008 0008 5d0 2f4c 62b5 310b 0008 0009 5e0 374d 62b5 310b 0008 000a 5f0 3f4e 62b5 310b 0008 000b 600 474f 62b5 310b 0008 000c 610 4f50 62b5 310b 0008 000d 620 5751 62b5 310b 0008 000e 630 5f52 62b5 310b 0008 000f 640 6753 62b5 310b 0008 0010 650 6f54 62b5 310b 0008 0011 660 7755 62b5 310b 0008 0012 670 7f56 62b5 310b 0008 0013 680 8757 62b5 310b 0008 0014 690 8f58 62b5 310b 0008 0015 6a0 9759 62b5 310b 0008 0016 6b0 9f5a 62b5 310b 0008 0017 6c0 a75b 62b5 310b 0008 0018 6d0 af5c 62b5 310b 0008 0019 6e0 b75d 62b5 310b 0008 001a 6f0 bf5e 62b5 310b 0008 001b 700 c75f 62b5 310b 0068 001c 770 f5a2 004d 8a90 62b5 310b 0008 001d 780 d761 62b5 310b 0008 001e 790 df62 62b5 310b 0008 001f 7a0 e763 62b5 310b 0008 0020 7b0 ef64 62b5 300b 0008 0001 7c0 ec44 62b5 300b 0008 0002 7d0 f445 62b5 300b 0008 0003 7e0 fc46 62b5 300b 0008 0004 7f0 0447 62b5 300b 0008 0005 800 0c48 62b5 300b 0008 0006 810 1449 62b5 300b 0008 0007 820 1c4a 62b5 300b 0028 0008 850 0001 ffea 7fa6 62b5 300b 0028 0009 880 0034 0001 312f 62b5 300b 0028 000a 8b0 000f dc57 62b5 300b 0028 000b 8e0 001b 0002 6f29 62b5 300b 0028 000c 910 001b ffd1 0a32 62b5 300b 0028 000d 940 000f 0023 5e7a 62b5 300b 0028 000e 970 0032 ffe2 4ccb 62b5 300b 0028 000f 9a0 ffda ffe9 f7a8 62b5 300b 0028 0010 9d0 ffed 000e 7eba 62b5 300b 0028 0011 a00 0004 0005 40f0 62b5 300b 0028 0012 a30 0039 ffed 0192 62b5 300b 0028 0013 a60 0014 0004 c1c7 62b5 300b 0028 0014 a90 001e 000d 676b 62b5 300b 0028 0015 ac0 001c 0006 faab 62b5 300b 0028 0016 af0
Re: Order from Pulster
enaut wrote: > Christoph Pulster schrieb: > >> Hello, >> >> thanks to Openmoko Inc. (great job Harry!) we received the new batch of >> units in time. So EVERYBODY who got an order confirmation from me for >> delivery-batch 15.08. will get his Freerunner in the next days. >> In other words, we are busy all the day to ship all orders. >> >> Despite very long delivery times and sometimes late replys from my side, >> Applause to my Openmoko customers, you all are very patient, >> understanding and very kind and friendly persons, >> >> Chris >> www.pulster.de >> Openmoko Shop >> >> > I recieved my Gummi bears yesterday :)... thx I was quiet exited about > the package by pulster I opened it and the first you see is a small > package of Gummi bears juhu :)... > > So I waited for more than a month and I can say, that it was absolutely > worth it. So just be patient for another week or two. Meanwhile the > software is getting better and better so the wow effect will be even bigger. > > enaut > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > > Oh yeah, I forgot to thank Christoph for the gummy bears too! Nice friendly touch! :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Where is ASU?
Hi folks. Sorry if I'm asking something too obvious, but I can't find the ASU images on http://buildhost.openmoko.org/daily/freerunner/... I see that all the links to ASU images in the mailing list end up in 404s... So, 2 questions: 1 - where are ASU images; 2 - what exactly is hosted in buildhost? FSO? Thanks in advance! Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
Hi. Sorry to barge in like this, but I don't quite understand the problem to begin with... Isn't open source code by definition protected against subsequent patents? It is part of the patenting process to search for conflicting publications; if they find any, then the candidate idea is not a novelty and cannot be patented. Publishing is the best weapon against (subsequent) patents: cheap and effective. I think we should just add some way to automatically timestamp every code check-in in a legally binding way, like using some outside certification entity's digital signature (that carries a legally recognizable timestamp). An open-source public repository is a valid publication of ideas, which are therefore not patentable. What do you think? - Mensagem Original - De: Sean Moss-Pultz <[EMAIL PROTECTED]> Data: Terça-Feira, 12 de Fevereiro de 2008, 4:25 Assunto: Re: Patents and OpenMoko > Nils, > > Thanks a lot for such an indepth reply. I need to think about a > lot of > these points. Let me just comment on a few now... > > On 2/11/08 Nils Faerber wrote: > > [snip] > > > > Are there any existing options available to us now? Does > anyone > > know of > > > > existing companies or organizations with a similar strategy > that > > we can > > > > seek guidance or partnership. > > > > > > > > Again, I want to emphasize that we only want our patents to > be > > used in > > > > defense. And what constitutes defense is something that we > want > > to be > > > > able to define (and potentially even redefine when new > threats > > arise). > > > > This is a noble aim but very very difficult to reach. > > Perhaps. But I think we should try our best... > > > Speaking as a free software acitvist especially software patents > are a > > complete no-go. > > Speaking as community guy I would say that with the software > patents > > you > > would have to sign and publish a non-revocable community > contract that > > sais quite explicitely for which use you would accept royaltee > free > > use > > and of which patents. Only then the community would be safe. > Else, at > > some later point in time, someone at OpenMoko/FIC might change their > > mind and try to make money from the patents. > > I think there is a way to get around this legal. We're getting > some > advice from the SFLC later this week. I'll keep everyone posted as > to > our plans. > > > > > Thanks in advance for the help. > > > > My very quick advice: Don't get your hands dirty with patents, > > especially with software. > > You will loose a lot of credibility in the free software world > and the > > benefit is questionable. > > With all due respect, I must disagree here. Not filing for > patents, is > hardly an option for a global company in this day and age. The > larger we > get, the more of target we become. > > I'm confident we can reach a solution that will be helpful for > both our > business and the community. I will keep you all posted as to our > progress. > Sean > > > > > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Ponha a sua Vida em Grande Plano! 10% DESCONTO ADICIONAL para adesoes on-line. Clique aqui para saber mais http://www.iol.pt/correio/rodape.php?dst=0801301 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Neo market status
Hi. There's one thing I'd like to see in the wiki or at openmoko.com: a sales status. Something a little more informative than Mc.D's "over one billion served". ;) I think it would be very informative to see a daily updated reality of how many Neos were actually sold. The wiki is already full of extrapolations, but there's nothing like the real deal. It would help us get a better image of the world we are moving in: how many Neos are out there? How big is the development pool? It would provide a sound base upon which to build the present wiki pages, which lay out the owners and wannabe owners. Is this doable? Vasco. ___ Quer credito? S, M ou XL? Saiba mais em http://www.iol.pt/correio/rodape.php?dst=0707183 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
