QtMoko and X applicatiions
Is there any easy way to run X applications under QtMoko? I'm not mush of a Qt person, and QtMoko does not appear to have X set up by default. -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
TclFltk-1.0-538 Released for Openmoko, Windows and Linux
An updated version of the TclFltk scripting language development environment is available on the sourceforge project site. This update adds a text editor widget, support for mouse wheels (finger dragging on the phone) and includes a large number of bug fixes. Sound support for widget events is implemented, however, the GTA02 is a bit slow to make the experience really pleasant. Its compiled for ARMV4T as used on the GTA02 device. I would be happy to find out if it also runs on the GTA04 if anybody out there likes playing with scripted applications. I test on shr only, so I can't comment on other systems, but should be fine on anything running X11. Download: http://sourceforge.net/tclfltk/files/TclFltk-1.0.538-double_buffering-armv4t-Openmoko-8.5-X11-bin.ipk Note that you need the Tcl 8.5 distro running on your machine for this package to work. Updated documentation is found in the PDF file also available on the site. Packages are also available for Windows and Linux (deb, rpm) for those who like cross platform script development. Develop your phone app on your mainframe, run it on your phone! Comments and criticisms are always welcome. -- Iain B. Findleton 514-457-074438 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA-04 Tour boards?
Anybody know when the boards would be available for shipment? I would like to pick one up in Germany in April if that is possible. -- Iain B. Findleton 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-Core : Display issue?
Thanks. I reverted to an install of SHR-U, the whole thing, and stuff is working fine again. I will probably flash it. I ultimately did try SHR-core including the rootfs on uSD without any happiness. Will try again some time in the future. Benjamin Deering wrote: I seem to remember something about event filtering being moved from kernelspace to userspace. If that is correct, you are running without any event filtering. The signal from the touchscreen hardware is very noisy, and software is needed to average it out. Upgrading the rootfs might be a good idea anyway. I have the last shr unstable installed in NAND on my freerunner, and the latest shr-core installed on an sd card. SHR-core is stabilizing quickly and I use it as my daily phone now. If you have everything working the way you want it with shr-unstable it might be worth making a backup. Last winter I wrote myself a script to go from a fresh install to customized. It installs programs, adds extra kernel modules for some sensors I added, changes some config files, and downloads then extracts a backup of my home directory. This makes it a lot less daunting to do a reflash. Ben On 01/09/2012 10:00 AM, Iain B. Findleton wrote: I have been running the SHR 2.6.29 kernel for a while. Lately I tried to install the latest SHR-core kernel (2.6.39.4) WITHOUT installing the rootfs files. This procedure has worked fine for other kernel upgrades. In this latter case, while running 2.6.39, the display appears to have gotten into trouble in that touch screen locations appear to be wildly off. Applications no longer respond to button press activity as expected, and it appears that the coordinates of the press are off in the y direction by about 50% of the screen size. Anybody have an idea why this would be so? Is upgrading the rootfs a requirement for the new kernel? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-Core : Display issue?
Well, I certainly am having lots of problems getting a working SHR back. GPSD non-responsive, enlightenment screen goes crazy. Wish I had my 2.6.29 era setup backed up somewhere:( If it ain't broke, don't fix it, I guess. Benjamin Deering wrote: you have to use --numeric-owner while untaring it. Otherwise ownership of some files might be wrong - which then causes stuff like dbus-activation to not work correctly causing GSM to not work correctly. Btw. GSM is unrelated to connman. I didn't know that, that explains some problems I had when I tried to install 017 on my spare FR recently. I have installed an older (011ish maybe?) tar.gz a while ago and set my feeds to shr-core-staging/latest, then I've been doing opkg upgrade when there is an update. Ben ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
SHR-Core : Display issue?
I have been running the SHR 2.6.29 kernel for a while. Lately I tried to install the latest SHR-core kernel (2.6.39.4) WITHOUT installing the rootfs files. This procedure has worked fine for other kernel upgrades. In this latter case, while running 2.6.39, the display appears to have gotten into trouble in that touch screen locations appear to be wildly off. Applications no longer respond to button press activity as expected, and it appears that the coordinates of the press are off in the y direction by about 50% of the screen size. Anybody have an idea why this would be so? Is upgrading the rootfs a requirement for the new kernel? -- Iain B. Findleton 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 Group Buy - Status
What is the status of the GTA04 graphics chip implementation. I have done a lot of work on the GTA02 with my graphics based apps, and the main issue for me is the very poor graphics performance with the chip in use on that platform. I run the apps over the USB link to any PC using X, and the performance of the app is quite satisfactory. On the GTA02 screen itself, its very poor to the extent that its not useful. Is the new board using the same graphics interface, or can the new board do some reasonable level of smooth display and animation? ri...@happyleptic.org wrote: Please everyone be prudent before claiming that this could be ready for general users as a conventional phone. Last time we pretended the openmoko was acceptable as a end-user product some non technical people bought it, then had tons of troubles (buzz, bad sound quality), then were responded that this is only a hacker friendly prototype and so on, and as a result many people end up upset against the phone (that may be why the conversion rate gta02-gta04 is so unexpectably low). This is very unlikely one will experiment the same end-user experience with a gta04 than, say, with any nokia device. We can't put the same testing effort in the device. There will be buzz, there will be interferences, there will be heating chipsets :), etc. Please end user don't forget we are nothing but a bunch of optimistic enthousiasts. :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: what do I install now?
I have been using SHR or over a year with all that stuff. Aside from some implementation problems with the settings dialog, it works fine. Matthias Apitz wrote: Hello, I'm thinking in a fresh install of my FR GTA02 (at the moment Om2008.9); what I would need at least are: - GPS OpenstreetMap (tango) - TCP over USB and SSH into the FR - Terminal with Stardict - PIM, SMS, call - X11vnc server Any recommendation for a distribution I should install? Btw: I own another GTA02 with Android installed on. I feel that it reacts much faster on the screen while moving around through the applications or menus. How they do this, as well with X11? Thanks matthias -- Iain B. Findleton 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA-02 Replacement Battery
Is the BL-5C still the best replacement for the battery on the GTA-02? Does the BL-6C also work? Anything better or more current easily available? -- Iain B. Findleton 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Tangogps?
Anybody have info on what happened to tangogps or who is maintaining it these days? I am having rouble building it with the OM tool chain. -- Iain B. Findleton 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tangogps?
Tks. I am thinking to try my hand at souping up the performance a bit on my OM. If I have any success I will advise. Some aspects of the program design made tangogps a little inconvenient for me. Getting the libraries set up is my current activity so that I can get a build environment going. Joshua Judson Rosen wrote: Timo Juhani Lindfors timo.lindf...@iki.fi writes: Iain B. Findleton ifindle...@videotron.ca writes: Anybody have info on what happened to tangogps or who is maintaining it these days? I am having rouble building it with the OM tool chain. You might want to switch to foxtrotgps, which is fork of tangogps. It has a bug tracker, public Vcs, IRC channel Yes :) and is also in debian and ubuntu. and Gentoo, and SHR (and their upstream, OpenEmbedded, I think),and the FreeBSD Ports collection--and possibly elsewhere;those are just the systems shipping it that I know about(if anyone knows of someone else shipping it, let us know-- I'd like to maintain a list of places where pre-built [and pre-integrated] packages are available). I don't know what's happening with tango--Marcus does seem to have`fallen off the map', so to speak. Iain, if you have any suggestions, criticisms, patches, or othercontributions that you can offer, we'd love to hear it :)I try to keep the FoxtrotGPS bzr history as orderly as possible,so Marcus and anyone else should be able to pick any specificimprovements out from it for tangoGPS if they want. -- Don't be afraid to ask (λf.((λx.xx) (λr.f(rr. ___Openmoko community mailing listcommunity@lists.openmoko.orghttp://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Article: What happened to real open source phones?
The article pretty well sums up my experience with the GTA02, although I certainly have no regrets about buying one. All things considered, the idea of the machine was great, but it is really unfortunate that the performance, stability and general quality of the applications was somewhat below expectations. In particular, the glamo chip was a disaster for any advanced use of the screen resolution available, and the battery life issues made it not much use unless plugged into a power source. I hope that the GTA04, when it gets fully shaken down, will address at least those 2 issues. For the applications I would like to implement, more memory, performance that at least resembles a 500 Mhz laptop, although most phones now are dual core 1 Ghz chips, and excellent WIFI/GSM functionality would be critical. In terms of additional features, an IRDA facility, and geo-environment sensors (temp, pressure) and compass would be nice. Whatever the outcome of the GTA04 project, I support the effort and even if its another hobbyist toy, I will likely find it interesting. While I don't use the GTA02 as a regular phone, its in regular use for software development and for GPS applications. For some reason, I have yet to get stable and reliable information out of the accelerometers, but even they are useful for some purposes. Unfortunately, I feel the struggle for a Linux phone is pretty much submerged by the Android phenomenon, which is in my opinion, too bad. Phone hardware that ran linux out of the box would be wonderful. Niels Heyvaert wrote: Hi all, To those of you who didn't see summary flying by on Linuxtoday.com, there is recent article published about the Openmoko: http://itmanagement.earthweb.com/mowi/article.php/3931296/What-Happened-to-Real-Open-Source-Phones.htm I'm sure that after reading the article, you'll have the urge to react. At least I know I did ;-) Regards, Niels. -- Microsoft gives you windows, Linux gives you the whole house. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OM Mailing List
It appears to me that something has gone wrong with this list again. All I am getting is SPAM since a few days. -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Is this community dead?
Have not seen anything on the OM list for a while. Has the server gone? Is the community dead? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re : Re: accelerometer calibratio n
I did a lot of work with my FR on the accelerometers. The output from the chip is quite noisy. There is a script I wrote in TCL on the SourceForge web site under the fltkwish project page. It may give you some ideas about that can be done. In my experience, the results vary depending on which of the chips you use. Note that on the iPhone, some versions of which used the same chip, you only get access to the 100/sec samples, and from what I can tell, they are smoothed, although I have not seen the iPhone driver. The other issues is there was at one time some confusion about how the driver reported through the event mechanism. I forget the details now, but working code depended on how up to date your kernel was. If you have a kernel of recent vintage, should not be an issue. On 12/24/2010 06:17 PM, Timo Juhani Lindfors wrote: W. B. Kranendonk wankelwan...@yahoo.com writes: Is that useful? This is while the FR is lying flat on its back. I haven't compared it to output from the other FR yet. Raw binary output would be a lot easier to parse. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] Wifi stopped working
I have had experience with a lot of WiFi chips that is that they stop working after a couple of years. Check that the device is found on your machine. I use lsusb HansV wrote: I have the same problem, but upgrading didn't solve it. I tried everything I could think of, but no wifi so far. Any ideas? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangoGPS is a very successful user orienteted map and gps viewer
Tangogps is a very fine product. I do have a suggestion for a feature based on my own experience using it on the FR: Normally, I am interested in only a selection of possible map resolutions, such as 8, 10, 12, 14 and 16. For whatever reason, 10, 14 and 16 are most used by myself. however, clicking the + and - buttons advances or reverses by increments of 1, and I have found the scroll bar somewhat tricky to use on the FR for reasons unknown to me. It would be a nice feature to be able to have a programmable increment or decrement on the buttons, and perhaps a list of resolutions on the scroll bar. 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
TclFltk 1.0.195 Released for Openmoko Phones
A new release of this GUI development environment has been placed on the sourceforge site. This release cleans up a lot of minor bugs, runs somewhat faster, implements sound feedback for actions on the touch sensitive screen, and implements an additional rendering scheme that delivers a gtk like appearance to applications. I have also put a couple of demo applications, an image viewer and an accelerometer application, that have been updated to use sound feedback and some other functional improvements. See http://sourceforge.net/projects/fltkwish for the list of files and downloads. Send comments or complaints to me at ifindle...@no-spam-videotron.ca Iain B. Findleton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Set the time zone?
While I can set the time, I can't figure how to set the time zone on the FR under SHR-U. The tzselect utility does not work for me for some reason. Any suggestions? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM future
Does anybody out there know what the financial envelope for, say, a run of 100 Neos with the accumulated hardware improvements, g3, and double the memory would be? I am thinking a custom application here... I also suspect that a faster processor and support for higher capacity SD cards could be nice. Gerald A wrote: Heya, On Wed, Feb 24, 2010 at 2:58 AM, Radek Polak pson...@seznam.cz mailto:pson...@seznam.cz wrote: On Tuesday 23 February 2010 10:05:31 Mike Crash wrote: We can create a phone as a next step in the future, but not now. This is a very bad idea. I cant agree. I have N770 which is great PDA. If Neo was just PDA i would never bought it. I agree 100%. I have a few different Palms, which were much cheaper then the Neo. It was the vision that inspired me, and I'm sure will inspire others. Neo is very nice piece of hardware. But the hardware needs some fixes. I think gta-core project does exactly what is needed. If it had better case and design (or you could choose from alternative cases - e.g. white color for girls and women) and if it was cheap, it could be quite successful phone. While I agree that aesthetics are a factor, at this point the community should focus on making something sustainable. If the stuff under the hood is good, we'll attract case mods, and they can put cool cases around our good hardware. I also think gta-core is on the right track. It just needs to keep moving forward, and we'll eventually be successful. Thanks, Gerald. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM future
Mike Crash wrote: Actually, I don't know, why everybody needs a phone. The community should aim at simple PDA with GPS, WiFi, BT and camera. This all is without any license fees and can be made to work. The phone is nice, but do you really need such a device, where you can navigate in car/outdoors and in the same time take a call? I will prefer a simple small commercial phone with other such device. If I drive in car, I don't need WiFi, just a GSP, if I'm outdoors, I need GSP, if I'm in restaurant, I need WiFi, if I'm in bus stop, I need BT to connect to my phone with GPSR. I need only one such a function at a time, but what I need always - is a phone. I want to call when I'm in a car, in a bus stop, in a restaurant, in a wood and I don't want to break my navigation, mailing, browsing every time I get a phone. A phone has wifi and GPS as a nice option, but to have separate device with all that functionality is much more usable. I'm using Neo as PDA without sim card. I'm glad how it works - in last update to xorg 7.5 the glamo works very well and fast. EFL is very fast on that, GTK is worse. We should aim at software now. The next step should be to make nice PDA device with GPS, WiFi and BT and with OLED display (LCD is out). Camera would be nice, but not needed. Forget the phone, it will be always problem for open source. There is not big problem in designing such a device. And also, it will have longer life then a phone. But - will there be enough people, who will buy it? It needs to manufacture thousands of units - so thousands of buyers. Will be? If yes, we can design such a device and I will be first, who will start to draw a schematic. We can create a phone as a next step in the future, but not now. This is a very bad idea. Don't really agree at all with this position. It appears to me to be pretty clear that as hardware improves more and more things now done on laptops will be done on handheld devices with phone/wifi/bluetooth/ir capabilities. Right now you can comfortably run a small business on your Neo. In future, such a device will have large memory, fast processing, low power consumption, better graphics and more applications. If anything, more sensors (weather, compass, software radio, broadcast signals, ir) would expand the use of the single device. I observe my kids, who pretty much do everything I use a laptop or desktop for on their phones. Theonly complaint is the phone is slow compared to the other machines. This will certainly become an artifact over the next few years. The Neo to me is the rough equivalent of a 2000 vintage laptop with significant improvements in capabilities. While I don't know if the openmoko crowd can make any progress on a next generation device, someone will make such progress, and I believe that is where the future of personal use computing will go. Improvements in human interface design are needed to make these things easier to use, but think of MSDOS and what we consider normal today. The same leap of technology will occur on these phone like devices. I also want to have to carry less techno-junk, not more. Its true that single purpose devices are easier to produce, but a pocket full of them weighs you down, requires you to learn more procedures for different devices, and you run out of plugs in the house for chargers. Iain F. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM future
Mike Crash wrote: You talk something else than me. I didn't said anything about usage and development, only about the phone. Take a today phone and try to use it as GPS. In some hours you are out of battery, not very usable for a weekend in nature. You say, that Neo is like laptop in 2000? Nope, on laptop you can write documents, make programming etc. On neo you cannot. The small screen is very limited. Neo can be used as GPS, for access to internet (especially reading), book reading, as MP3 player etc. But not as mobile office. If you are clicker, yes, but for real work no. Also consider the open source community - it has not the power to take the lead. And no power to make really open phone. Not without any involvement of some big manufacturer. Well, I make extensive use of the Neo via usb networking and X forwarding. You can program on it. I have a pretty good editor(s) on the Neo, and I mostly write script applications, so pretty well all development can be done right on the phone. The display and keyboard are non-issues with X forwarding. Cross compilation is faster than the Neo compilations, but even that works fine. I have a word processor on the Neo which I also use via X forwarding. There are lots of other apps available as well. Yes the power is a pain, but its a development box. Next generations will not have the power problems. I am thinking of the future, not the past. As to the powerless open source community, I wonder what Linus or Stallman would say to that? Actually, I don't care. You can always crack an HTC or a Nokia or a iPhone or an Android phone and install Linux. Perhaps Openmoko won't get anywhere, but someone will. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
tangogps-0.99.3 ipk?
Is there a package file out there for this version? If so, where? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr] gwaterpas
Works on my SHR-U. I will put a copy on sourceforge.net/projects/fltkwish/openmoko. jeremy jozwik wrote: On Wed, Jan 6, 2010 at 4:15 PM, Davide Scaini dsca...@gmail.com wrote: Is there anyone of you having a working gwaterpas package? I'm trying to install it on latest shr-u but i get r...@om-gta02 ~/packs $ opkg install gwaterpas_0.3.1_armv4t.ipk *** glibc detected *** opkg: double free or corruption (out): 0x00cd0aa8 *** i poster on opkg a while ago that gwaterpas will not install on 20091205, seems no one is working on it at the moment, ___ 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-U] Wifi?
After many spent hours trying to get wifi and bluetooth up and running on SHR-U, I am about to conclude that these features just do not work. Wifi, after doing the bind and module reload things, works for about 10 pings, then appears to just stop, hanging the USB connection as well. Bluetooth, after trying to install bluez4 and encountering installation errors relating to lack of the bluetooth file in init.d, appears to do absolutely nothing. The mokonnect application is pretty useless to me for some reason, and the settings app appears to not set anything. Anybody actually have reliable bluetooth and/or wifi working on the SHR-U using the .29 kernel from last December? If so, what is the formula? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New release of TclFltk and a couple of simple apps...
I have posted a new release of the TclFltk application development environment to the sourceforge.net web site (http://www.sourceforge.net/projects/fltkwish/). The current version is TclFltk-1.0.155-x and is available for Windows, Linux (rpm and deb) and the Openmoko Neo FreeRunner (ipk) This release contains a number of bug fixes, an additional 3D plot widget and some documentation improvements. I have also posted to the site a couple of applications for use on the FR. gravity-1.0 - Displays the local gravity vector as computed from the accelerometer data photos-1.0 - An image display and animation application for the FR These latter applications are in the form of binaries. Source code is available on the SF site in the form of .tcl files in the Openmoko sub-directory. You will need to install the .ipk files as they contain the supporting images, icons, etc needed to get the applications up. The source files can be run directly after you install the .ipk files by making them executable. These applications are O/S independent scripts and have been built and tested on SHR-U and various OM200x.X releases. Note that you MUST have the tcl environment installed on your machine, and you may possibly have to provide a soft link for libtcl8.4.so if it is not already there. This soft link should work fine on all releases of tcl. eg: On the FR: opkg install tcl cd /usr/lib ln -sf libtcl8.4.19.so libtcl8.4.so or something similar, depending on your setup. Note also that I install applications to /usr/local/bin, etc. If you don't have a /usr/local path, you may need to make that as well: for d in bin lib ; do mkdir -p /usr/local/$d ; done For support, e-mail ifindleton-no-sp...@videotron.ca With this package on your various platforms, you can develop applications in a platform independent context, then just move them where you want them to run. Happy New Year! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all] reading accelerometers to a text file
Vikas Saurabh wrote: so im interested to know if there is a way to dump accelerometer information and gps information to text files. so that, hopefully, some day in the future i could see read them into a future application? or... if there are any developers just kinda hanging out drop me an email! http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval has some sample scripts (in different scripting languages) to dump data. If you want to see a somewhat evolved script to process accelerometer data, try gravity.tcl from: http://www.sourceforge.net/projects/fltkwish That script implements a few subtle aspects of the accelerometers, which are quite noisy in their output values. --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
[SHR-U] Screen Calibration
Anybody know how to verify screen calibration on SHR-U? I need to check that the X server is returning reasonably accurate pen touch locations. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] Screen Calibration
Yogiz wrote: Why not simply use the painting application that came with SHR and check if it paints the pixels you're touching? Yogiz On Tue, 29 Dec 2009 08:14:33 -0500 Iain B. Findleton ifindle...@videotron.ca wrote: Good plan. I am printing out the values sent by the X server and they appear to indicate that the location of a pen touch can vary by quite a few pixels. Just trying to track down why that would be and to make sure that an adjustment can be made. I don't think there is a problem necessarily with absolute screen locations, by within a window in an application I detect some issues. As a start, it would be nice to know the screen locations are good, and if not, how to get the X server to send good ones. Other armv4t machines I have used had a mechanism for screen calibration, and I wonder if the Neo under SHR has such an application and method. Anybody know how to verify screen calibration on SHR-U? I need to check that the X server is returning reasonably accurate pen touch locations. ___ 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: Quick e-mail poll: Still using your Freerunner?
Risto H. Kurppa wrote: Do you use FR as your daily/primary phone? No Do you use FR as your primary PDA? No What distribution you run most of the time? SHR-U If you don't use FR as your daily phone/PDA, what phone did you change over to, and why? Battery life, heat generation. Nokia basic model Thank you :) r -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: reliable wifi gui for SHR
My biggest problem with SHR is the settings dialog appears to be largely non-functional for most things I try to do. Info on how to control the state of the WiFi radio without using the settings application would be a big help to me. I am not much of a python person, but just being able to find the scripts for the settings modules would probably help. Any info? Christian Rüb wrote: On Wednesday, 23. December 2009 15:05:05 Michal Brzozowski wrote: Hi, What's the most reliable wifi utility nowadays on SHR? I tried mokonnect, but it can't see any networks, although 'iwlist scan' shows them properly. Is there any other tool that will let me: -select a hotspot -type the password -connect -disconnect and turn off wifi (in such a way that the battery isn't drained). Thanks! Michal Hi, wpa-gui - http://hostap.epitest.fi/wpa_supplicant/ I use wpa_supplicant roaming mode and deactivated eth0 for conman. WiFi config is saved in wpa_supplicant.conf and can be edited via wpa-gui from wpa_supplicant project. You can find my bitbake recipe for wpa-gui here [1] and a package here [2]. There are also my changed files in wpa-roaming.tar and and a README in [2]. I have been using this setup for months now with connections to WPA(2) PSK, WEP and unencrypted networks with dhcp and static IP. You then just need to switch WiFi on and off in SHR settings then udev and wpa_supplicant will do the rest :) Cheers, Christian [1] http://git.senfdax.de/?p=oe_recipes;a=tree;f=wpa-supplicant;h=bb7d494f16e6edff316775cef1d3b1a8ad3c6f90;hb=HEAD [2] http://openmoko.senfdax.de/shr-new-unstable/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-U Accelerometer data
Iain B. Findleton wrote: Michael 'Mickey' Lauer wrote: Am Donnerstag, den 17.12.2009, 11:59 -0500 schrieb Iain B. Findleton: Many tests appear to indicate that a complete report set read from /dev/input/event2 or event3 is a relative rarity. Looking at the code from the lis302dl driver in git.openmoko.org it appears to me that this should not be true, and if I recall correctly, proper output was couming out under OM2009.x at one point. Let me remind you that the driver has changed wrt. RELATIVE and ABSOLUTE. These days, upon opening the device, only the first report is a full report. Subsequent reports only contain changed axes. I got that about the ABSOLUTE. The changes only thing does not look to come from the driver code. Is that something associated with the linux input system interface? Anybody with any thoughts on this issue? According to what I read, /dev/input/eventx interface should reliably handle every event and make it available. The other issue is that the first report from the driver following an open on the device should be complete and contain the axis calibration values. This appears to be not true in that the first report I get is often incomplete in that not all axes are supplied. I can't confirm that. I'm running andy-tracking and when I call hexdump inputnode the first three entries are always axes 0, 1, 2. From what I saw of the driver code and the lis302dl spec sheet, an open on the device file should send the calibration data from the device. Can you confirm that I am reading the correct driver source? I have now confirmed that indeed the proper sequence of data is flowing from the accelerometer interface using /dev/input/event2 and event3. The first 64 bytes after an open contain the calibration values and the next 64 bytes contain the complete absolute readings. Subsequent events only contain changed values. Thanks for the responses. ___ 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-U Accelerometer data
Many tests appear to indicate that a complete report set read from /dev/input/event2 or event3 is a relative rarity. Looking at the code from the lis302dl driver in git.openmoko.org it appears to me that this should not be true, and if I recall correctly, proper output was couming out under OM2009.x at one point. Anybody with any thoughts on this issue? According to what I read, /dev/input/eventx interface should reliably handle every event and make it available. The other issue is that the first report from the driver following an open on the device should be complete and contain the axis calibration values. This appears to be not true in that the first report I get is often incomplete in that not all axes are supplied. I am presuming that the lis302dl driver in use on SHR-U is the same one as in the git repo. If not, where is the source being used by SHR? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-U Accelerometer data
Michael 'Mickey' Lauer wrote: Am Donnerstag, den 17.12.2009, 11:59 -0500 schrieb Iain B. Findleton: Many tests appear to indicate that a complete report set read from /dev/input/event2 or event3 is a relative rarity. Looking at the code from the lis302dl driver in git.openmoko.org it appears to me that this should not be true, and if I recall correctly, proper output was couming out under OM2009.x at one point. Let me remind you that the driver has changed wrt. RELATIVE and ABSOLUTE. These days, upon opening the device, only the first report is a full report. Subsequent reports only contain changed axes. I got that about the ABSOLUTE. The changes only thing does not look to come from the driver code. Is that something associated with the linux input system interface? Anybody with any thoughts on this issue? According to what I read, /dev/input/eventx interface should reliably handle every event and make it available. The other issue is that the first report from the driver following an open on the device should be complete and contain the axis calibration values. This appears to be not true in that the first report I get is often incomplete in that not all axes are supplied. I can't confirm that. I'm running andy-tracking and when I call hexdump inputnode the first three entries are always axes 0, 1, 2. From what I saw of the driver code and the lis302dl spec sheet, an open on the device file should send the calibration data from the device. Can you confirm that I am reading the correct driver source? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] wifi connection
Arigead wrote: Hello All, I was going to try and connect my FR to my laptop with an ad-hoc wifi connection but being as I've never even connected to infrastructure I decided that I'd start there. I followed the instructions in the wiki [1] but got some strange results: ifdown eth0 ifup eth0 ifdown: interface eth0 not configured WPA: Configuring Interface ioctl[SIOCSIWENCODEEXT]: Operation not supported ioctl[SIOCSIWENCODEEXT]: Operation not supported ioctl[SIOCSIWENCODEEXT]: Operation not supported ioctl[SIOCSIWENCODEEXT]: Operation not supported udhcpc (v1.13.2) started run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1 Sending discover... Sending discover... Sending select for 192.168.1.137... Sending select for 192.168.1.137... Lease of 192.168.1.137 obtained, lease time 3600 run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1 adding dns 192.168.1.254 r...@om-gta02 /media/card $ ifconfig eth0 Link encap:Ethernet HWaddr 00:12:CF:8F:37:23 inet6 addr: fe80::212:cfff:fe8f:3723/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:751 errors:0 dropped:0 overruns:0 frame:0 TX packets:381 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:353244 (344.9 KiB) TX bytes:9635 (9.4 KiB) It appears that I get offered an address by the DHCP server on the wifi but that it's not being used by eth0 for some reason. Is this a know issue. To be honest I've never tried to use the wifi part of the phone before and the wiki might be outdated, even for infrastructure mode? Cheers for any help that anybody has time to offer. I have similar problems getting wifi to work on SHR-U. In my case I get an address and configure the interface via dhcp, but can not establish any traffic to the interface. In one case I could ping a host but the transit time was enormous. The other thing I note from ifconfig is ridiculous RX and TX values, almost 1TB on an interface I never have used. Looks to me like a bug somewhere in the driver code. [1] http://wiki.openmoko.org/wiki/Wifi ___ 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
Ken Young wrote: DJDAS dj...@djdas.net wrote: [...] I am sure people trying the smoothness and responsiveness of Illume at 240x320 would never complain of a lower resolution! Furthermore I don't understand why a lower resolution (and in this I agree with you people are strange ;) ) would become in an unusable device while the iPhone at the same resolution is the best usable device ;) OK, I was going to try to control myself, but I just can't. I'm one of the people who always pops out of the woodwork to scream when someone suggests that switching to QVGA is a good idea. 1) The iPhone is not QVGA. It's HVGA. Try running a web browser on an iPhone with the bottom half of the display covered with black tape. 2) The Freerunner has one, and ONLY ONE, feature which is somewhat better than what is found on a typical smart phone. The VGA display. You are suggesting that feature should be downgraded so that it is effectively worse than what is found virtually every smart phone being currently manufactured. Every other feature of our phones is either no better than average (the GPS, the accelerometers), worse than average (USB 1.1, GPRS), or fucked up by firmware problems (WiFi). Yes, let's make sure the display is substandard too! Personally, I wish OM had stayed with the UI they had in 2007.1. That's right, 2007.1 - the first version, which had no kinetic scrolling. There was never any chance that OM would produce a phone with graphics as smooth and fancy as what a high-volume smart phone has. They did not have access to the hardware components. They did not have a legion of engineers to work on it.There is even less chance that gta02-core or gta03 will have state-of-the-art graphics capabilities. It will be nothing short of a miracle if a community hardware effort ever produces a usable phone, available to the full OM community, at all. IMO the OM software should try to differentiate our device from other smart phones, not produce a half-assed iPhone clone. Forget smooth graphics. Forget kinetic scrolling. Forget transparency. Show a simple, clean array of icons representing the applications which can be launched. Allow the user to set the brightness, screen blank time and suspend time. Stop there. Ken Young ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Neo graphics is certainly not as wonderful as you can get with iPhone like devices, but it is certainly far from a disaster. Only real problem I have found is the rate at which images can be displayed, which appears to be related more to SD card and memory access speed than anything else. Still, its usable for looping through pictures. The VGA resolution makes the device as far as I am concerned. Lots of space for a nice application UI, good scrolling, scalable fonts, nice color handling. I do think, however, that its never going to be more than an interesting toy and test platform for ideas for mobile applications. To me, the most interesting feature is it can be used as a portable office, as it can hold quite a bit of data, connects to anything, and when forwarded to a display with modern graphics capabilities, is quite fast and smooth on many applications. Instead of hauling about a portable, you can pop the Neo in your pocket, and not worry about it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Accelerometers
Al Johnson wrote: On Sunday 25 October 2009, Ivo van den Maagdenberg wrote: 2009/10/25 Frederik Sdun frederik.s...@googlemail.com * Iain B. Findleton ifindle...@videotron.ca [25.10.2009 13:19]: Where is the device control for the accelerometers on SHR? Was /sys/bus/platform/devices/ls302dl.1/2 or some such on the OM distros. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community here's an overview of the sysfs paths: http://wiki.openmoko.org/wiki/GTA02_sysfs#Accelerometers No luck. The paths specified on the page you refer to do not exits on the SHR release. r...@om-gta02 ~ $ ls -a /sys/devices/platform/ .physmap-flash.0 s3c2440-sdi s3c-ohci .. powers3c2440-uart.0 soc-audio gta02-led.0 s3c2410-iis s3c2440-uart.1 uevent gta02-pm-wlan.0 s3c2410-wdt s3c2440-uart.2 neo1973-memconfig.0 s3c2440-i2c s3c2440-usbgadget neo1973-version.0s3c2440-nand s3c24xx_pwm.0 http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval#The_.2Fsys_inter facedoes neither point to the right direction in the SHR case. Any other suggestions how to manipulate the accelerometers? This is a case of a wiki page in need of an update because it only makes sense if you already know what it means ;-) Note the first line on the page: NOTE: These only apply to Linux kernel 2.6.24, 2.6.28 has different paths (see below) The #Accelerometers link you were given points to the paths for 2.6.24 which have explanations, but aren't used by any current distro. Below that is a section that says what each path from 2.6.24 changed to in 2.6.28 and later, and are used by all current distros. Scroll to the very end of the page and you'll find the answer you were looking for. Well, unfortunately, the information found where you indicate it to be does not in fact point to the required lis302dl control entries. Is it possible that the appropriate module needs to be loaded? Anyboy out there do any work on accelerometers using 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] Accelerometers
Al Johnson wrote: On Sunday 25 October 2009, Ivo van den Maagdenberg wrote: 2009/10/25 Frederik Sdun frederik.s...@googlemail.com * Iain B. Findleton ifindle...@videotron.ca [25.10.2009 13:19]: Where is the device control for the accelerometers on SHR? Was /sys/bus/platform/devices/ls302dl.1/2 or some such on the OM distros. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community here's an overview of the sysfs paths: http://wiki.openmoko.org/wiki/GTA02_sysfs#Accelerometers No luck. The paths specified on the page you refer to do not exits on the SHR release. r...@om-gta02 ~ $ ls -a /sys/devices/platform/ .physmap-flash.0 s3c2440-sdi s3c-ohci .. powers3c2440-uart.0 soc-audio gta02-led.0 s3c2410-iis s3c2440-uart.1 uevent gta02-pm-wlan.0 s3c2410-wdt s3c2440-uart.2 neo1973-memconfig.0 s3c2440-i2c s3c2440-usbgadget neo1973-version.0s3c2440-nand s3c24xx_pwm.0 http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval#The_.2Fsys_inter facedoes neither point to the right direction in the SHR case. Any other suggestions how to manipulate the accelerometers? This is a case of a wiki page in need of an update because it only makes sense if you already know what it means ;-) Note the first line on the page: NOTE: These only apply to Linux kernel 2.6.24, 2.6.28 has different paths (see below) The #Accelerometers link you were given points to the paths for 2.6.24 which have explanations, but aren't used by any current distro. Below that is a section that says what each path from 2.6.24 changed to in 2.6.28 and later, and are used by all current distros. Scroll to the very end of the page and you'll find the answer you were looking for. Okay, in what I can only assume is an effort to make finding the lis302dl (Accelerometer) control interface easier, the path on the SHR distro I have installed is: /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0 /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.1 where the .0 and .1 directories refer to the respective accelerometer devices. An alternative path is: /sys/bus/spi/drivers/lis302dl/spi3.0 /sys/bus/spi/drivers/lis302dl/spi3.1 I don't know who has permission to modify the wiki page, but someone who can do so may wish to add this information on the #Accelerometers page. Here is the output of `cat /etc/shr-version` on my machine: Tag Name: mv-packages-to-recipes-pre VERSION: 02fe96061411de095776edd314d9ae551e1b2f22 Branch: shr/import Build Host: opmbuild Time Stamp: Sun, 06 Sep 2009 16:34:21 +0200 ___ 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] Accelerometers
Where is the device control for the accelerometers on SHR? Was /sys/bus/platform/devices/ls302dl.1/2 or some such on the OM distros. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[Android] SSH Access...
Just installed Android, SSH does not come up by default. What is the secret sauce? Also, need a magnifying glass to read the screen. Is there a solution for that as well? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OT: Where can I meet a female companion with similar interests and personality /in person/?
This site is completely free, worldwide, but mainly english speaking. Lots of fish of all ages and locations... http://www.plentyoffish.com/ Jeff Sadowski wrote: Too long a read. If your looking for a mate may I suggest okcupid.com I had quite a few dates off the site and it was free. I never found the one off that site but I could get maybe a date a week off the site and it was a lot of fun. I found my final date through a close personal friend just a months ago and this is the ideal way to meet someone. Learning to dance goes a long ways with most ladies and is a lot of fun. It could also be a way to meet someone I had been dancing for 3 years and gone on a couple dates that I met while dancing. The magic words I found to get a date where somewhere along the lines Dinner on me and I invited them on a dinner date stating I have more fun meeting them in person and that body language speaks a lot. :-) Good luck On Thu, Sep 10, 2009 at 2:12 PM, Brolin Empey bro...@brolin.be wrote: Hello list, Like most of the members of this list (AFAICT from the first names I recognise as sex/gender-specific), I am male. I am 22 and still live with my parents. I have never lived away from my parents. I am planning to hire a support worker to help me live away from my parents (I have another meeting later today) because I continue to indefinitely defer trying to live away from my parents. I named my form of procrastination “priority inversion” because what is, in practical terms, my lowest priority, becomes my highest priority. For example, I choose to spend my free time playing with my computers, including my FreeRunner, instead of learning about human biology and/or nutrition, which will affect me every day of my life, and at least trying to live away from my parents. When I say I play with my computers, I do not mean gaming: I almost never play games anymore. Even when I decide I want to play a game again, I spend all of my time reading about games, viewing screenshots and videos, and trying to decide which of the endless games I should play (or rather, obtain if I do not already have a copy and make work on my PC) instead of actually playing a game. I feel like I am always overwhelmed and/or overloaded with information and stimulation in the Too Much Information Age. I always feel like the NET Effect is that there is Never Enough Time because time flies faster than ever because I am always overthinking, overwhelmed with overchoice, etc. I recognise my mind is a word and pattern recognition engine, which is constantly adding new stimulations/experiences to its database. I have Asperger’s Syndrome, but can function much better, at least in terms of interacting with people in person, than when I was in high school, for example. I used to often feel like I had social anxiety disorder because I would get so anxious and/or worried even when calling someone on the phone (on my parents’s landline because I did not have a cell phone until 2008) that I could not speak clearly enough for the person on the other end to understand me, so I would always have to repeat myself at least once for every turn of the conversation. I am a purist and have been called the most pedantic person in the world by Jamie Zawinski, of Lucid Emacs/XEmacs and Netscape/Mozilla fame. :) Imprecise usage and redundancy bothers me even if know what is meant from the context. For example, I am bothered by people mentioning a “standard” transmission in a vehicle (it is a manual transmission. Standard depends on the vehicle. Automatic is standard for some vehicles.), calling an LCD monitor (a flat panel) a “flat screen” (high-end CRTs have flat glass too!), common redundancies, such as PIN number, ATM machine, LCD display, people who assume all cars use crappy gasoline engines and use fuel-specific terms, such as gas station (it is a service station), gas tank (it is a fuel tank), gas pedal (it is an accellerator), gas pump (I have used a diesel pump at Shell that told me to “select octane” instead of “select ctane” (sp?) or “select fuel grade”. My car has a diesel, not gasoline, engine. I have been highly influenced by my father, Brian Empey. Brian is a Professional Engineer (Electrical Engineering). He founded Technical Solutions Inc. (Techsol) in 1996 with his second wife (my step-mom), Karen Empey (nee Schellenberg). Techsol is an embedded computer hardware company specialising in Linux on ARM architecture. I am very fortunate to be able to work at Techsol. I am a Linux + Windows System Administrator/Web master/IT person/general computer person. I think my responsibiles are more important than my title(s). I know I am very dependent on my parents, but at least I own my own car (which I bought from my dad), have a Class 7 driver’s licence (the Novice stage of the Graduated Licensing Program in British Columbia, Canada. I live in the Lower Mainland of
Re: vi vs. nano in shr user manual (was Re: SHR first experiences user manual)
The FLTK distribution has an excellent editor that is largely based on nedit code which I use on my FR. Forward your X display to another host and fire it up. Does not have all the features of nedit, but works just fine when compiled out of the box. ... Wait a sec - did I understand correctly that you want to tell people to use vi in the user manual? So I take you expect that people going through the manual are skilled enough to use vi and if not, they'll be smart enough to use nano instead? Maybe the manual should explain how to use vi: how to save, exit etc.. I have no idea how to use it. Maybe a link to vi howto? I have no problems accepting that some prefer more vi than nano but I have hard time accepting it being suggested in a manual where you can't be sure people know how to use it as it isn't as self-explanatory as nano, no matter how much Ctrl you have to use. r I would agree with Risto here - vi is great for experienced users, but for the inexperienced or pure user - it can be a nightmare experience that provides detractors with plenty of ammunition that linux is hard to use, for geeks only and not for serious use ... Idea, have guides for both (if not nano then something similarly easy to use - a dos edit clone of some kind for compatibility, nedit?) - linked from the manual. There are plenty of vi guides out there, and probably for most other apps as well. The idea should be to guide and inform, catering for both experienced and inexperienced (to both the FR and linux) users. BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why one cannot recommend the freerunner as a daily phone (was Re: Is a FreeRunner sufficient for me?)
Most of Joerg's comments reflect the experience I have had. On the other hand, its a GREAT portable office. You can run just about any Linux application on it and with an 8Gbyte microSD card, carry around a lot of stuff easily in your pocket. Just plug it into any old PC via WIFI, Bluetooth or USB (Preferred) and you are away. Simply great for a consulting lifestyle. It also receives and sends phone calls, although it generates too much heat to carry about in your pocket for that application. Joerg Lippmann wrote: On Thu, Jun 18, 2009 at 10:49 AM, Joerg Lippmannjl_li...@donalbain.de wrote: Then the Freerunner is not for you. It may sound harsh, but it's definitely *not* suitable for daily use. Period. Brolin, I must respectfully disagree with Joerg's advice to you. There are flaws, including the ones Joerg points out, but they do not necessarily make the Freeruner unsuitable as a daily phone. I think it depends on the person. I use mine daily as my only phone and it works well for me. From your description of yourself, I suspect you would be happy with a Freerunner as well, as long as you don't expect it to do everything you want out of the box. OK, maybe I should explain. My mail should not be taken as FUD. I have a freerunner since it came out a year ago and - being a linux user since 1994 - I was prepared to get something rough and unfinished. But I hoped that it would one day be sufficient to replace first my phone, then my Palm Tungsten C and maybe my Etrex-GPS. It does neither in a satisfactory way. I used it for about year now, installed this and that distro and during that time I defended all the shortcomings as being a work-in-progress and a community effort. But all in all I cannot recommend it to anyone as a daily phone. Here's why: - The device wakes up too slowly, I lost some calls. - The vibrator is too weak, I missed more calls. - The volume is way to low, You can really only use it indoors. - The Display is too dark for sunny days, even in the shade. - I lost many SMS. I eventually receiced most of them after restarting the device - The battery lasts only a few hours, again, I lost many calls (this depends on the distro. But even with a »good« one, I had cases in which the device did not suspend due to something crashing) - Sometimes I cannot access the phonebook (Android, SHR) - Wifi does not work reliably and it takes a long time to connect. - The device/software is terribly slow. How fast was even the oldest palm in comparison! - the on-screen keyboards are all terrible for finger-typing. I liked the one from QTe, but you have to install german wordlists by hand. Also it was impractical to switch upper/lowercase. Best solution would be to use landscape automatically. - Even simple tasks like inserting the number of the caller into the addressbook is sometimes impossible or very complicated. (- Many people I called complained about terrible buzz, but I hope to get the fix soon) - The alarm clock does not work reliably. - When the battery is completely empty, it takes ages to reload the phone and you're not able to turn it on even when plugged in. - You cannot sync dates or even contacts, PIM-functions are virtually non- existent. (And I did not mention nice things like video-playback, a good MP3-Player, voice-notes, a nice email-Interface or a feed-aggregator...) Granted, most things depend on the distro you're using. But neither is really good: OM: 2007: very stripped down, although I liked the simple interface. QTe: Overall quite OK, but no Sync, no working wifi, no usable browser, no GPRS, no usable GPS-Application SHR: good battery life when not crashing. some bad design decisions (animations are useless on this phone), slow (especially the setup-menus and finger-scrolling), ugly phone-function, contacts crash very often, tangogps is working, many SMS and calls lost. Keyboard either english-only or only usable with a pen. Android: Best of the bunch so far. But volume too low, missing keyboard in stable versions (cupcake one looks better, but is not stable enough at the moment) I'm trying to honour the work of the many developers, but in my book, this is still not a working everyday phone. Let alone a smartphone. Today, I slipped my SIM-card back into my old Siemens M55. What an experience: I got every call immediatly! I could hear what the other side was talking! I could send an SMS in a few seconds without problems and received an answer! I could also insert the number from a caller directly into my addressbook. You should try it once. My freerunner will stay in my drawer. Maybe when Android works perfectly, I will give it another try. Am Samstag 20 Juni 2009 schrieb Ben Wong: The sound quality is terrible according to Joerg, but that has not It's just way too low. I can only unterstand the other
Re: git checkout
The error message is fatal: not a git repository Same for git branch -a. Al this follows what looked like a successful git clone command Thomas White wrote: Iain B. Findleton ifindle...@videotron.ca wrote: I confess to not being too familiar with git, however, the web site says to use the command: git checkout origin/andy-tracking after cloning the kernel project. This does not work for me. I suspect that origin must be something else. Any suggestions? Can you paste an error message? Also, the output of the following command should help: $ git branch -a Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: git checkout
Ah yes, a little knowledge, experience and skills and abilities are a great help. Thanks. That was the problem... Iain F. Thomas White wrote: On Wed, 27 May 2009 10:36:34 -0400 Iain B. Findleton ifindle...@videotron.ca wrote: The error message is fatal: not a git repository Same for git branch -a. Al this follows what looked like a successful git clone command A quick muppet check here: you *did* change directory into the newly cloned folder..? If you're cloning the kernel tree, it'll be called kernel, but you can tell it a different name if you want. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
git checkout
I confess to not being too familiar with git, however, the web site says to use the command: git checkout origin/andy-tracking after cloning the kernel project. This does not work for me. I suspect that origin must be something else. Any suggestions? -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Accelerometer Accuracy
After many experiments with the accelerometers, I notice that there is, on my FR, a considerable difference between the readings from the 2 devices. Aside from the noise issue, the difference between the measured gravity between the 2 devices is of the order of 1m/s**2, device 0 being lower than device 1. Is there any way of calibrating the output from these devices? Simple noise suppression using thresholds appears to aggravate the problem. In my tests, the error computing the angles between the local gravity vector and the device axes when the FR is at rest on a flat surface appears to be in the range -1.5 to +1.5 degrees, something that would appear to make these devices more or less useless for anything beyond very crude estimates of local acceleration or gross changes of position. -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Performance
That should be fine. Of course, if the phone has no future Thomas White wrote: On Fri, 03 Apr 2009 21:14:16 +0100 Ian Stirling openm...@mauve.plus.com wrote: What is the bandwidth for memory moves? About 6-8 or so - with 100% CPU utilisation Or one pixel per 2D engine clock cycle for moves inside Glamo's memory using its blitter (i.e. VRAM-VRAM). I think that in the Freerunner the relevant clock runs at 50MHz, but I haven't managed to properly decipher what's going on in that regard. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometers in recent kernels
I have the latest kernel I have found on the .../unstable/ download, dated Apr 06, 2009, but I do not see any EV_ABS (type 3) events listed when I access the /dev/input/event[2,3] files. Is there another kernel out there? Which one matches the andy-tracking modules? Michael Tansella wrote: On Tuesday 07 April 2009 00:45:05 Cedric Cellier wrote: I tried to edit the wiki page about the accelerometer in order to document this change : http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval Please someone review it ! Thanks ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometers in recent kernels
Are you building it yourself or is there a uImage and modules file pre-compiled? ri...@happyleptic.org wrote: -[ Tue, Apr 07, 2009 at 12:09:56PM -0400, Iain B. Findleton ] I have the latest kernel I have found on the .../unstable/ download, dated Apr 06, 2009, but I do not see any EV_ABS (type 3) events listed when I access the /dev/input/event[2,3] files. Is there another kernel out there? Which one matches the andy-tracking modules? I used a 2.6.29 from andy-tracking branch of the kernel repository at git.openmoko.org. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Performance
In my case, one of the motivations for looking into the FR was the VGA graphics capability. Any old phone would do for QVGA level performance. As for the ferrari analogy, as far as graphics performance goes, it looks like the Apple produces and their competitors make the FR look like the poor cousin, which to me means that it does not have far to go as a phone of the future. Its just an interesting little gadget for hobbyists. Makes me wonder what the designers were thinking. For non-graphics intensive applications, however, the FR is quite adequate in VGA mode. ri...@happyleptic.org wrote: -[ Fri, Apr 03, 2009 at 09:45:37AM +0200, Miguel Ángel Calderón ] What really surprises me is the fact that if this is so clear, why is Comunity not working on qvga graphics yet? (...) I'd prefer to drive the funnier modest car than to have the ferrary parked outside... I though linux and free software people were mostly this way. I was feeling exactly the same, and will try qvga asap. ___ 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: Graphics Performance
In my case, the apps I use need space on the screen for buttons, etc that control the things being done. My typical layout is to use 460 x 570 for the actual application display, the rest for decorations and controls. Under these conditions, 512 x 512 would be fine, even if I had to cut the display by a few lines. Even the 2D accelerations items would probably make things much better as I do my own conversion from 3D to 2D. Are there any instructions as to how to get the xorg driver running? I currently use whatever came with the phone run time images Thomas White wrote: On Thu, 02 Apr 2009 11:17:42 -0400 Iain B. FIndleton ifindle...@videotron.ca wrote: A significant issue for me is the performance of the graphics display on the FR. I recall some discussions a while back about making use of the XGlamo acceleration features. Has any progress been made here? It appears to me that the graphics performance on the FR is poor compared to, for instance, the iPhone or iTouch, both of which have slower CPUs. When applications running on the FR have their X output routed to a machine with accelerated graphics, it is apparent that the FR processor can deliver the X events fast enough, but the FR graphics chip interface can't keep up. [I wrote this before the other replies came through, so it re-covers a bit of ground.] We do have some acceleration already - both XGlamo (the Kdrive X server) and xf86-video-glamo (the Glamo driver for Xorg) make use of Glamo's 2D engine to accelerate tasks such as flood-filling large areas and moving blocks of data around the screen or onto the screen from offscreen. However, I do agree that we can do a lot more. So far, we've concentrated on trying to implement conventional acceleration protocols while being limited by what Glamo can't do. Instead, I think we should look at what the little chip CAN do, and really make it work, HARD, for us. Particularly its 3D engine. With that, we could do things like (dare I say it, iPhone-style) flying launcher icons, or alpha-blended overlays, or other things I can't even imagine right now... There are many limitations of the chip, but I don't see them as a reason to give up on this kind of thing. For example, it's often mentioned that the 3D engine won't render to a buffer larger than 511x511 pixels. That would seem to rule out such graphical fanciness at the native resolution of 480x640, but how about we just cover a 480x511 region of the screen with accelerated graphics and make the remaining area into some kind of tool or status bar? Maximum texture size of 256x256? Then design the UI so that the accelerated parts of the UI split into blocks of that size or less. And so on. I see more potential in working 3D acceleration than just Quake, and I'm not in the least bit put off by the knowledge that the chip is a one-off... Tom ___ 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: Graphics Performance
I installed whatever editor I use on the phone, then use a forwarded X connection to do editing stuff using the desktop or portable. Fat thumb typing on a small screen does not make a lot of sense to me, but then, I don't text people much either. joa...@verona.se wrote: ri...@happyleptic.org writes: I feel the ferrari analogy is broken. it depends on what you would like to do with the device. Moving bling bling is not efficient, Ok. Things that demand high resolution, like ebooks and emacs work fine. I spend some time in the terminal myself, generally to fix something in a config file or to mount manually something on USB or fix the network configuration. If the device were working flawlessly and with a good GUI for all apps, I wouldn't mind not hurting my eyes on the small chars :-) For working seriously in a terminal I need a keyboard and a large screen anyway (or a magnifying glass maybe ?). I don't know how you manage emacs with the various CTRL+ALT+META-x on the virtual keyboard but I sure can not stand it for more than a few minutes. I made some elisp for choosing symbols, and patched in some toolbar buttons in packages I use. Typing on a virtual keyboard is, admittedly, no fun though. As for reading in general (ebooks or web browser), I admin this is certainly better in a bigger resolution. The same goes for viewing maps. But all in all, a small gadget with small screen and no keyboard will never replace a desktop computer. So personnaly I am looking for other use cases for my FR, and a smaller resolution and better responsiveness is the direction I want to go. -- Joakim Verona ___ 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: Graphics Performance
It appears to me that the implementation on the FR is not capable of moving an updated frame buffer in memory to the chip's video buffer, presuming they are different, without draping. Since the controller appears to be able to rescan its own video buffer without flicker, I wonder what the issue is in moving the frame buffer data? At the speeds available on the FR, moving 640 x 480 x 2 = 614,400 bytes from memory to a video buffer at 30 Hz needs about 18 MB/sec. What is the bandwidth for memory moves? Carsten Haitzler (The Rasterman) wrote: On Fri, 3 Apr 2009 14:25:48 +0100 Thomas White t...@bitwiz.org.uk said: On Sat, 4 Apr 2009 00:01:16 +1100 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: beware of jumping all over 3d as the solution. i have recently been working on a gles2 engine for evas. i have run it on 2 platforms (s3c6410 and omap3530). both with hardware opengles2 (and capable of high res etc.) and software beats gles2. yes - evas software rendering is faster. oddly enough the movial guys and trolltech (qt) guys see the exact same performance problems. gl is slower (i know that i and the trolls have seen about a 1/4 speed of gl vs software). I'm really interested as to why this might be the case. Do you have any ideas? Something like the increased overhead of the extra API and latency associated with swapping contexts? not 100% sure. at first i thoguht maybe lots of context changes. i cleaned that up and had them changed as little as possible - only got about 10% more. what i'd expected. i suspect the gl scissor ops simply dont optimally clip operations early in the rendering (at the geometry stage) like the do in software (evas's clips clip really early). but i have yet to prove that. software is capable of being smarter. gles is stuck in the Render the whole window or nothing phase. anything else doesnt work or is not supported or is a software path anyway. so you have to re-render the whole backbuffer just to update 1 button that changed. of course as long as both are rendering the whole buffer - they are on even ground, but software can take more optimal paths and only re-render sub-sections. i also know the gles drivers perform excess memcpy's of data (with the cpu) to get it to the screen - software engine is able to avoid at least 1 copy there (when in 32bbpp). texture uploads are a big drain on performance - so if you have dynamic data (video or generated pixels) software beats gl by a wide margin as it can do this zero copy. gl requires a texture upload. gles2 also requires everything be a shader - there is no more fixed pipeline. you have lots of problems here when it comes to quality of the shader compiler - and even if it is implemented at all. it's a black box. but as of gles2 you have no choice - you MUST use shaders. also i suspect there is a bit of nastiness in always having to put all draw ops through the gl transform matrix - when really all the code is doing is trying to pass pixel coordinates. another problem is RGBA va ARGB. ARGB is by far and wide the most common 2d pixel format. but the gles committe in their infinite wisdom decided to only support RGBA - thus you are forced to either swizzle from ARGB to RGBA at tex upload time... overhead, or do it at draw time in the shader - possibly impacting performance a bit. but these are just my set of things i am sure have some impact. but i really have not found a good reason for the big difference. gl hardware should SPANK software's butt. by a country mile. but it doesn't. :( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Graphics Performance
A significant issue for me is the performance of the graphics display on the FR. I recall some discussions a while back about making use of the XGlamo acceleration features. Has any progress been made here? It appears to me that the graphics performance on the FR is poor compared to, for instance, the iPhone or iTouch, both of which have slower CPUs. When applications running on the FR have their X output routed to a machine with accelerated graphics, it is apparent that the FR processor can deliver the X events fast enough, but the FR graphics chip interface can't keep up. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Performance
Well, that clears things up a bit. So, there is no way to get rid of the draping one sees when the display is refreshed? My stuff uses double buffering, but your comments appear to indicate that that is a waste of time. Carsten Haitzler (The Rasterman) wrote: On Thu, 2 Apr 2009 18:23:38 +0200 Tobias Diedrich ranma+openm...@tdiedrich.de said: Iain B. FIndleton wrote: A significant issue for me is the performance of the graphics display on the FR. I recall some discussions a while back about making use of the XGlamo acceleration features. Has any progress been made here? It appears to me that the graphics performance on the FR is poor compared to, for instance, the iPhone or iTouch, both of which have slower CPUs. When applications running on the FR have their X output routed to a machine with accelerated graphics, it is apparent that the FR processor can deliver the X events fast enough, but the FR graphics chip interface can't keep up. Isn't the glamo supposed to have one (or more?) OpenRISC cores? It would be nice to have a documented way to upload code to the core, that way it might be possible to implement the Bling on the graphics chip directly... I mean, since OpenRISC has a documented instruction set (unless they've augmented it) set I'd figure the only thing missing would be where to put the code and how to start it... this information is not even in the docs openmoko had on the glamo. there is no known way to play with this core. my understanding is that it is actually a relatively slow core (50mhz) and is only really for higher level management of sub-systems on the glamo. of course here is your big problem.. you can do all this for the glamo and it will never work anywhere else. it is a 1 off for 1 chip that will never see the light of day in another product. So, just like with the mpeg4 decoding unit, wouldn't it be possible for someone with access to the NDA documentation to write an example program that just shows how to run a simple program (e.g. bitblt) on the OpenRISC processor? no. as those docs are not even in the nda docs. other than that.. bitblit is documented and not related to the risc core. there is a blitter there. xglamo uses even. xglamo *IS ACCELERATED* it's about as accelerated as most x drivers (fills, blits). it has no accel for xrender (xglamo doesnt implement enough of xrender's operations to make it worth it - again see my previous mail. you'll be writing fallback software code and end up no faster than where you started). if you want decent speed - drop to qvga. thats what glamo was really designed to handle. even the 2442 (cpu) is pushing it to deal with vga nicely. it can. but that generation of cpu is more geared to qvga resolutions. the gta02 is a ferrari body (vga screen) with a lawnmower engine under it (2442 +glamo). you need to drive it like a lawnmower - and then only expect it to be as good as a lownmower. it looks nice parked on the street (still photos) but if it moves... it will show its true nature. remove the heavy ferrari body and drive it like a go-kart and you'll have more fun. -- Tobias PGP: http://9ac7e0bc.uguu.de ___ 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: Accelerometer Data
The location of the control interfaces for the accelerometers in the
2.6.28 build has moved to :
/sys/bus/platform/devices/lis302dl.x/...
After reading the code for the driver version on the git tree, I
discovered that the settings for sample_rate and full_scale are limited
to 2 values only, and the units of the threshold value are determined by
the full_scale settings.
As to the time intervals between reports, to my view, they are still
pretty erratic, although at least the time codes on the reports are at
least always increasing in time.
The code read so far appears to indicate that the overrun values are not
reported. Is there an easy way to get the exact, current source for the
driver that is used in the 2.6.28 release? Even although I have been
reading diff files since the 1970s they still cause my brain to dissolve
an leak out of my ears.
What I am wondering is whether the devices themselves report according
to spec and setup? It pretty hard to make use of the data for much if
you can't determine the time interval that the acceleration value refers to.
As to keeping up with the device, I can envisage code that would be too
slow as a possibility, but a 500 MHz processor should easily manage a 10
ms device, one would think. I have not personally seen a timing issue
for a device on a modern CPU since the 1980s.
Neil Brown wrote:
On Monday March 23, ifindle...@videotron.ca wrote:
Okay, it looks like the 2.6.28 kernel and modules are an improvement for
the accelerometer data, but the report times, while not negative any
more, appear somewhat erratic. The type codes appear to be unchanged in
this build, with the driver reporting EV_REL and EV_SYN.
The time codes should be very reliable, and should be spaced at 10ms
intervals as the device interrupts at 100Hz (by default).
Each open file on the /dev/input/eventXX device has an internal buffer
of 64 entries. If your application is not able to read fast enough to
keep that buffer from over flowing, then you will occasionally loose
chunks of 64 entries (and so see gaps for 640 ms).
However this is not what I see. If I measure the time between EV_SYN
reports for 1000 such reports, I get a histogram like
freq ms
805 10
136 20
34 30
11 40
1 41
4 51
5 61
1 71
Which isn't what I expected. No over-runs are being reported, and
there are no 640ms gaps, so the internal buffer isn't wrapping.
(goes and reads code again...)
Ah. If none of X, Y, or Z change, then EV_SYN won't be reported
either. So this presumably shows that there are times when the
accelerometers think the device is completely stable - nothing
changing.
If the device were reporting EV_REL events, then you could only lose
EV_SYN events if all three axes reported 0, which means perfect
free-fall. That seem unlikely...
I have a patch which I'm in the middle of writing which makes the
'sample_rate' sysfs setting more useful. Instead of just '100' or
'400' you can have any other (smaller) value, and it samples the
accelerometers at that rates. So e.g. '10' with give 10 samples per
second, and '0.1' will give one every 10 seconds. When I get up to
testing that I'll make sure that it delivers properly times events.
You do similar histogram-generation tests yourself by:
wget http://beagleboard.googlecode.com/files/evtest.c
cc -o evtest evtest.c
./evtest /dev/input/event2 | grep Sync | awk '{print int(($3 - prev)*1000)
; prev = $3}' | sed 1000q | sort | uniq -c
I would be interested to see what you get using a kernel that
reports EV_REL events.
'evtest' is a very useful program for experimenting with the various
input devices.
NeilBrown
___
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: Accelerometer Data
Okay, it looks like the 2.6.28 kernel and modules are an improvement for the accelerometer data, but the report times, while not negative any more, appear somewhat erratic. The type codes appear to be unchanged in this build, with the driver reporting EV_REL and EV_SYN. Thanks for the various suggestions. I will report whatever else I find that appears interesting. Iain F. Michael Tansella wrote: In the latest andy-tracking it reports the more correct 'ABS' events. So now it does report zeros. However it doesn't report an axis if there has been no change. Is it correct that there are now two changes for developers. The first one is that the EVENT type has changed from EV_REL (0x02) to EV_ABS (0x03). This would mean in the python sample code of the wiki the change would be: from: if type == 2: if code == 0: x = value if code == 1: y = value if code == 2: z = value to: if type == 3: if code == 0: x = value if code == 1: y = value if code == 2: z = value The second change is that if no new (y,x, or z) value is reported the old one should be taken. If you want to simply get the current values there is an ioctl : EVIOCGABS I think. I think that is what most developers want. It would be great if someone could show a small sample code how this works. Greets Michael ___ 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: Accelerometer Data
Charles-Henri Gros wrote: A known issue in 2008.12. http://docs.openmoko.org/trac/ticket//2145 Workaround: echo 10 /sys/devices/platform/lis302dl.1/threshold ls /sys/devices/platform: drwxr-xr-x 21 root root0 Mar 23 12:40 . drwxr-xr-x4 root root0 Mar 23 12:39 .. drwxr-xr-x3 root root0 Mar 23 12:39 gta02-led.0 drwxr-xr-x3 root root0 Mar 23 12:39 gta02-pm-wlan.0 drwxr-xr-x3 root root0 Mar 23 12:39 neo1973-memconfig.0 drwxr-xr-x3 root root0 Mar 23 12:39 neo1973-version.0 drwxr-xr-x3 root root0 Mar 23 12:39 physmap-flash.0 drwxr-xr-x2 root root0 Mar 23 13:58 power drwxr-xr-x3 root root0 Mar 23 12:39 s3c2410-iis drwxr-xr-x4 root root0 Mar 23 12:40 s3c2410-ohci drwxr-xr-x3 root root0 Mar 23 12:39 s3c2410-wdt drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-i2c drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-nand drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-sdi drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-uart.0 drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-uart.1 drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-uart.2 drwxr-xr-x4 root root0 Mar 23 12:40 s3c2440-usbgadget drwxr-xr-x3 root root0 Mar 23 12:39 s3c24xx_pwm.0 drwxr-xr-x6 root root0 Mar 23 12:39 sc32440_fiq.0 drwxr-xr-x3 root root0 Mar 23 13:58 soc-audio -rw-r--r--1 root root 4096 Mar 23 13:58 uevent Something has changed. Where is the device control for the accelerometers? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Accelerometer Data
I have been playing a bit with the accelerometers on the FR appear to observe the following: 1) The time stamp on events appears to be unreliable, in the sense that the time difference between sequential events is frequently negative, and appears also to be have erratically by jumping an order of magnitude or 2 between sequentially available events. 2) It also appears to be relatively common that a SYN arrives before all 3 axis values are available, making it hard to figure out the meaning of the data 3) There is a significant difference between the readings of the 2 accelerometers when the FR is just sitting there on the desk doing nothing. 4) When you move the FR about, the rate of reports being available appears to become very erratic, in the sense that there are relatively long periods between reports. My questions are: 1) Is this a common situation with the FR (OM2008.12) 2) Is the device driver just buggy? Of course, I realize that my own code might be just buggy, but these features of the accelerometers appear in both my C++ and TCL code, and in the example programs from the wiki references with print statements inserted. Tks for any advice. -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: opkg-deb
I use EPM to build both deb and opk/ipk from the same configuration file. As far as I can tell, the formats, at least for relatively simple packages, are identical. EPM also builds RPMs, tarballs and other stuff from a single config file. Check out Easy Package Manager and live happily ever after. Michele Renda wrote: On 03/02/2009 22:43, Jeffrey Ratcliffe wrote: Given that there are some applications (e.g. navit) which are updated regularly for opkg, but not for deb, it occurred to me that as the file formats are so similar, it shouldn't be so hard to write a script to convert from one to the other. Before I spent any time on this, has anyone beaten me to it? Hello, I think you are speaking about a alien for opkg :) I don't know if exist a package for this. The problem is not to convert a opkg in deb, is pretty standard. The problem is to manage all the dependency. The better solution is according me to maintain a list, in the wiki, with a list of software present only as opkg, and one list of software present only as deb, and package all this software.. I think Navit must to be one of the first that need to be packaged, because, with Tango Gps, are the only software to use in efficent way our FR. ___ 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: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
For those of you who are interested in the fltkwish package for the FR,
I have added a couple of ipk packages to the SF repository. The fb2image
package is a small screen shot utility that is capable of generating
either png or jpg images from a sub-window of the FR screen. The
fltkwishlibs package contains the pre-built Tcl 8.4, Mesa 7.03 (OpenGL,
GLU) and TIFF 3.0 libs. All of this is installed under the /usr/local
path, which I have on my SD card to save space on the FR itself.
The sources for these libs are widely available on the net, and the
binaries are just builds of the unmodified sources using the ARM tool chain.
Have fun. Send complaints to my regular e-mail.
Iain F.
Iain B. Findleton wrote:
Okay, for those of you who would like to test out this thing on your FR,
you can get an ipk from the fltkwish project on sourceforge.net. Once
you have Tcl on your phone (opkg install tcl), and the required
graphics libraries, you can do a quick test with the following script:
#!/bin/sh
# \
exec fltkwish $0 ${1+$@}
#
# Create an Image widget and load up a file
#
Image t.t -f myfile.jpg -w 460 -h 570 -autoscale false -center false;
Show t
You can now drag the image about with your finger, or pen. On my machine
the dragging is nice and smooth. You should have an image that is bigger
than the display screen to fully appreciate the results.
If you have troubles, and if you have read the documentation and still
have troubles, feel free to contact me.
Iain F.
Petr Vanek wrote:
On Tue, 18 Nov 2008 10:58:41 -0500
Iain B. Findleton
[EMAIL PROTECTED] (IBF) wrote:
No problem, although my setup is not opkg ready yet. As my stuff uses
Tcl, libjpeg,libpng,libtiff, the setup is not pretty yet, but if you
are a Linux handyman type, it can be done. Otherwise, it will have to
wait until I get around to package it all up...
Yes please, do share anyways,
thank you
Petr
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
--
Iain B. Findleton
Tel: 514-457-0744
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
No problem, although my setup is not opkg ready yet. As my stuff uses Tcl, libjpeg,libpng,libtiff, the setup is not pretty yet, but if you are a Linux handyman type, it can be done. Otherwise, it will have to wait until I get around to package it all up... Nicola Mfb wrote: 2008/11/17 Iain B. Findleton [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] I have implemented an image display script on the FR that demonstrates smooth scroll in the form of dragging the image about the screen. Works for fairly large images (colour weather maps of North America). The application uses the FLTK tool kit with double buffering through X. May you share it? Thanks Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Okay, for those of you who would like to test out this thing on your FR,
you can get an ipk from the fltkwish project on sourceforge.net. Once
you have Tcl on your phone (opkg install tcl), and the required
graphics libraries, you can do a quick test with the following script:
#!/bin/sh
# \
exec fltkwish $0 ${1+$@}
#
# Create an Image widget and load up a file
#
Image t.t -f myfile.jpg -w 460 -h 570 -autoscale false -center false;
Show t
You can now drag the image about with your finger, or pen. On my machine
the dragging is nice and smooth. You should have an image that is bigger
than the display screen to fully appreciate the results.
If you have troubles, and if you have read the documentation and still
have troubles, feel free to contact me.
Iain F.
Petr Vanek wrote:
On Tue, 18 Nov 2008 10:58:41 -0500
Iain B. Findleton
[EMAIL PROTECTED] (IBF) wrote:
No problem, although my setup is not opkg ready yet. As my stuff uses
Tcl, libjpeg,libpng,libtiff, the setup is not pretty yet, but if you
are a Linux handyman type, it can be done. Otherwise, it will have to
wait until I get around to package it all up...
Yes please, do share anyways,
thank you
Petr
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
--
Iain B. Findleton
Tel: 514-457-0744
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
So far, on the FR, I remain to be convinced that the use of X is the critical performance issue. In any event, the main issue with optimization efforts is whether they can proceed faster than the introduction of better hardware. If a 400 Mhz machine is too slow, will a 1 Ghz machine be fast enough? Will anything be fast enough? Apparently, from the history of desktops, the answer is no! My own experiments with the FR lead me to believe that memory access and peripheral access are more significant than X performance, but I have yet to do the tests and the math. Carsten Haitzler (The Rasterman) wrote: On Mon, 17 Nov 2008 13:54:55 +0800 John Lee [EMAIL PROTECTED] babbled: On Sun, Nov 16, 2008 at 10:05:16AM +1100, Carsten Haitzler wrote: x's internals are definitely up for improvement - callium3d is there to try and fix this by providing a better more organised and better accelerated driver layer - but again - they aren't going to replace x... just clean up internals. what it means is - the rest of us can continue happily writing x apps and just wait for an improvement to pop out the pipeline. indeed x's internal acceleration layer could be improved. it has in the past (especially with xaa) proved an impediment if you have to code AT the driver layer. as such - x was originally designs (as a system - not specifically the xorg tree etc.) to allow full freedom to implement the internals of x any way you like - so as such if you wanted to spend the effort x could accelerate just about everything as long as hardware can do it, somehow - but the points at which that acceleration knowledge need to go into might be much higher up than xaa/exa. you'd have to write a forked x with all sorts of hooks higher up. - but it's possible... and then x client work as they always did - and get more use of the hardware :) MicroXwin ? http://www.microxwin.com/ MicroXwin is binary compatible to the Xlib API. However it is niether client server nor network oriented. Graphics operations are implemented in the linux kernel via a kernel module. An open source Xlib library sends graphics commands to the kernel. There is no network overhead and no context switch from X client to X server. This makes our solution smaller and faster than traditional X Windows. as such - context switching doesn't happen as often as people think.. if you write good x code - its' buffered. but as such this is an interesting solution - that is linux specific. not sure if it handles everything (window management, and not to mention enough of the modern extensions), but for gta03 (as this is framebuffer based) this could be a definite option. i'd say it'd be worth exploring. keeps compatibility AND should give you some speedup. not sure just how much day to day though. but the license seems... opaque - no idea what it is but it looks closed. but as such this would be another valid way of doing things with x. as such x apps just should avoid round-trip calls to x, so while they run they can do all their gfx ops WITHOUT a single round trip (thus no cache flush) and they only flush on final draw of everything - so just once per frame really (for the app). -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
I have implemented an image display script on the FR that demonstrates smooth scroll in the form of dragging the image about the screen. Works for fairly large images (colour weather maps of North America). The application uses the FLTK tool kit with double buffering through X. Nicola Mfb wrote: 2008/11/17 The Rasterman Carsten Haitzler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [...] this is the thing.. the drvier is ALREADY doing this. i repeat this ad-nauseum. the acceleration is the same u get in the nv driver or you saw a few years back in the i8xx drivers etc. you get blit and fill accelerated (the most common x ops). xvideo is accelerated. the only thing not is anti-aliases font drawing and as such the glamo doesnt support this fully - u need to do some hacks to pretend it will (like expand fonts to ARGB32 in software) and from the look of it the expansion and then upload of pixels will likely net you zero speedup as this extra cost will negate the speedups you get. imho glamo is right now about as fast as u'll ever likely see it (imho). you can go sink a mountain of work and as per the example above.. see no return. the ONLY thing that i can see it might be worth it is opengl - and even then its a very weak opengl accelerator with lots of gotchas. all of the above of course is in my opinion. it's based from years of doing graphics - software and hardware and with x, and having read all of the glamo docs. Hi Raster! before reading this post I supposed that 2d acceleration was very partially implemented. This cames out for example because I never see a smooth scroll on the device. So what is the reason for this? glamo? 2d acceleration driver? poor graphics toolkit? Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
I run Mesa on my FR without any problem, aside from the possible slowness of it, but then again, its pretty similar in performance to any 400 mhz box I have used in the past. I can only presume this complaint laments the lack of hardware acceleration for the OpenGL calls. How complex can that be to achieve? Yorick Moko wrote: On Fri, Nov 14, 2008 at 11:11 AM, Wolfgang Spraul [EMAIL PROTECTED] wrote: Jacob, Glamo is not a forbidden topic. Having said that, if someone wants to seriously develop for the glamo, please get in touch with me and we will find a legally correct way to extend the smedia documentation to you. In fact we have done that in a few cases before already, but I'm not sure how much actual codes have come out of that. I think very little ;-) So we need some really serious coders that don't mind a tough challenge. Best Regards, Wolfgang wow, this is the first I hear about this I don't think it is very well know in the community. Maybe somebody can put a notification on the main page of the wiki about it? y ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Touch screen calibration?
It appears that my touch screen is out of calibration for some reason. Is there a utility or a method available to recalibrate the touch screen? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Touch screen calibration?
When I run xtscal I get: XCALIBRATE extension missing. Any ideas? Johny Tenfinger wrote: xtscal Or some menu position in Qtopia/Qt Extended. 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: Touch screen calibration?
Okay, the solution is to use ts_calibrate. xtscal does not work on 2007.x Iain B. Findleton wrote: When I run xtscal I get: XCALIBRATE extension missing. Any ideas? Johny Tenfinger wrote: xtscal Or some menu position in Qtopia/Qt Extended. 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Touch screen calibration?
There are, according to the net, issues on other distros with xtscal. Perhaps the maintainers retired? Johny Tenfinger wrote: Hmm, xtscal worked for me some time ago on 2007.2. Now it isn't working to me too :x Why? On Fri, Nov 7, 2008 at 21:42, Iain B. Findleton [EMAIL PROTECTED] wrote: Okay, the solution is to use ts_calibrate. xtscal does not work on 2007.x Iain B. Findleton wrote: When I run xtscal I get: XCALIBRATE extension missing. Any ideas? Johny Tenfinger wrote: xtscal Or some menu position in Qtopia/Qt Extended. 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 ___ 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: GPS sensitivity
I find the FR more or less equivalent to other GPS devices I have. The biggest factor I notice is weather conditions. In overcast conditions I can use the GPS anywhere inside my house, as well as outside. Under clear sky conditions, the GPS will only work outside and will not acquire a first fix unless I am more or less in the open, away from trees, houses, etc. Some people claim that there are newer GPS chips that work better. Perhaps its the nature of the beast. Nishit Dave wrote: On Mon, Oct 27, 2008 at 9:18 PM, Alastair Johnson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Stefan Monnier wrote: The FR is the first device I use with a GPS, so I don't know what's considered as normal w.r.t GPS function. I find that my FR's GPS never works inside a building (e.g. at home), and even outside in the streets of Montreal, it seems to only be able to get a first fix if I'm in a somewhat open area (i.e. not in a street but on a place, in a park), and also it seems to rarely if ever be able to get a first fix when it's in my pocket. Is that normal? My FR does have the capacitor in the µSD slot and it has a fairly recent kernel (don't know if that means it has the software fix that stops the µSD clock when possible, does it?) It's a little tricky to describe 'normal' since the movement of the sats gives some inherent variability. Getting the first fix also requires significantly more signal than maintaining a fix once acquired, and it seems to help being stationary when doing it. I don't know how limited the view of the sky is in Montreal, but 'urban canyon' effects have long been a problem for GPS systems due to limited view of the sky (can't see enough sats) and multiple reflected signals. That said, since the SD clocking fixes were added to the kernel I find the Freerunner usually at worst as quick as my Garmin Gecko at getting a fix, and substantially better at keeping it. The Freerunner will often keep a fix indoors when the Gecko hasn't a hope. OTOH the Gecko is hardly state of the art now, so expectations may be different. I recently tested the performance of a Nokia E71 with the FR, while standing 2 feet from a window inside my office building. Most of the view (line of sight) was obstructed by another large building 200 ft away, although the sky over it can be viewed from the said window. The Nokia got a fix and started to download maps with google maps in 15 seconds. I was unsuccessful in getting the FR to register a fix at the same position for greater than 15 minutes, after which the experiment was stopped. Qtextended 4.4.1, MappingDemo used. The FR version I use is from the time when the software fix to the hardware problem was about to be released. The FR still takes some minutes to get a fix when in a moving vehicle, and anywhere inside a building, it is as if it never worked. Nothing new. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Touchscreen scratch protection
Clear plastic contact wrap works for me. Cheap, replaceable and easy to install Xavier Cremaschi wrote: Alastair Johnson a écrit : http://www.zagg.com/invisibleshield/openmoko-neo-freerunner-cases-screen-protectors-covers-skins-shields.php I am currently using a full invisible shield protection Invisible Shield protects your device from scratches, and it does it very well, but you lose a bit in good-looking aspect (in my opinion) and in usability. About the body protection : as a geek I generally consider protection to be more important than look, but the FreeRunner looks far better without it (without:smooth and matte, with:adhesive and glossy/plastic). About the screen protection : very good protection too, but less slippery. A friend of mine bought an HTC recently and fingers slide well on default protection. That's not the case with the Invisible Shield, it is a bit harder to use. Having an object that pleases you is important too... maybe I will remove Invisible Shield soon. Neo1973 owners : how does your device look today ? Xavier. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ``Freerunner reliable and stable''?!
Sorry to disagree. There was lots of info about how the FR was not ready for prime time available when I bought mine. I think it is pretty clear that this machine is a hackers box that makes phone calls, and that is what I bought. I use the thing for phone calls and it works just fine. Its also a machine that is roughly equivalent to a PC desktop one might have bought in the late 90's, only a lot more portable. Only real drawbacks I find with the FR is the battery life. Aside from that its great. As to OM, they are quite obviously not a highly professional gang with loads of marketing and support resources, and the direction of the project appears to be somewhat vague. That said, I am a happy customer because I can roll my own applications, and eventually fix most of the issues with the machine myself. If I want a professional, thoroughly solid phone with bells and whistles that appeal to a teeny-bopper or business exec, I will get a Nokia. As for the FR, you can run a small business completely off the phone is you want to do so, and carry it in your pocket, complete with customer data and development tools. Try that on your Nokia. Ole Kliemann wrote: On Sun, Oct 26, 2008 at 11:44:35AM +0100, Matthias Apitz wrote: Hello, I'm a bit tired of all those (useless) threads like this. I DO USE the FR with Om2008.9 for everyday use, I do not even own any other cellphone. We should improve what we have and stop useless discussions, as well about Google's trick of Android which has nothing todo with free software. Thx matthias Sorry for asking, but have you actually read my post? All these useless discussions arise from the discrepancy between what people expect and what OM delivers to them. A clear warning about GTA02 on openmoko.com and the annouce mail could have saved us a lot of useless discussions. Certainly no use crying over spilt milk now. Just the problem remains. If you are into the community and the wiki and you just look at openmoko.com, you still think you get a usable and reliable phone. Judging just from openmoko.com, which I understand is the official company's website, there is a problem with OM's self-perception. Ole ___ 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: Partitionning separate /home/ floder to SD
All that works just fine, particularly the use of a swap partiton which eliminates the slowing of the FR with time. I also made /usr/local point to the uSD so that any applications I install are not affected by changes to the flashed stuff. I notice little negative effects by putting as much as possible on the uSD. I did appear to observe that using ext3 on the uSD partitions appears to be faster than using FAT file systems, however. That is just an impression as I have not run any tests. Joel Newkirk wrote: On Sun, 19 Oct 2008 22:39:34 +0100, Andy Selby [EMAIL PROTECTED] wrote: Is there a way that /home/ is in my SD card? Only /home/, like we do in Linux distributions... so I can flash whenever i want the Neo without loosing configuration files, icons and stuff I am adapting for myself in the Neo? Did you try #link /media/card/home /home Actually that'd be 'ln'... ;) The solution I suspect Andy is seeking is to alter /etc/fstab: /dev/mmcblk0p1 /media/card autodefaults,async,noauto 0 0 change to /dev/mmcblk0p1 /home autodefaults,async,noauto 0 0 This replaces /home in the filesystem with the contents of the first partition on the uSD. (note that if the /home folder already exists that this will effectively redirect /home to the uSD without touching the 'local' /home, so that if the uSD is removed, corrupted, etc, and doesn't mount, there's still a /home/root folder, just without everything you customized and added while on the uSD) When (if) I get my FR where I plan to retain the same installation long-term, I intend to carve up the 8gb uSD and have /dev/mmcblk0p3 as /home. (partition #2 as swap, #1 as alternate boot) j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner a month after
Really depends on what your motivations and goals are, I suspect. Personally, I develop the applications that I want on the phone using TclFltk, a scripting based language that uses the FLTK tool kit. Since this cross platform environment works on Windows, Linux, etc. It does not get bogged down on all this platform dependant stuff. I suspect that there must be other things that are pretty isolated from the stack, like python-gtk or java that you can use. On the other hand, if you are into the internals of the phone, your project will probably have a lot of trouble because of the lack of documentation and access. My projects are strictly user space applications, and so far, things are relatively speaking just fine. Nicola Mfb wrote: Hi, After experimenting with freerunner and trying to develop applications for it I have some doubts. I searched on the mailing-list, forums, wiki and so on, but I was not able to retrieve some basic information that I need to continue this exciting experience. If someone answers on this I think a lot of people will appreciate, and I'll be happy to update the wiki. First of all, I'd like to have some clarifications about software stack future. Actually, we have tree main distros: 2008.x, fso and qtopia. Qtopia is very stable, but peoples seems to not prefer it as not community based (I was not able to find qtopia 4.3.3 snapshot sources, but this is another problem). 2008.x is based on an older qtopia fork patched for x11, using it's phone server, dialer and settings. In the om-oe-tree it seems there is no staging for qt/qtopia library, nor documentation that explains how to develop qtopia/qt applications for 2008.x (I hope I'm in error), so you cannot interact easly with qtopia stack. You may use excellent qtopia offical SDK but your applications will not run becouse they need a qpe server. You may bitbake qt4-free-x11, and build applications against it, but i do not know if they are compatible with libraries that provided by qtopia on x11 itself and if that oe recipie is om-supported or is it there only from the oe fork. So it seems developing over qtopia/2008.x is not encouraged (at least for external developers). The last is FSO, it has documentation and is a very nice middleware and is bleeding-edge. I may be in error again (if i am please ignore the next assumptions!) but it seems as FSO is developed out of Fic or OpenMoko inc., directly on openembedded (some rumors about developers that left openmoko and join fso). The second doubt came as that om-oe-tree is a fork of oe-tree and is on a different git server, why this? to leave to openmoko official developers the full control over it? If some bitbake recipies need a fix, should the openmoko developers fix it or the oe guy? After that there are debian and other coming soon distros, as gentoo. All these dependes above all on openmoko linux kernel, are the openmoko developers the only writing/mantaining it? are oe guys involved too? On the wiki i read that next openmoko release will be based on fso, so will openmoko guy patch qtopia x11 to use dbus and avoid it's intertnal phone server? if not why are they supporting the project? I know this is a mix between political and technical questions, but please clarify! Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.9 Basic questions
Well, the box certainly is in a fairly raw state, and most of the apps there are pretty basic in terms of polish and performance, surprisingly so to me, as it is a machine that is roughly the equivalent of a desktop that one might have used in the late '90s. However, I make use of it instead of carting around a laptop. You can run a lot of stuff on the machine from the Linux community if you just use the usb network connection to another PC. With 8 GB of storage on it, you probably don't need more for usual daily business apps, and while the bloatware out there is a possible problem, there is a huge amount of stuff that runs very nicely, thankyou, right on the phone. It also works fairly well as a basic phone/text gaget for me if the network signal is good. The only real irritations that I have found are: 1) GSM reception is poor compared to most standard phones, and positively crappy compared to an ancient Nokia I use. 2) GPS reception is flakey when not actually under clear sky. 3) Battery life is lousy. And of course, the buggy software can hurt. Surprisingly, I activated swap on my FR and stability and periodic slowing have improved. Don't know why that should be, but there you are. Generally, the performance of all the parts of this box is far better than the 33 Mhz i486 I ran Slackware 96 on back in the previous century, so, there is a solution out there. Whether the OM people are able to put it together is an open question. I suggest they hire some old people if they have not gotten some there already. If a programmer is old enough, he/she will know how to make everything run well in 16KB of memory and 128KB of 230ms disk access. rakshat hooja wrote: Sorry for the chain of posts, but when I bought the phone, IDA Systems claimed it had a 500 MHz processor. Now they have corrected their website to say it is 400 MHz. Are we trying to promote openness here, or damage it? Dear Nishit, The 500MHz was based on early confusion based on the fact that the Samsung processor is capable of 500 Mhz but is clocked at 400 Mhz. The early buyers were offered 30 days return policy (we only get 28 days dead on arrival from Openmoko) for the very reason that some buyers may not like what the Freerunner offers. 30 days are over but in your case, as a special consideration, if you are not satisfied with the Freerunner please post it back to us and we will give you a full refund. We have limited supply of the Freerunner and need devices to send as review samples. Hope this will take you out of your misery a little. Regards, Rakshat ___ Openmoko community mailing list community@lists.openmoko.org mailto:community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- -- Please use Firefox as your web browser. Its protects you from spyware and is also a very feature rich browser. www.firefox.com http://www.firefox.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Screen shot failure?
Aborts with some message about not being able to convert the png CREATOR field to an ISO charset. Anybody know the solution to this one? -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screen shot failure?
Hardly. Its the screen shot application on the GTA-02 that fails with this message. I know what the png field actually is. My question is whether there is a fix or configuration requirement for my FreeRunner. Dale Maggee wrote: Iain B. Findleton wrote: Aborts with some message about not being able to convert the png CREATOR field to an ISO charset. Anybody know the solution to this one? google is your friend ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Display of Images on GTA-02
After doing some experiments which involve displaying an image on the screen of the GTA-02 I have the impression that things are unduly slow. The problem is to display a single image (jpg,png,gif) which is currently in a file on the root file system. Image size is 570 x 420 pixels in 32 bit color. It appears to take several (~10) seconds to read the image from the file and then display it on the screen. This is incredibly slow for a 400 MHZ machine and I am wondering if others have had similar experiences. Along the same lines, the tangoGPS application looks to take a long time to update the screen from a local cache. Anybody have any ideas? -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Display of Images on GTA-02
On my Freerunner, XGlamo does not appear to be a CPU hog, although in light of the tickets mentioned I am going to check further on that. I do notice that the machine slows considerably at times for no particular reason. Top shows that pulseaudio is the main CPU hog, and I wonder why that should be? I am not doing any sound stuff aside from the click of the touch pad. Is the source for XGlamo available at all? I recall reading something about the chip internals not being public but I can probably spot bad server code. I have another ARM box on which I run nano-X without problems, and that is a 200 MHZ machine. Graphics is quite responsive there, so the Freerunner should positively fly. Thomas B. wrote: On Wed, Sep 10, 2008 at 10:42:12AM -0400, Iain B. Findleton wrote: After doing some experiments which involve displaying an image on the screen of the GTA-02 I have the impression that things are unduly slow. The problem is to display a single image (jpg,png,gif) which is currently in a file on the root file system. Image size is 570 x 420 pixels in 32 bit color. It appears to take several (~10) seconds to read the image from the file and then display it on the screen. This is incredibly slow for a 400 MHZ machine and I am wondering if others have had similar experiences. Well, the performance of my Freerunner regularly breaks down because of [1]. Also [2] might be relevant for you. What does top say while the image is loading? Regards, Thomas [1] http://docs.openmoko.org/trac/ticket/1597 [2] http://docs.openmoko.org/trac/ticket/1315 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Display of Images on GTA-02
Thanks, Rui, Unfortunately, the package is not found on the openmoko site. Iain Rui Miguel Silva Seabra wrote: On Wed, Sep 10, 2008 at 12:35:46PM -0400, Iain B. Findleton wrote: reason. Top shows that pulseaudio is the main CPU hog, and I wonder why that should be? I am not doing any sound stuff aside from the click of the touch pad. opkg install pulseaudio-module-suspend-on-idle echo load-module module-suspend-on-idle /etc/pulse/session Problem solved. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
