On Mon, 3 Jun 2019 09:30:40 +0200
H. Nikolaus Schaller <h...@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 <ji...@kernel.org>:
> >
> > On Thu, 9 May 2019 19:02:49 +0200
> > "H. Nikolaus Schaller" <h...@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
>
