Re: Community effort: Browser review/comparison in wiki
On Mon, Mar 23, 2009 at 1:38 AM, Marco Trevisan (Treviño) m...@3v1n0.net wrote: Risto H. Kurppa wrote: (I'm currently using Minimo as AFAIK it's the only one that can actually login to gmail, and I know that it's not developed anymore but.. ) Did you read my reply-mail about this theme? However any webkit based browser can log in gmail if you simply update your libcurl with one that is compiled with libgnutls support (allowing ssl). Search in the archives for links... ;) I did but I guess something didn't quite work out.. I'll check it later again.. Thanks! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
On Sun, Mar 22, 2009 at 07:39:13PM -0700, Charles-Henri Gros wrote: Iain B. Findleton wrote: 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 I've seen that too; it seems that '0' readings are discarded. What I did in omnewrotate was to discard packets with any coordinate '0', and provide a flag to consider them, instead of discarding. Also, a packet is x, y, z, sync. If it isn't this sequence, I discard it. Rui -- All Hail Discordia! Today is Boomtime, the 9th day of Discord in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Is SIM Toolkit possible to support on the freerunner?
The reason for asking, is that my bank provides internet banking, and the authentication process is greatly simplified by having a STK-supporting phone. Basically, the telco installs a piece of software onto the SIM card (already done), that exchange encrypted sms with the bank. Most of the software runs on the SIM card processor. That part works with any phone - even the freerunner. STK support on the phone is needed when this software need to ask me about my banking PIN code. It needs to display a prompt, and get my response. And the sim card processor can obviously not control the display directly, but making such a question-answer GUI is simple enough. The interesting question - is this possible at all? Is our gsm chip capable of STK communication? Is there a set of AT commands (or similiar) to use for this purpose? I teach programming, so I can sometimes set up student projects for things like this. Provided that it is possible, of course. STK is used for various other purposes as well, some of which may be nice to support. I do not worry that telcos might use STK for crippling the phone. The phone is open-source, and it will obviously possible to not use this software. Don't install STK if you don't want it. Also, an open-source implementation of STK won't be able to do wrong. We control it, so it can't control the phone against our will. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
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
Re: Bluetooth headsets to the rescue
Hi again, I can tell that these e-mails of mine will either age-out like so many regarding this issue have in the past, or the community will get upset because of my constant and irritating questioning. Would it be worth while to start a petition for the official fix in the wiki (As I said in the past this is not to force a fix into existence, only to get official word on whether it will ever be available)? That way I can stop filling up your inboxes with e-mails that you are probably already tired of. Thanks ezuall -- View this message in context: http://n2.nabble.com/Buzz-Issues---Last-Questions%2C-I-promise-tp2509041p2520061.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bying a Freerunner with the buzz-fix on it
Hi, one month after, do you have any update relative to shipping date of GTA02v7 ? Kind regards, Xavier ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
ezuall ezu...@gmail.com writes: Would it be worth while to start a petition for the official fix in the wiki No. They obviously know that community is extremely irritated about it and want to hear _any_ official statement. But they prefer being silent. I guess we'll need to wait for another month for the final clarifications. And btw, in case you missed it, there're already 2 officially (OM-the-company) supported buzz rework parties planned. And don't forget that the proposed rework doesn't fix wired headset mic, it will still produce a lot of buzz. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
On Mon, Mar 23, 2009 at 10:53, Paul Fertser fercer...@gmail.com wrote: And don't forget that the proposed rework doesn't fix wired headset mic, it will still produce a lot of buzz. Oh ? I had not seen this info yet... :-( Is this the same buzz as before rework or another problem ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
And don't forget that the proposed rework doesn't fix wired headset mic, it will still produce a lot of buzz. how's that? i lived under the impression that the buzz is basically one buzz and the hw fix is intended to end all buzz. any sources proving your statement available? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
paroli updates
Is paroli still being worked upon? I see that the latest git changes were made 10 days ago. Some kind of holiday going on? Even shr and fso development seems slower these days (the latest ticket fixed in fso is from March 10th) ... I just want to make sure my phone won't stay dead paperweight forever :-) Franky ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] vim, ntpclient... a repository ?
Date: Sun, 22 Mar 2009 09:51:56 +0100 From: Xavier Cremaschi omega.xav...@gmail.com Subject: [SHR] vim, ntpclient... a repository ? To: community@lists.openmoko.org Message-ID: gq4u7d$gb...@ger.gmane.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi folks, does someone know how to install vim (not vi) in SHR ? I think there is one repository I don't have, I can't believe vim to be not available :P Xavier. Hi Xavier, you can find vim (in my case worked in both OM2008.x and SHR) here: http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/vim_7.0-r1.1_armv4t.ipk And obviously it works perfectly! Cheers Giacomo -- /_\ The ASCII Per comunicare in modo riservato: \_/ Ribbon Campaign gpg --keyserver pool.sks-keyservers.net \ X Against HTML--recv-keys 20611EAD /_\ Email! -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM buzz-fix party in Braunschweig, Germany
/me is also interested in sending the (1) phone to you. Would it also be possible to perform the bass fix? Thank you very much for your effort! Sven ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All] Suggested IMAP client?
On Sat 21 March 2009 om 07:36:52 GMT William Kenworthy told us: Yes, this would be nice. In the meantime, Ive fallen back to squirrelmail on my webserver and midori to read it on the FR. Works ok, but is there a better webmail more suited to a small screen? I use MIMP, part of the Horde framework. http://www.horde.org/mimp/ However, a real mail client would be vey nice. On Fri, 2009-03-20 at 17:29 -0400, Cameron Frazier wrote: As per the subject, is there a suggested IMAP client for the FR? I'm using SHR-Unstable at the moment, but I figure it's a reasonable question for all distros. Kind regards, Cameron ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- William Kenworthy bi...@iinet.net.au Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Remember there's a big difference between kneeling down and bending over. -- Frank Zappa ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
Okay, it looks like the 2.6.28 kernel and modules are an improvement for the accelerometer data, but the report times, while not negative any more, appear somewhat erratic. The type codes appear to be unchanged in this build, with the driver reporting EV_REL and EV_SYN. Thanks for the various suggestions. I will report whatever else I find that appears interesting. Iain F. Michael Tansella wrote: In the latest andy-tracking it reports the more correct 'ABS' events. So now it does report zeros. However it doesn't report an axis if there has been no change. Is it correct that there are now two changes for developers. The first one is that the EVENT type has changed from EV_REL (0x02) to EV_ABS (0x03). This would mean in the python sample code of the wiki the change would be: from: if type == 2: if code == 0: x = value if code == 1: y = value if code == 2: z = value to: if type == 3: if code == 0: x = value if code == 1: y = value if code == 2: z = value The second change is that if no new (y,x, or z) value is reported the old one should be taken. If you want to simply get the current values there is an ioctl : EVIOCGABS I think. I think that is what most developers want. It would be great if someone could show a small sample code how this works. Greets Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
arne anka openm...@ginguppin.de writes: And don't forget that the proposed rework doesn't fix wired headset mic, it will still produce a lot of buzz. how's that? i lived under the impression that the buzz is basically one buzz and the hw fix is intended to end all buzz. any sources proving your statement available? Schematics. Or ask Joerg. Basically the idea is that the buzz gets to the MICBIAS line via the 4th pin of the headphone receptable (that is mic input). The longer antenna you attach to it, the more RF you get. Then it's detected somewhere inside the Wolfson and comes back via the same MICBIAS line this time as a very strong audio frequency signal. With internal mic you can use a large cap to filter it on one side of the mic and get the signal from the other side because it's connected in a differential way. With the headset mic it's not possible because it has only one line. The rework for that would take lifting the can, desoldering one small R, soldering two of them in parallel to the same place (already tricky enough!) and adding a big cap to gnd (and free space inside the can is very limited). So, not practically possible. Read the schematics. OTOH you can use headphones and _internal_ mic for GSM after buzz-fixing it. NB: Factory-produced A8 will have ferrite beads in place (so RF will not get anywhere it can be detected in the first place), and that should probably solve all known buzz problems. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
On Mon, 2009-03-23 at 16:51 +0300, Paul Fertser wrote: arne anka openm...@ginguppin.de writes: And don't forget that the proposed rework doesn't fix wired headset mic, it will still produce a lot of buzz. how's that? i lived under the impression that the buzz is basically one buzz and the hw fix is intended to end all buzz. any sources proving your statement available? Schematics. Or ask Joerg. Basically the idea is that the buzz gets to the MICBIAS line via the 4th pin of the headphone receptable (that is mic input). The longer antenna you attach to it, the more RF you get. Then it's detected somewhere inside the Wolfson and comes back via the same MICBIAS line this time as a very strong audio frequency signal. With internal mic you can use a large cap to filter it on one side of the mic and get the signal from the other side because it's connected in a differential way. With the headset mic it's not possible because it has only one line. The rework for that would take lifting the can, desoldering one small R, soldering two of them in parallel to the same place (already tricky enough!) and adding a big cap to gnd (and free space inside the can is very limited). So, not practically possible. Read the schematics. OTOH you can use headphones and _internal_ mic for GSM after buzz-fixing it. NB: Factory-produced A8 will have ferrite beads in place (so RF will not get anywhere it can be detected in the first place), and that should probably solve all known buzz problems. Just a wild guess, but is it possible to replace the headphone receptable with a shielded one? Would perhaps be more of a DIY job then replacing SMD resistors and add SMD caps. Kind regards, Ed ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
Charles-Henri Gros wrote: A known issue in 2008.12. http://docs.openmoko.org/trac/ticket//2145 Workaround: echo 10 /sys/devices/platform/lis302dl.1/threshold ls /sys/devices/platform: drwxr-xr-x 21 root root0 Mar 23 12:40 . drwxr-xr-x4 root root0 Mar 23 12:39 .. drwxr-xr-x3 root root0 Mar 23 12:39 gta02-led.0 drwxr-xr-x3 root root0 Mar 23 12:39 gta02-pm-wlan.0 drwxr-xr-x3 root root0 Mar 23 12:39 neo1973-memconfig.0 drwxr-xr-x3 root root0 Mar 23 12:39 neo1973-version.0 drwxr-xr-x3 root root0 Mar 23 12:39 physmap-flash.0 drwxr-xr-x2 root root0 Mar 23 13:58 power drwxr-xr-x3 root root0 Mar 23 12:39 s3c2410-iis drwxr-xr-x4 root root0 Mar 23 12:40 s3c2410-ohci drwxr-xr-x3 root root0 Mar 23 12:39 s3c2410-wdt drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-i2c drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-nand drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-sdi drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-uart.0 drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-uart.1 drwxr-xr-x3 root root0 Mar 23 12:39 s3c2440-uart.2 drwxr-xr-x4 root root0 Mar 23 12:40 s3c2440-usbgadget drwxr-xr-x3 root root0 Mar 23 12:39 s3c24xx_pwm.0 drwxr-xr-x6 root root0 Mar 23 12:39 sc32440_fiq.0 drwxr-xr-x3 root root0 Mar 23 13:58 soc-audio -rw-r--r--1 root root 4096 Mar 23 13:58 uevent Something has changed. Where is the device control for the accelerometers? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] vim, ntpclient... a repository ?
El día Monday, March 23, 2009 a las 11:40:07AM +0100, giacomo giotti mariani escribió: Hi Xavier, you can find vim (in my case worked in both OM2008.x and SHR) here: http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/vim_7.0-r1.1_armv4t.ipk And obviously it works perfectly! Cheers Giacomo For me it gives: r...@om-gta02:~# vim events.py Illegal instruction in Om2008.9 matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e matthias.ap...@oclc.org - w http://www.oclc.org/ http://www.UnixArea.de/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
Paul Fertser fercer...@gmail.com writes: R, soldering two of them in parallel to the same place (already s/parallel/series/ -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
As I've been asked to comment by Paul... Yes, this is accurate info. Big-C stopping buzz for internal mic only. Shielding headset may or may not work. There's been reports of stopping or reducing hs-buzz by adding a huge bead next to or inside the hs-plug, to stop RF from entering the device via hs-cable. Anyway this will help to reduce hs-buzz to what it's been for internal mic prior to big-C rework only, as internally generated buzz remains the same with buzzfix for MICBIAS voltage to headset (Paul comprehensively explained why) cheers jOERG Am Mo 23. März 2009 schrieb Paul Fertser: Paul Fertser fercer...@gmail.com writes: R, soldering two of them in parallel to the same place (already s/parallel/series/ signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
Yes, this is accurate info. Big-C stopping buzz for internal mic only. well, that's pretty disappointing. making a call and simultaneously doing something with the phone requires a headset -- when a call comes in it is easy to plug in the wired headset and off you go. using bt means: enable bt, power on headset, connect, pray your partner has not hung up annoyed. having bt on always eats power and i don't like to walk around like a steiff's teddy bear with a button in my ear, looking like one of these hey, i am important! idiots. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] vim, ntpclient... a repository ?
Hi Xavier, you can find vim (in my case worked in both OM2008.x and SHR) here: http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/vim_7.0-r1.1_armv4t.ipk And obviously it works perfectly! Cheers Giacomo For me it gives: r...@om-gta02:~# vim events.py Illegal instruction in Om2008.9 matthias May be you miss some dependences, I use vim every days with great satisfaction (to be honest on a OM2008.12, I've never tried it in a older ASU). Is Illegal instruction the only error you get? By Giacomo -- /_\ The ASCII Per comunicare in modo riservato: \_/ Ribbon Campaign gpg --keyserver pool.sks-keyservers.net \ X Against HTML--recv-keys 20611EAD /_\ Email! -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
Am Mo 23. März 2009 schrieb arne anka: Yes, this is accurate info. Big-C stopping buzz for internal mic only. well, that's pretty disappointing. I agree. Anyway that's as good as it gets. You seen Paul's comment about using internal mic in conjunction with headphones/headset for GSM purposes? /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
You seen Paul's comment about using internal mic in conjunction with headphones/headset for GSM purposes? yes. but it has two (and maybe a half) drawbacks - you need another set of headphones with 2.5 plug - someone needs to prepare a state file for that scenario -- i am incapable to understand that alsa lingo or read the charts the half: what about the sound when you hold the phone so you can use the stylus or your fingers? will the mic pick up the voice in good quality? will my hand interfere somehow? the tapping and scartching? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
On Mon, Mar 23, 2009 at 16:50, arne anka openm...@ginguppin.de wrote: making a call and simultaneously doing something with the phone requires a headset -- when a call comes in it is easy to plug in the wired headset and off you go. using bt means: enable bt, power on headset, connect, pray your partner has not hung up annoyed. having bt on always eats power and i don't like to walk around like a steiff's teddy bear with a button in my ear, looking like one of these hey, i am important! idiots. Agreed. I am loosing faith in ever having a really usable freerunner... I am now less willing the effort to have the buzz rework done, for only a partial result... On Mon, Mar 23, 2009 at 17:13, Joerg Reisenweber jo...@openmoko.org wrote: I agree. Anyway that's as good as it gets. You seen Paul's comment about using internal mic in conjunction with headphones/headset for GSM purposes? Except in some cases, not really useful. Usually not have the phone close to my mouth when I use the headset. So internal mic would have to be over amplified, so quality going down and ambiant sounds getting annoying. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
Am Mo 23. März 2009 schrieb arne anka: You seen Paul's comment about using internal mic in conjunction with headphones/headset for GSM purposes? yes. but it has two (and maybe a half) drawbacks - you need another set of headphones with 2.5 plug Hmm, I don't see the point here. Can be done with any headset/headphones, including the FR accessory ones. Probably I got you wrong. - someone needs to prepare a state file for that scenario -- i am incapable to understand that alsa lingo or read the charts NP, I'll supply one. the half: what about the sound when you hold the phone so you can use the stylus or your fingers? will the mic pick up the voice in good quality? Depends on distance mouth-mic. You can test right now. will my hand interfere somehow? Same here. Probably not. the tapping and scartching? Dunno. Good point. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is SIM Toolkit possible to support on the freerunner?
Helge Hafting wrote: The interesting question - is this possible at all? Is our gsm chip capable of STK communication? Is there a set of AT commands (or similiar) to use for this purpose? Android and Qt Extended both have SIM Toolkit support. In QTE it's disabled - i havent tested what it would do when enabled. In Android it was not working for me, but i didnt do any exploring. This month i switched bank, that does uses plain SMS, so i dont need sim toolkit anymore :) Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: paroli updates
Developers have something strange called Real Life too :) But I want to do some useful changes in shr-settings in next few days. Stay tuned :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
On Monday March 23, michael-tanse...@gmx.de 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
Or
if type == 2 or type == 3:
...
then it would work on both old and new kernels.
The second change is that if no new (y,x, or z) value is reported the old one
should be taken.
Correct. The code you have given does this already, providing that x,
y, and z persist between calls to that code.
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.
In C it is simply:
#include linux/input.h
.
.
.
struct input_absinfo abs;
ioctl(fd, EVIOCGABS(ABS_X), abs); x = abs.value;
ioctl(fd, EVIOCGABS(ABS_Y), abs); y = abs.value;
ioctl(fd, EVIOCGABS(ABS_Z), abs); z = abs.value;
In python it is a little harder because you need to make your
own EVIOCABS()
Something like...
import fcntl, struct
_IOC_WRITE = 1
_IOC_READ = 2
_IOC_NRBITS = 8
_IOC_TYPEBITS = 8
_IOC_SIZEBITS = 14
_IOC_DIRBITS = 2
_IOC_NRSHIFT = 0
_IOC_TYPESHIFT = _IOC_NRSHIFT + _IOC_NRBITS
_IOC_SIZESHIFT = _IOC_TYPESHIFT + _IOC_TYPEBITS
_IOC_DIRSHIFT = _IOC_SIZESHIFT + _IOC_SIZEBITS
def _IOC(dir, type, nr, size):
return ( (dir _IOC_DIRSHIFT) |
(ord(type) _IOC_TYPESHIFT) |
(nr _IOC_NRSHIFT) |
(size _IOC_SIZESHIFT))
def EVIOCGABS(abs):
return _IOC(_IOC_READ, 'E', 0x40 + abs, 5*4)
ABS_X = 0
ABS_Y = 1
ABS_Z = 2
def get_abs(fd, code):
buf = struct.pack('i', 0, 0, 0, 0, 0)
abs = fcntl.ioctl(fd, EVIOCGABS(code), buf)
(val,min,max,fuzz,flat) = struct.unpack('i', abs)
return val
fd = open(/dev/input/event2)
x,y,z = get_abs(fd, ABS_X), get_abs(fd, ABS_Y), get_abs(fd, ABS_Z)
print x,y,z
which could, of course, be cleaned up and put in a class or two.
NeilBrown
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
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
Re: Accelerometer Data
On Monday March 23, ifindle...@videotron.ca wrote: 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: They seem to move around a bit.. debian-gta02:/tmp# find /sys | grep thresh /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/threshold /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/wakeup_threshold /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.1/threshold /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.1/wakeup_threshold or debian-gta02:/tmp# p=*; while [ `eval echo /sys/$p/threshold` = /sys/$p/threshold ]; do p=$p/* ; done ; echo /sys/$p/threshold /sys/bus/spi/devices/spi3.0/threshold /sys/bus/spi/devices/spi3.1/threshold So look under /sys/bus/spi/devices/spi3.x I wonder what 'spi' means... NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
On Monday 23 March 2009, Neil Brown wrote: So look under /sys/bus/spi/devices/spi3.x I wonder what 'spi' means... Serial Peripheral Interface, a common bus for connecting microprocessors to accelerometers and suchlike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
On Tue, Mar 24, 2009 at 09:24:09AM +1100, Neil Brown wrote: if type == 3: if code == 0: x = value if code == 1: y = value if code == 2: z = value Or if type == 2 or type == 3: ... then it would work on both old and new kernels. Shouldn't if (type == EV_SYN) do that? Of course maybe the program would require being recompiled for the corresponding system version it is going to run... Rui -- Frink! Today is Boomtime, the 9th day of Discord in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Back to the Basics plan: Andy left
Dear List, I can't express how sad I'm when I read Andy Green left Openmoko. I do not know why he left (and it is not my business anyway), but I know since Andy was at Openmoko the kernel side began to form shape, and got things work. (suspend? anyone?) I know that every people is replacable at a company, but show me at least two people who made as much commit/day (and code quality) what Andy did. You cant, because there is no black magic here, no marketing mantra, it is all public and we can see who commits what into the git tree. So you just let go the single most valuable people at kernel side. Nice try. I do not know who is responsible for this desicion but I hope they are not the same design team who had fired Rasterman. Oh, and Harald Welte had left Openmoko too, but we never knew the exact details. Who left? At the hardware side: Werner and Joerg at the software side: Mirko and hmm, nobody? Im counting... How long will they stand? If I had enough money I would just hire those people and form a new company and outsource the fabrication to a chinese company (that's exactly what everyone does including apple) and forget about Openmoko (the name was a bad choice anyway ;) I know this letter a bit harsh, but it is intented to address to whom is concerned: Get your head out of your @ss, sit down and think about a bit. You must honor those people who gets the job done! The best would be just hire back those valueable people, and work out how they want to work. Even if they want to form a new (software) company, to make sure this situation will never happen again. I always wanted to buy the next model of openmoko, but I know exactly, if it has bugs (and surely it will), never or really slowly will be fixed (as the current(=everyone gets fired) situation shows). And if it will have hardware bugs, they will be never fixed by Openmoko (as the company), and I can just hope that some people offer *their free time and knowledge* and fix the problem UNOFFICIALLY (unless they did not get until fired). Can you imagine where we were today without Andy and Rasterman? I surely can: an unofficial/unsupported qtextended with an unoptimized 2.6.22 kernel. All those nice things came from these (fired) people. I'm afraid of the future. Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
question about kernel image build
i got a freerunner, first i download the two image:
Om2008.12-om-gta02.uImage.bin
Om2008.12-om-gta02.rootfs.jffs2
use the dfu tools upgrade success.
but i want to build the kernel image myself, so i do like this:
1.
install git tools: apt-get install git
2.
git clone git://git.openmoko.org/git/kernel.git linux-2.6
3.
cd linux-2.6
git checkout origin/andy-tracking
4.
cp arch/arm/configs/gta02-moredrivers-defconfig .config
5.
download openmoko-i686-20080916-arm-linux-gnueabi-toolchain.tar.bz2 from
http://downloads.openmoko.org/developer/toolchains/
6.
cd /
sudo tar jxf /openmoko-i686-20080916-arm-linux-gnueabi-toolchain.tar.bz2
7.
cd linux-2.6
mkdir GTA02
cp arch/arm/configs/gta02-moredrivers-defconfig ./GTA02/.config
8.
vi /usr/local/openmoko/arm/setup-env
modify line with : export
LDFLAGS=-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -rpath-link
${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -O1
9.
. /usr/local/openmoko/arm/setup-env
10.
cd linux-2.6/
./build GTA02 dummy
after above, i use the dfu tools burn the uImage-GTA02.bin which under GTA02
directory to freerunner, but it
stop at openmoko srceen, can't boot the system up,
why?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the Basics plan: Andy left
Laszlo KREKACS wrote: I can't express how sad I'm when I read Andy Green left Openmoko. I do not know why he left (and it is not my business anyway), but I know since Andy was at Openmoko the kernel side began to form shape, and got things work. (suspend? anyone?) You should have stopped here IMHO. It really is none of our (community's) business, and it would be a lot more productive to just focus on the question of where do we go from here? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the Basics plan: Andy left
On Tue, March 24, 2009 2:03 pm, Mike Montour wrote: Laszlo KREKACS wrote: I can't express how sad I'm when I read Andy Green left Openmoko. I do not know why he left (and it is not my business anyway), but I know since Andy was at Openmoko the kernel side began to form shape, and got things work. (suspend? anyone?) You should have stopped here IMHO. It really is none of our (community's) business, and it would be a lot more productive to just focus on the question of where do we go from here? I have to say that I think the answer to that is up stream. Code doesn't have to be completely working before it goes into the upstream kernel. Just supported and useful are often enough. I understand that there is work underway to get some of the openmoko kernel code upstream. I think that should be a major focus. Once it is all in, then work can go back to enhancing and bug fixing. It would be awesome if mainline-2.6.30 or even 2.6.31 would run on the Freerunner unchanged! When it is all in mainline, it is a lot easier for more people to contribute. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
