Re: Hardwarefixing at 26c3?
Am Freitag, 18. Dezember 2009 02:58:52 schrieb Matthias Eller: Hello, I am member of the 26c3 video-team. Some days ago, I replaced the 10µF capacitor successfully hoping fixing some kind of bug #1024. It was quiet easy. So if there is some need, I can provide fixing bug #1024 and other hardware bugs (buzz fix eg) at 26c3. So If you are planing to visit 26c3 and like me to do some fixing please respond to this mail (I need to order the parts). MfG Ello Great! Would be cool, if you could fix cosrahns and mine. Mine already has the buzz fix and needs to get #1024-fixed, cosrahns lacks both fixes. -- Fabian Henze signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Thursday, 20th of August 2009 14:04:49 UTC Sebastian Krzyszkowiak wrote: My opinion is simple. Developer of app provides bb file (or asks someone to write it) and then all distros provide that app in repo. And that's all. That's a great idea. But there has to be some way for a distro maintainer to get the latest bb files easily. Maybe a RSS feed, which contains all projects? -- Fabian Henze ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Annuncing new Project - Intone mplayer frontend
Hi, Well, intone - the media player in making (and it's **really** basic as of now), uses 0% CPU (according to HTOP (all my tests are with it). mplayer, in a separate thread uses its usual 15% or so. I'm using anjuta and glade for development, using fifo (named pipe) to communicate with mplayer running as slave and gtk+ for the frontend. As I have said before - the code is ***really*** basic. It makes a lot of assumptions, and is right now just a demonstration program - while I get some feedback on whether I need to put in any more time in it at all. If it is in such an early state, you might consider switching to some EFL based GUI library, like Elementary or Edje. Besides eating less RAM than your GTK+ program, they are also easier to use on touchscreen devices. Your ideas sound really promising, so please consider the switch to a toolkit, that was designed for small screen devices. (The right tool for the right job ;-)) -- Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On 30.11.2008 at 12:50:22, John Lee wrote: Since there are different hw versions out there (a5, a6, a7), it's impossible to provide one alsa state file that suits all models. Just a short question: What is a7? Can you please update the wiki article about the GTA02 revisions? -- Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
DIY Audioadaptor
Hi, I was about to solder myself an adaptor to use my headphones with the FreeRunner as an ogg/flac player. I have found some jacks, which seem to good for this task (german website): http://www.reichelt.de/?;ACTION=3;LA=2;GROUP=C161;GROUPID=3237;ARTICLE=47784 http://www.reichelt.de/?;ACTION=3;LA=2;GROUP=C161;GROUPID=3237;ARTICLE=47785 http://www.reichelt.de/?;ACTION=3;LA=2;GROUP=C161;GROUPID=3237;ARTICLE=9410 Now I wonder, whether a) the jack inside the fr is compatible to the ones of reichelt? b) I just need to connect the jacks with a proper cable or do I have to solder some resistor, capacitor or sth, different in between to work around the bad sound quality some people have noticed? -- Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: DIY Audioadaptor
On 28.10.2008 at 21:57:09, Marcel wrote: There's a notice on the wiki about a working adaptor I also own - didn't notice significant quality decrease with it and it works well. Just to possibly save you from soldering (although I know its fun). :) As far as I know this adaptor is mono-only, right? -- Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One more rotate version
Hey guys, I have spend more time optimizing the code and fixing bugs of my previous release. So here are the changes compared with my previous version: - Fixed a memleak - Changed the angle, which is required to initiate a rotation from 22.5° to 15° - Added a workaround for a bug in the input driver - fewer false positives - Reduced CPU time even more (when in idle it consumes about 600% fewer CPU cycles compared Rui's version. Non-idle workloads are hard to measure but the usage should be _at_least_ equal) - Achieved by introducing a hack, which might break if some parts of the system are compiled with different cflags. So please report if it is not working for you - Uses exactly 760 byte RAM now. - Added more comments - It's actually usable now (imo) - BUT: The accelerometers stop working after a while bug persists - Sorry Rui, still no patch for your version I hope you enjoy it. -- Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One more rotate version
On 21.10.2008 at 22:26:41, Fabian Henze wrote: Hey guys, I have spend more time optimizing the code and fixing bugs of my previous release. So here are the changes compared with my previous version: - Fixed a memleak - Changed the angle, which is required to initiate a rotation from 22.5° to 15° - Added a workaround for a bug in the input driver - fewer false positives - Reduced CPU time even more (when in idle it consumes about 600% fewer CPU cycles compared Rui's version. Non-idle workloads are hard to measure but the usage should be _at_least_ equal) - Achieved by introducing a hack, which might break if some parts of the system are compiled with different cflags. So please report if it is not working for you - Uses exactly 760 byte RAM now. - Added more comments - It's actually usable now (imo) - BUT: The accelerometers stop working after a while bug persists - Sorry Rui, still no patch for your version I hope you enjoy it. Whoops forgot the files. P.S. @Rui: you google code link seems broken. accel-rotate-allyouneed.tar.bz2 Description: application/bzip-compressed-tar rotate.tar.bz2 Description: application/bzip-compressed-tar ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One more rotate version
Hi Fabian, I'm adding your changes, and we should agree on an indent style. After skimming indent(1) I propose to use indent -kr. Yeah indent should not be an issue. Just use whatever you think is good and I will use it from now on. I'm not giving up on the brightness thing unless I can be proven the split screen isn't worked around with it, but we should add a flag for enabling/disabling it. What about enabling/disabling it with #ifdefs? This should work well as the code for the brightness handling is more or less seperate from the rest (iirc just three codeblocks). I'd just like to add the following (don't take me wrong, I'm not mad or anything even closer :) ): You can't really replace... * Copyright © 2008 Rui Miguel Silva Seabra [EMAIL PROTECTED] * * Inspired upon Chris Ball's rotate, this is a totally new rewrite. With... * Copyright (c) 2008 Fabian Henze [EMAIL PROTECTED] * * Based on Rui Miguel Silva Seabra's rotate, but more optimized for * speed memory usage and a better algorithm. Much apologies. I should have thought more about this part :) So in the mix and matching I'm doing, I'm writing: * Copyright © 2008 Rui Miguel Silva Seabra [EMAIL PROTECTED] * Copyright © 2008 Fabian Henze [EMAIL PROTECTED] * * Inspired upon Chris Ball's rotate, this is a totally new rewrite. Fine with you? Sure. Can you get a google mail account (just for having an account on code.google.com) so I can add you as a project member? *sigh* google ... yeah guess I can do that tomorrow. -- Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One more rotate version
On 20.10.2008 at 04:14:08, SCarlson wrote: Very snappy. It does die pretty quickly.. Due to accelerometer failing? How can I help test this further. I ran from command line and when it dies it just stopping writing to stdout. Also, if I re-run it just sits and waits for stdout. I assume this is the acc. problem that you mentioned above.? Scott Yes I think so. It might as well be a bug in my code, but as other rotate programs have the same problem (or build around it), this is not very likely. It would help, if anyone could tell me how to avoid the bug by altering some timeouts or how to predict the next death. I am currently trying if `cat /dev/input/event3` is also dying after a while, however it has not stopped yet. Is there some information on this bug around? I have not found anything in the bugtracker. -- Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One more rotate version
On 20.10.2008 at 12:00:36, Rui Miguel Silva Seabra wrote: On Mon, Oct 20, 2008 at 01:37:33AM +0200, Fabian Henze wrote: As it seems popular these days to publish a custom version of the rotate program, I am also going to do it. heh, you could've just sent a patch :) Then I would have to write in your style, which I am not used to :p After reading the source code of Rui Miguel Silva Seabra's rotate program, I found some parts that could be improved and hacked on those. The result differs from the original in the following points: - No brightness control (Its just annoying) I found that ever since I added it I never again had the weird split screen after rotation bug which sometimes happened when going horizontal. Doesn't that ever occur to you? It always occur if I switch from xrandr -o 1 to xrandr -o 3. However only then. - Imo better (and faster) heuristics I'll check on them and perhaps integrate. Great :) - uses fewer CPU cycles (I have not done much research, because it would not even show up in top) ? I hardly ever see mine on top, and even so when it did never more than 1% (especially with the dimmed screen). oh, okay^^ Your announce message said something around 0.9%. BUT: - It still suffers from the accelerometers stop working after a while bug. This is hopefully a driver problem (if it's a hardware problem we're SOL). Yeah hopefully. I have tried running cat /dev/input/event3 and it also stops after some time. @openmoko-devs: this would be a great bugfix for your 'back to the basics' path -- Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One more rotate version
On 20.10.2008 at 13:49:32, SCarlson wrote: Someone correct me if I'm wrong, but from what i've read, the accelerometers are not dieing but the mechanism that exposes them to /dev/eventX does.? Still able to view throught the /sys/proc route? That's possible but why do you care? The effect is the same. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
One more rotate version
Hi, As it seems popular these days to publish a custom version of the rotate program, I am also going to do it. After reading the source code of Rui Miguel Silva Seabra's rotate program, I found some parts that could be improved and hacked on those. The result differs from the original in the following points: - No brightness control (Its just annoying) - Imo better (and faster) heuristics - Fewer errors and false positives (the display won't rotate while the phone is shaken around or sth. like this) - uses fewer CPU cycles (I have not done much research, because it would not even show up in top) BUT: - It still suffers from the accelerometers stop working after a while bug. I would much appreciate feedback on the program and especially on the quality of the code. And I would even more appreciate a better accelerometer driver so userland hacks like one by Oscar Casamitjana are not necessary anymore -- Fabian accel-rotate.tar.bz2 Description: application/bzip-compressed-tar accel-rotate-allyouneed.tar.bz2 Description: application/bzip-compressed-tar ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing http://www.opkg.org
On 12.10.2008 at 11:30:06, Tobias Kündig wrote: Hello everyone, I'm proud to announce my newest project: http://www.opkg.org It's a simple database of available *.ipk-Packages. I know, some time ago there was someone other who planned to do something like this. But it's been a long time since then. I don't think they are working on it anymore... It just confirms what everyone is saying about Openmoko: Everything is unfinished and takes forever to be done. In my opinion that's not true. All of you do a really great job. So I wanted to give my contribution to the community and build that Homepage. That's great! Thanks for investing the time to do the homepage. There is a lot to improve on the site. These are (some of) my targets: * add Search-Box * improve «Package-Detail»-Screen * improve Home-Screen What about providing an ATOM feed [1] with the latest packages? -- Fabian [1] http://en.wikipedia.org/wiki/ATOM ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtopia]how to rotate screen from the shell?
On 02.10.2008 at 17:01:37, Joel Newkirk wrote: Google 'x11 rotate' or 'linux screen rotate' and you'll quickly find the command 'xrandr'. Resolution and Rotation controls. xrandr -o 0 - 'normal' xrandr -o 1 - 'right' xrandr -o 2 - 'inverted' xrandr -o 3 - 'left' -o for 'orientation', you can use the numbers or the string 'normal' etc. qtopia does not use X ... -- Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: expected write speed on microSD
On 19.09.2008 at 13:20:01, Nicolas Chauvat wrote: I have no problem when doing an scp of a new rootfs image to, say, /var/volatile/log which is a tmpfs, but untarring the system image to /dev/mmcblk0p2 or scp-ing the image directly to the same place is extremely slow. It gets as slow as 5 K per second. Writing ~50M takes hours. You mean scping from your desktop pc to the freerunner? This would be slow because of USB 1.1, but it should still be faster than 5 k. Are you still using the 2007.2 release, which comes with the stock freerunner? If yes try to upgrade to FSO or Om 2008.8 (is Om 2008.9 already out?) and test again. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Zhone with visual suspend feedback, Was: FSO milestone3 my view (ON gta01)
On 12.09.2008 at 12:24 +0200, Tilman Baumann wrote: Differenciating between suspend and shutdown is terribely hard. I almost never get the thing to sleep because i fear i would press power too long and shut it down. What happens quite often never the less. Agreed and this is especially annoying if you use the FreeRunner as a watch (like I do). On ASU that's: take the fr out of the pocket, press power, wait 1-2 seconds, see the time and press power again. But on FSO (which has a nicer clock, btw ;)) that's: take the fr out, press power, wait 1-2 seconds, see the shiny clock and then wait 2-4 seconds till suspend is triggered or press the button too long and shut it down. imho the 2 to 4 second timeout (I haven't figured out the exact time yet^^) is not really necessary, as the power button is so tiny, that it is very unlikely you press it by accident. So im my eyes a much better solution compared to the gui by Joachim Breitner, would be to disable the timeout completely. -- Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Zhone with visual suspend feedback, Was: FSO milestone3 my view (ON gta01)
On 12.09.2008 at 18:56:00, Joachim Breitner wrote: From what I’ve seen while coding the GUI (which is commited now), I think the reason why there is a timeout is that if there is not, the POWER press that you use to wake up the phone will be detected again... So how does it work on ASU? I think suspending on button _release_ should work fine. -- Fabian ___ 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
On Saturday 30 August 2008 at 10:59:29, Abdelrazak Younes wrote: A better solution would be to just configure the Ublox to send the ephemerises and almanacs as soon as they are received. A simple daemon would watch for these messages and store them appropriately when they are received. Why would this be a better solution? I dont see any benefits over the save on gpsd exit or save on 'gps off' in settings menu method, except that just another daemon steals CPU time and consumes RAM. Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC OpenMoko Bluetooth remote controller - now with Gestures
Am Mittwoch, 27. August 2008 13:33:15 schrieb Valerio Valerio: Hi, a ReMoko package with ability to send events through gestures (Paul's daemon - http://wiki.openmoko.org/wiki/Gestures) is available now in: http://code.google.com/p/remoko/downloads/list Sounds (and looks) great, but unfortunately I have no idea where to get the missing module from: Traceback (most recent call last): File /usr/share/remoko/remoko/remoko, line 37, in module from optparse import OptionParser ImportError: No module named optparse If I am not completly wrong this is some cython package, which is strange as python-cython-0.9.6.9-ml0.01 is installed. Fabian P.S.: I am currently using Om 2008.8 (as long as FSO milestone 3 is in the works) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What's Enlightenment doing for so long?
4. scanning disk for .desktop files (as these are all the applications) 5. scanning fonts for use Isn't it possible to cache stuff like this in just one file? So e can start using the cache and check for new .desktop files or fonts afterwards? 9. query some hal info (removable devices etc.) maybe this can be done after the e start? On Mon, 25. Aug 2008 12:53:17 Carsten Haitzler wrote: btw - app startup is generally very fast - if the apps are in c. i clock in a simple efl application at under 1 second (about 0.8) and a simple gtk app at about 1.5 secs or so. so as such toolkit isnt much of an issue here in start time. :) you are just going to have this kind of lag no matter what. lots of libs get resolved for symbols for pretty much any app using enough gui libs - there is x setup (connect, query for info etc.) and likely loading in of data from disk (icons, maybe fonts etc.) so... you're not going to really do much better i think just using efl. it doesn't matter much really. efl just tends to do a little less on init, but generally is more data-driven from files on disk (eg .edj files) and so needs to load these in too. In my opinion 1 second is pretty slow and afaik people get annoyed if anything (interactive) takes more than 0.5 seconds. What about using LDFLAGS to compile the programs (dont know if this is already used). or precaching commonly used applications like the Dialer, the SMS app or the contact list. Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Emergency call at boot time functionality (was Re: Windows CE on freerunner)
Am Samstag, 23. August 2008 19:04:18 schrieb Gilles Casse: It time is very critical, it seems better to let the phone continuously on. Otherwise is this scenario acceptable (automatic call after 3 minutes): the phone is off, the user still holds the power on button while the kernel is starting (say during 5 seconds or more), when the OS is operationnal, an automatic message is sent (with info on the user, possibly gps coordinates, etc...). This is problematic, if the power button is pressed while the phone is in the pocket. Maybe it would be possible to boot the kernel, gsm and X, then display a button for emergency calls while the rest (bluetooth, wifi and user interface stuff) is starting up. If the user presses the emergency call button the bootprocess stops/pauses and a menu like this shows up: 911 999 112 Continue booting Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
