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
to share.
Jonathan
>
> BR and thanks,
> Nikolaus
>
