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

[H. Nikolaus Schaller]

> Am 10.05.2019 um 10:57 schrieb Bastien Nocera <hadess@xxxxxxxxxx>:
> 
> On Mon, 2019-04-22 at 15:20 +0100, Jonathan Cameron wrote:
>>> 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