Re: [RFC v2] iio: input-bridge: optionally bridge iio acceleometers to create a /dev/input interface
From: H. Nikolaus Schaller
Date: Fri May 10 2019 - 05:35:19 EST
> 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
>> 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
>> here is they will now discover 'both' without the existing userspace
>> knowing that they are the same device. We need to be very careful
>> to break those userspace programs.
>> So this is an illustration of why the simplistic case doesn't work
> 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"
Event type 0 (EV_SYN)
Event type 3 (EV_ABS)
Event code 0 (ABS_X)
Event code 1 (ABS_Y)
Event code 2 (ABS_Z)