Re: [Letux-kernel] [RFC v2] iio: input-bridge: optionally bridge iio acceleometers to create a /dev/input interface
From: Jonathan Cameron
Date: Sat Jun 08 2019 - 06:56:46 EST
On Mon, 3 Jun 2019 09:30:40 +0200
H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> 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@xxxxxxxxxx>:
> > On Thu, 9 May 2019 19:02:49 +0200
> > "H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx> 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
> BR and thanks,