Handling of non-positional data through evdev

[Roderick Colenbrander <thunderbird2k@gmail.com>]

Hi all,

I'm working on a device driver for an input device, which has both
directional axes in addition to sensors (accelerometer and gyro). I'm
trying to figure out how to map these axes properly, but I'm stumbling
on some road blocks. Directional axes should be mapped to e.g.
ABS_X/_Y/_Z, while relative axes make most sense for sensors. The main
issue I'm seeing is that there is no way to determine using evdev what
type of data is exposed on an axis.

Based on definitions in input.h, it seems traditionally ABS_X/_Y/_Z
had a resolution of 'units per millimeter', while ABS_RX/_RY/_RZ where
meant for rotational axes in 'units per radian'. Over the years
handling of these axes evolved, where gamepads often use
ABS_RX/_RY/_RZ for the right stick, which is 'units per millimeter'.

In a similar way some drivers are currently reporting acceleration
through absolute axes (e.g. wii driver). The application has to know
it is dealing with the wii gamepad to be able to really understand the
data. Then there is also a special flag 'INPUT_PROP_ACCELEROMETER'
which some drivers use to report acceleration data through absolute /
relative axes provided the device doesn't report any directional axes
on that same node.

As I have shown, handling of non-positional data is sort of handled
now on a case by case basis. As an application developer you pretty
much have to check the product/vendor IDs to really be able to handle
a device. You can't just rely on detecting the type of axes. Moving
forward I would like to determine what the best way of handling
non-positional data is through evdev.

In my opinion the main problem of the current API is that there is no
way to determine what 'unit' is reported on an axes. Is it positional
data, is it (angular) velocity, is it acceleration, something else?
Ideally I think there should have been some 'type' field in
'input_absinfo', which allowed someone to determine the data type and
e.g. map a resolution of '1024' units to 1G of acceleration or a
certain number of radians per second. Unfortunately user space can't
be broken, but potentially a new ioctl could be invented to add such
information (if that's the way forward) returning e.g.
'input_relinfo'. Another option is to add a new axis type.

What are your thoughts on this matter? Ideally I would like to find a
nice solution if possible.

Thanks,
Roderick