On Sun, 26 Nov 2023 11:59:05 +0100
Philipp Jungkamp <p.jungkamp@???> wrote:

> Hi,
>
> would it make sense to move the HID human presence driver at
> drivers/iio/light/hid-sensor-prox.c to the input system then? This
> driver only checks for the "Biometric" (0x2004b0) and "Biometric: Human
> Presence" (0x2004b1) HID usages. The former has a vendor defined value
> range, the latter is defined as a boolean switch. See the HID Usage
> Tables, section 21.1 and 21.6.

These boundaries always get messy. Given there is a value range, it
might get used for something else.
>
> I take from this discussion that the input subsystem would make more
> sense for the "Biometric: Human Presence" usage.

Potentially yes
>
> I just wanted to chime in as there seems to be some older precedent for
> a binary sensor in the iio subsystem. I tried to get that sensor
> working for the proximity sensor on my laptop last year.

I guess this one landed because it looked much like the hid light sensors
and no one raised the question at the time (that I recall).

Probably not worth moving it, but we may well have suggested putting
it in input if we'd noticed at the time!

Jonathan

>
> Regards,
> Philipp Jungkamp
>
> On Sat, 2023-11-25 at 22:33 -0600, Jeff LaBundy wrote:
> > Hi Sicelo and David,
> >
> > On Sat, Nov 18, 2023 at 06:09:18PM -0600, David Lechner wrote:
> > > On Fri, Nov 17, 2023 at 12:22 PM Sicelo <absicsz@???> wrote:
> > > >
> > > > Hi
> > > >
> > > > Some phones have 1-bit proximity sensors, which simply toggle a
> > > > GPIO
> > > > line to indicate that an object is near or far. Thresholds are
> > > > set at
> > > > hardware level. One such sensor is OSRAM SFH 7741 [1], which is
> > > > used on
> > > > the Nokia N900.
> > > >
> > > > It is currently exported over evdev, emitting the
> > > > SW_FRONT_PROXIMITY key
> > > > code [2].
> > > >
> > > > So the question is: should a new, general purpose iio-gpio driver
> > > > be
> > > > written, that would switch such a proximity sensor to the iio
> > > > framework?
> > > > Or evdev is really the best place to support it?
> > > >
> > > > There are a couple of people who are willing to write such an iio
> > > > driver, if iio is the way to go.
> > > >
> > > > Regards,
> > > > Sicelo
> > > >
> > > > [1]
> > > > https://media.digikey.com/pdf/Data%20Sheets/Osram%20PDFs/SFH_7741.pdf
> > > > [2]
> > > > https://elixir.bootlin.com/linux/v6.6.1/source/arch/arm/boot/dts/ti/omap/omap3-n900.dts#L111
> > > >
> > > Since this is really a proximity switch (it is either on or off)
> > > rather than measuring a proximity value over a continuous range, it
> > > doesn't seem like a good fit for the iio subsystem. If the sensor
> > > is
> > > on a phone, then it is likely to detect human presence so the input
> > > subsystem does seem like the right one for that application.
> > >
> > > More at
> > > https://www.kernel.org/doc/html/latest/driver-api/iio/intro.html
> > >
> >
> > I tend to agree; if there are only two discrete states as is the case
> > for a
> > GPIO, then this is technically a switch and not a sensor. Therefore,
> > input
> > seems like a better fit; that is just my $.02.
> >
> > FWIW, a similar discussion came up a few years ago in [1] and again
> > the key
> > differentiator was whether the output is discrete or continuous.
> >
> > Kind regards,
> > Jeff LaBundy
> >
> > [1]
> > https://lore.kernel.org/linux-iio/9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com/
> >
>