[Letux-kernel] [RFC v2] iio: input-bridge: optionally bridge iio acceleometers to create a /dev/input interface

H. Nikolaus Schaller hns at goldelico.com
Mon Apr 15 23:04:36 CEST 2019

Hi Roderick,

> Am 14.04.2019 um 18:26 schrieb Roderick Colenbrander <thunderbird2k at gmail.com>:
> Hi Jonathan and Nikolaus,
> I would like to jump into this discussion a bit as well. Might be
> slightly off topic or not... I'm not too familiar with the details of
> IIO, but as Sony we do report accelerometer / gyroscope data through
> /dev/input for our DualShock devices through hid-sony. This is among
> reasons done for Android, which Nikolaus showed interest in as well.

Yes, some of our devices have Replicant support which was the main trigger
to work on it.

> We are working on exposing this data through user space through
> standard Android APIs (see,
> https://android-review.googlesource.com/c/platform/hardware/libhardware/+/571762/).
> The work will likely be merged later this year and it is already used
> in some devices. Main reason it wasn't merged yet it that in our case
> we have multiple evdev devices (gamepad, touchpad, motion sensors) and
> need to tie those together for applications. Android doesn't support a
> good mechanism for that yet.
> Since the IIO input work relates to our Android work as well, I will
> jump in more from the sidelines to make sure things are done in a
> consistent manner. The main concern are resolution and value ranges.

as far as I understand the Android architecture, there are two approaches.

One is to read /dev/input/event devices data like you do and the other one is
to read the data through iio. It can be roughly compared with reading and
generating raw IP packets vs. using UDP packets. Both basically contain the same
information but have different headers and APIs. And UDP uses IP internally,
so using IP directly is less abstracted and duplicates kernel code in user-space.

This is what the layered protocol stack does.
Here, I see a "protocol" stack like:

	L3: input
	L2: iio
	L1: i2c, spi, usb, hdq, ...
	L0: chips, ...

User-space could read data on every level (you could access the chips directly
through e.g. i2c) but it is easiest to use the highest level because most
transformations have already been done and run at much better performance in-kernel.
And the abstraction of implementation details from L1 to L3 is done once for all.

>>> We need to apply some scale since iio reports in (fractional) units of 1g, i.e. values
>>> of magnitude 1.
>> m/s^2 not g, but doesn't matter for the point of view of this discussion.
> m/s^2 is conceptually right, but others have been using 'g' for input,
> so I would consider that the standard now. Also leaves handling of
> location on Earth to user space instead of assuming a fixed conversion
> to 9.81 m/s^2.

Yes, this is how I see it as well. "input accelerometer" has a specific
purpose. So it should use domain-specific units. While iio provides physical
data which obviously uses general physical units.

So one of the tasks of L3 driver is to scale that between the domains.

>>> These are not adaequate for input events which use integers. So we must
>>> define some factor for iio_convert_raw_to_processed() to scale from raw value range
>>> to int value range. We could report raw values but this would be an improper abstraction
>>> from chip specific differences.
>> Hmm. I can see we perhaps need some mapping, but is there a concept of standard scale
>> for existing input accelerometers?  How is this done to give for other input devices
>> such as touch screens?  I'd expect to see a separation between scale, and range.
> We at the time were one of the first to expose acceleration and gyro
> data through /dev/input for DualShock 4 as supported by hid-sony. We
> report acceleration in 'g' and angular velocity in 'degree / s'. We
> set the resolution to respectively '1 g' and '1 degree / s'. The range
> we set to the range of the device e.g. for DS4 -4g to +4g for
> acceleration. I need to check though what coordinate system we use,
> but I think it is right handed (gyro counter clockwise relative to
> acceleration axes).

This would be good test-case to check if the whole mount-matrix thing has
the correct coordinate orientation.

> The two other drivers using INPUT_PROC_ACCELEROMETER are hid-wacom and
> hid-udraw-ps3 Wacom. Both seem to report resolution in 'g'  as well.

There is also for example drivers/input/misc/bma150.c which IMHO also
reports "g".

> Thanks,
> Roderick

BR and thanks,

More information about the Letux-kernel mailing list