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.

I take from this discussion that the input subsystem would make more
sense for the "Biometric: Human Presence" usage.

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.

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/
>