Am 10.05.2019 um 10:57 schrieb Bastien Nocera [off-list ref]:

On Mon, 2019-04-22 at 15:20 +0100, Jonathan Cameron wrote:

quoted

quoted

Different goals usually lead to different solution architectures.

Indeed, but in this case we have your proposal which is a subset of
what
I am suggesting.  One architecture can fulfil both requirements.

I'll leave it for the other thread, but Bastien has raised the case
(that I'd forgotten) that there already userspace stacks that are
capable of happily taking in both IIO and Input devices.  The
confusion
here is they will now discover 'both' without the existing userspace
knowing that they are the same device.  We need to be very careful
not
to break those userspace programs.

So this is an illustration of why the simplistic case doesn't work
'now'.

I don't know what state the whole patch is, but, at the very least, I'd
expect that patch to export the fact that it's exporting synthesised
data from another driver, so that it can be easily ignored in user-
space that already supports IIO devices.

It does through "Input device name:" starting with "iio-bridge:" as you can see in the commit message of [RFC v3]:

root@letux:~# evtest /dev/input/event5 | head -19
Input driver version is 1.0.1
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "iio-bridge: bmc150_accel"
Supported events:
  Event type 0 (EV_SYN)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value      8
      Min     -511
      Max      511
    Event code 1 (ABS_Y)
      Value    -44
      Min     -511
      Max      511
    Event code 2 (ABS_Z)
      Value   -265
      Min     -511
      Max      511