No subject

get an estimate of speed, or double-integrate to get position would
have an expected error that would get very large very quickly.

If some application wanted to try to do that, the best that the kernel
can do to help is keep out of the way and simply deliver events at the
full 400Hz.  Certainly that will be an option.

But I think that the most useful information that you can get from the
accelerometers is attitude (which direction is 'down') and 'jerks'
(aka sudden changes in acceleration) such as taps and various other
gestures. 

To measure attitude, you just want to poll the accelerometers
occasionally.  1 or 2 HZ is probably plenty.  Certainly 100Hz is
overkill.  That is the point of making a low sample-rate meaningful.

To measure 'jerks' and related gestures, you want to know about
significant changes to acceleration.  That is where the 'threshold'
value comes in.

So a moderate sample_rate (between 0.5Hz and 5Hz) combined with a moderate
threshold (probably around 500mg) would provide you with all the
information needed to detect attitude and gestures without
interrupting the CPU at 100Hz.

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

Yes.

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

There is?
Maybe you mean event0 and event4 which both report EV_KEY events, one
for the POWER button and one for the Aux and mic-mute buttons plus
the headset-present switch.

Are you suggesting that the tap events go out one of these?
Apart from any (debatable) "ugliness" factor of this, we would need 6
different KEY_ or BTN_ values if we ever wanted to differentiate taps
on the different accelerometers.

If there was just one event device for all of the keys and
switches, then you might have a case.  But as there are two, it seems
hard to justify not adding a third and fourth for distinctly different
forms of input...

And then there is the fact that it would be really nice if this driver
were sufficiently generic that it could be used by a totally different
device had that same accelerometers... Mixing into a common keyboard
event stream doesn't seem to mesh well with that.

We could possibly leave creating the 'tap' event device until taps
were actually requested.  That would help with the
backwards-compatibility issues...

Thanks for your thoughts,
NeilBrown