Possible incompatible change in behaviour of accelerometers - EV_ABS rather than EV_REL - and other thoughts.

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

|     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
|     /dev/input/accel{0,1}).
|     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.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkm2Ez8ACgkQOjLpvpq7dMqTAACcCYhi1aH0zFoFeVnnUpeDPkYI
nWEAmgMVDtXSt3iKnSmWpNHEopz8nFiC
=XXsx
-----END PGP SIGNATURE-----