At least some of the time, an accelerometer is more like part of a
joystick. You can have phones with accelerometers at both ends, where the
input events produced depend on the combination of the readings, with each
of the individual accelerometers being a device that is also available by
itself. You can have phones which can be used in various orientations,
where the logical "left" direction depends on the orientation. With a
joystick, the device that the driver is for has the assignment of motions
to inputs; for an accelerometer in a phone, the assignment is outside the
scope of the chip, and it would make sense to have a second driver that
takes non-chip-specific accelerometer output (per-accelerometer, per-axis)
and maps it to input events based on how the user holds the box the chip
is in.
It's like having a whole bunch of button devices; you want them to be
exposed as a keyboard, and the sensor hardware reports press and release,
but something else is needed to know which hardware button is which key.
Similarly, you want to know about how the user is moving the device, and
you may need to process various sorts of raw data to produce anything
meaningful to applications.
-Daniel
*This .sig left intentionally blank*
--
