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

[H. Nikolaus Schaller]

Hi Jonathan,
sorry again for the long delay. I just now found a little time to summarize and try to
get the discussion boiled down to the key difference.

> Am 11.05.2019 um 13:05 schrieb Jonathan Cameron <jic23 at kernel.org>:
> 
> On Thu, 9 May 2019 19:02:49 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> 
>> If you close the lid, the display is turned upside down and y and z axes reverse sign.
>> 
>> So there remains only the issue that user-space must know which sensor device file is which sensor
>> and can do the calculation of the lid angle. This is possible because the iio accelerometer name
>> is available through the input event ioctls.
>> 
>> In summary this case also does not need policy or configuration. Just user space using the information
>> that is already presented.
> 
> I disagree with that last statement.  If there is a lid angle sensor, policy is
> needed to know which of your associated orientation is the base one and which
> device indicates the lid angle.
> 
> Actually most of the time what you will do is pick one 'correct' sensor under
> some configuration of the device and use that.  That is policy.  Yes, you could
> bake the policy in to device tree, but then you can also bake in the association
> between the underlying IIO sensor and any virtual input sensor.

Ah, maybe I did not understand what you mean by policy here.

Indeed, choosing the right sensor is always something which is application specific
and something user-space must obviously dictate. And we agree this should *not* be
in device tree (or user-space scanning device tree) because that describes hardware
and not user-space interaction.

But I still do not think that this requires a new mechanism where user-space
*tells* the kernel which sensor to use and present as which device.

Equally well, the kernel can present all sensors it knows about and a set of properties
that allow the user-space to simply choose the right one ("apply policy"). Properties
could be file name (e.g. provided by udev), device name, label (provided by DT) or similar.

If it were absolutely necessary to tell the kernel to map iio devices to something before
use, I think Bastien would not have been able to implement his library. He also has to
choose the right sensors. This seems to work and not need a new mechanism.

> 
> Anyhow, we still disagree on whether any such virtual input interface
> should be a userspace policy decision.  So far I haven't seen any compelling
> argument why it shouldn't be and the flexibility such a policy based interface
> provides is its major advantage.

I still think it is not needed because kernel already provides necessary information
to user-space to make policy decisions (by ignore unwanted interfaces) without needing
a new interface where the user-space tells the kernel to activate some interfaces.

So the key difference is about the question if user-space needs to tell the kernel first
that it wants to see a specific interface or just makes use of it if present.

BR and thanks,
Nikolaus