> 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
