Possible incompatible change in behaviour of accelerometers - EV_ABS rather than EV_REL - and other thoughts.
andy at openmoko.com
Tue Mar 10 08:14:07 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| Hello fellow developers.
| I have be turning my attention to the accelerometers in the Freerunner
| recently, and I would like to make a number of improvements.
| I'll give a bit of an overview below for those who are interested, but
| the main point of the email is to let you know about a change which
| I very much hope will go through and will require most applications
| which use the accelerometers to be changed, though it will probably be
| a very minor change.
Apologies for this late change.
| If the value were below 50 I would disable that interrupt and use
| a kernel timer to sample the values at the desired rate.
Don't you have to capture everything that's going inbetween samples and
| It would be best to create new /dev/input/event* devices for these
| so an app that wants them doesn't have to be woken by all the
| noise of ABS_* events. However creating new event devices would
| renumber some existing one which would break any app which relies
| on hard codes paths (we really should have e.g. /dev/input/AUX and
| I'm not sure what I'll do about this just yet.
As I mentioned on the kernel list you have to take care about interrupt
routing vs PCB revision and so modality of tap vs capture.
There's a "keyboard" input device already existing that could take these
tap events easily. You'd have to pass a pointer to the keyboard input
event device in through platform data from the mach-gta02.c.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the devel