Event types

[Jonathan Cameron <jic23@cam.ac.uk>]

Hi All,

We are in the process of cleaning up the event subsystem of IIO.
As some devices will be used via an input bridge, it makes sense
to pin down what they would be translated to in input. Note our
'readings' that will map to events in input are handled via a
different patch. There are plenty of drivers to suggest what those
should map to. We can basically pretend these devices are joysticks
with several xyz controllers.

For the sort of direct 'input' types of events - double tap etc
we can just copy existing drivers.

Much more common for us though are controllable threshold events.
In IIO the associated control attributes are named:

Like <channel>_<limit>_<dir>_<attr>, where
 <channel>: name of the channel, i.e. accel_x0
 <limit>:   thresh, mag, roc
 <dir>:     rising, falling
 <attr>:    en, value, period, mean_period 

So taking a typical device (adis16400) we have the following
actual events

in_supply_thresh_rising
in_supply_thresh_falling
in_supply_roc_rising
in_supply_roc_falling

accel_[x|y|z]_thresh_rising
accel_[x|y|z]_thresh_falling
accel_[x|y|z]_roc_rising
accel_[x|y|z]_roc_falling

gyro_[x|y|z]_thresh_rising
gyro_[x|y|z]_thresh_falling
gyro_[x|y|z]_roc_rising
gyro_[x|y|z]_roc_falling

magn_[x|y|z]_thresh_rising
magn_[x|y|z]_thresh_falling
magn_[x|y|z]_roc_rising
magn_[x|y|z]_roc_falling

temp_thresh_rising
temp_thresh_falling
temp_roc_rising
temp_roc_falling

in0_thresh_rising
in0_thresh_falling
in0_roc_rising
in0_roc_falling

The _mag_ events are for devices (often accelerometers) which provide an
interrupt based on the magnitude not the signed value of the relevant channel.

Note a typical event only has a value attached to it in the sense that we know
what barrier is crossed.

So what would such general events map to?  I suppose in some senses they are EV_KEYs
but which keys?  The only example I have seen is the adxl34x. That uses btn_touch for
tap events and pdata to specify keys for freefall, orientation and activity.

In our case I guess the mapping can be provided to the userspace bridge daemon to
translate all these events into 'magic' keys. Is this the best plan?
A few clearly don't conventionally make much sense in input (temperature and supply
voltages would be unusual human interfaces!).

All thoughts on this welcomed.

Thanks,

Jonathan