Re: QtMoko and X applicatiions

[Iain B. Findleton]

Thanks for the hint.

When I start QM from the qtmoko menu, I get nothing but a blank screen 
and an input for an application. I have updated the files in 
/opt/qtmoko/etc/qm as described in the Openmoko wiki, but the menu items 
for favourites shows nothing. Is there any other updated documentation? 
Need I install something?





Harry Prevor wrote:

On 1/24/13, Iain B. Findleton  wrote:
  

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.



There's an application that comes with QtMoko called QX. QtMoko runs
entirely off the framebuffer by default, but QX is sort of like having
the X Server inside an application. You choose a command to run in QX
and it just works.

  



--
--------
Iain B. Findleton
514-457-0744


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

QtMoko and X applicatiions

[Iain B. Findleton]

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

[Iain B. Findleton]

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?

[Iain B. Findleton]

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?

[Iain B. Findleton]

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

Re: SHR-Core : Display issue?

[Iain B. Findleton]

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

SHR-Core : Display issue?

[Iain B. Findleton]

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

[Iain B. Findleton]

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?

[Iain B. Findleton]

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

[Iain B. Findleton]

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

Re: Tangogps?

[Iain B. Findleton]

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  writes:>> "Iain B. Findleton"  
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

Tangogps?

[Iain B. Findleton]

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: Article: What happened to real open source phones?

[Iain B. Findleton]

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

[Iain B. Findleton]

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?

[Iain B. Findleton]

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

[Iain B. Findleton]

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"  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

[Iain B. Findleton]

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

[Iain B. Findleton]

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

[Iain B. Findleton]

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?

[Iain B. Findleton]

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

[Iain B. Findleton]

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  > 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

[Iain B. Findleton]

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

Re: OM future

[Iain B. Findleton]

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

tangogps-0.99.3 ipk?

[Iain B. Findleton]

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

[Iain B. Findleton]

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  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?

[Iain B. FIndleton]

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

Re: [all] reading accelerometers to a text file

[Iain B. Findleton]

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

New release of TclFltk and a couple of simple apps...

[Iain B. Findleton]

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: Quick e-mail poll: Still using your Freerunner?

[Iain B. Findleton]

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: [SHR-U] Screen Calibration

[Iain B. Findleton]

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"  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

[SHR-U] Screen Calibration

[Iain B. Findleton]

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: reliable wifi gui for SHR

[Iain B. Findleton]

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]

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
>>  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

Re: SHR-U Accelerometer data

[Iain B. Findleton]

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
>  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

SHR-U Accelerometer data

[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.

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] wifi connection

[Iain B. Findleton]

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

[Iain B. Findleton]

Ken Young wrote:
> DJDAS  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

[Iain B. Findleton]

Al Johnson wrote:
> On Sunday 25 October 2009, Ivo van den Maagdenberg wrote:
>   
>> 2009/10/25 Frederik Sdun 
>>
>> 
>>> * Iain B. Findleton  [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

Re: [SHR] Accelerometers

[Iain B. Findleton]

Al Johnson wrote:
> On Sunday 25 October 2009, Ivo van den Maagdenberg wrote:
>   
>> 2009/10/25 Frederik Sdun 
>>
>> 
>>> * Iain B. Findleton  [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

[SHR] Accelerometers

[Iain B. Findleton]

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...

[Iain B. Findleton]

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/?

[Iain B. Findleton]

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  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 st

Re: vi vs. nano in shr user manual (was Re: SHR first experiences & user manual)

[Iain B. Findleton]

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?)

[Iain B. FIndleton]

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 Lippmann 
>> 
> 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 "terri

Re: git checkout

[Iain B. Findleton]

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"  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

Re: git checkout

[Iain B. Findleton]

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"  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

git checkout

[Iain B. Findleton]

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

[Iain B. Findleton]

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: Accelerometers in recent kernels

[Iain B. Findleton]

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: Accelerometers in recent kernels

[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?


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: Graphics Performance

[Iain B. Findleton]

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  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: Graphics Performance

[Iain B. FIndleton]

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  said:
>
>   
>> On Sat, 4 Apr 2009 00:01:16 +1100
>> Carsten Haitzler (The Rasterman)  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

Re: Graphics Performance

[Iain B. FIndleton]

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

[Iain B. FIndleton]

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"  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

[Iain B. FIndleton]

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

[Iain B. FIndleton]

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 
> 
> 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

Graphics Performance

[Iain B. FIndleton]

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: Accelerometer Data

[Iain B. FIndleton]

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

[Iain B. FIndleton]

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

Re: Accelerometer Data

[Iain B. FIndleton]

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

Accelerometer Data

[Iain B. Findleton]

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

[Iain B. FIndleton]

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)

[Iain B. Findleton]

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)

[Iain B. Findleton]

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)

[Iain B. Findleton]

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)

[Iain B. Findleton]

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: Buzzing (was :The forbidden topic: Glamo OpenGL)

[Iain B. Findleton]

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: The forbidden topic: Glamo OpenGL

[Iain B. Findleton]

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

Re: Touch screen calibration?

[Iain B. Findleton]

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: Touch screen calibration?

[Iain B. Findleton]

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?

[Iain B. Findleton]

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

Touch screen calibration?

[Iain B. Findleton]

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: Touchscreen scratch protection

[Iain B. Findleton]

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: GPS sensitivity

[Iain B. Findleton]

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: ``Freerunner reliable and stable''?!

[Iain B. Findleton]

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

[Iain B. Findleton]

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

[Iain B. Findleton]

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

[Iain B. Findleton]

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

Re: Screen shot failure?

[Iain B. Findleton]

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

Screen shot failure?

[Iain B. Findleton]

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: Display of Images on GTA-02

[Iain B. Findleton]

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

Re: Display of Images on GTA-02

[Iain B. Findleton]

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

Display of Images on GTA-02

[Iain B. Findleton]

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