Date:   Sun, 24 Mar 2019 18:29:30 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     letux-kernel@...nphoenux.org, kernel@...a-handheld.com,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org
Subject: Re: [RFC 0/4] iio-input-bridge so that accelerometers which only
 have an iio driver can still present evdev input events

On Mon, 18 Mar 2019 21:39:30 +0100
"H. Nikolaus Schaller" <hns@...delico.com> wrote:

	
> Some user spaces (e.g. some Android) use /dev/input/event* for handling the 3D
> position of the device with respect to the center of gravity (earth). This can
> be used for gaming input, rotation of screens etc.
> 
> This should be the standard because this interface is an abstraction of how
> this data is acquired from sensor chips. Sensor chips may be connected through
> different interfaces and in different positions. They may also have different
> parameters. And, if a chip is replaced by a different one, the values reported
> by the device position interface should remain the same.
> 
> But nowadays, new accelerometer chips usually just get iio drivers and rarely
> an evdev input driver.
> 
> Therefore we need something like a protocol stack: input device vs. raw data.
> It can be seen as a similar layering like TCP/IP vs. bare Ethernet. Or keyboard
> input events vs. raw gpio or raw USB access.
> 
> This patch set bridges the gap between raw iio data and the input device abstraction
> so that accelerometer measurements can also be presented as X/Y/Z accelerometer
> channels (INPUT_PROP_ACCELEROMETER) through /dev/input/event*.
> 
Hi,

I've kind of run out of time today and want to give this a detailed look.

In the meantime a few initial comments.

1. Resend the whole series cc'ing the linux-input list and maintainer.
2. In the vast majority of devices the interrupt pin is connected for an
   accelerometer. and they support data ready signals.  My gut feeling is
   that should be the preferred mode.  It was for that use case that we originally
   put all the demux and multiple buffer code in IIO. The original series for
   that actually had an input bridge.
https://lore.kernel.org/linux-iio/1351679431-7963-5-git-send-email-jic23@kernel.org/

3. It's going to be a hard sell to have it 'always' map an accelerometer in IIO
   to an input device when configured.  There are lots of other accelerometer use
   cases where this would be crazy.  In the repost, give some comentary perhaps on
   the following options:
   a) Explicit binding - like the iio-hwmon bridge.
   b) A userspace bridge (I even wrote one of those years ago using uevent)
   c) Some sort of userspace triggered way of creating these on demand.

4. Input has polled modes. Don't reinvent them.

5. The patch break up is very very random.  Just have one patch :)

Anyhow, I'll take a look in detail but may be a little while.

Thanks,

Jonathan


> 
> H. Nikolaus Schaller (4):
>   iio: input-bridge: optionally bridge iio acceleometers to create a
>     /dev/input
>   iio: input-bridge: add iio-input-bridge to Makefile
>   iio: input-bridge: add IIO_INPUT_BRIDGE kernel config option
>   iio: input-bridge: make the iio-input-bridge driver called by iio-core
> 
>  drivers/iio/Kconfig                    |   7 +
>  drivers/iio/Makefile                   |   1 +
>  drivers/iio/industrialio-core.c        |  12 +
>  drivers/iio/industrialio-inputbridge.c | 420 +++++++++++++++++++++++++
>  drivers/iio/industrialio-inputbridge.h |  28 ++
>  5 files changed, 468 insertions(+)
>  create mode 100644 drivers/iio/industrialio-inputbridge.c
>  create mode 100644 drivers/iio/industrialio-inputbridge.h
> 

Powered by blists - more mailing lists