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

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 3 Jun 2019 09:30:40 +0200
H. Nikolaus Schaller <hns@goldelico.com> wrote:

> 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@kernel.org>:
> > 
> > On Thu, 9 May 2019 19:02:49 +0200
> > "H. Nikolaus Schaller" <hns@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.

Absolutely. Good summary, but I don't think either of us is going
to persuade the other.

I've started work on my proposal but things have been 'interesting' in the
last few weeks so it may be a little while yet before I have anything
to share.

Jonathan

> 
> BR and thanks,
> Nikolaus
>