Hi folks,
I am working on a driver for the Kionix KXTF9 accelerometer. This is a
fairly close relative of the KXTJ9 that Chris Hudson has been iterating
in linux-input. Unfortunately I missed his driver when getting started,
so I now have a fairly-complete IIO-based implementation instead.
As the KXTJ9 input driver has had more review, it makes sense for me to
backtrack and build on that one. My proposal is to work on generalizing
the driver enough to also support the KXTF9, and coordinate with Chris
Hudson to avoid breaking his improvements.
While the I2C interfaces are fairly similar, the KXTF9 (and newer KXTI9)
have more on-chip processing and a variety of added features. These
include things like taps and coarse orientation, which I am not sure how
to report in an upstream-friendly way. Any advice would be appreciated:
Tap: Single and double taps in six directions. The only example I can
find is the ADXL34 driver, which seems to just report BTN_TOUCH for any
tap (unless changed in platform data).
Tilt: Coarse orientation in six directions (face up, face down, left up,
right up, top up, bottom up). Saw some discussion about this, but wasn't
sure if there was agreement on how to report these events in a useful
fashion.
Motion: Yes/no binary state.
Sampling Rate: KXTJ9 driver is using delay in ms to drive both
interrupt-based and polling-based cases. Since the sysfs interfaces are
string-based, am wondering if decimal Hz would be more intuitive. These
would be converted to fixed-point in-kernel. Since there are five or six
different rates to adjust, they needs to be easy to understand.
Timing Parameters: The tap/tilt/motion sensing is configured via a large
number of user-configurable parameters. My thought for these is to
expose them in sysfs as decimal numbers of seconds. I believe the actual
values set on the chip need to change with the associated sampling rates.
Axis Parameters: Many of the modes need to be configured with a mask of
directions (+x -x +y -y +z -z). Six sysfs attributes for each seems
excessive and a bitmask feels error-prone. I wouldn't be averse to using
a list of strings if that is acceptable (e.g. "x z" or "up down left
forward"). Any other alternatives?
Thanks,
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
