Re: proximity sensor, input

[Jonathan Cameron <jic23@cam.ac.uk>]

On 4/10/2012 10:47 AM, Peter Meerwald wrote:
> Hello,
>
> I am wondering how to support proximity sensors; goal is to trigger some
> application event when an object comes close (in that sense, the proximity
> sensor is used like a button)
>
> there are several places in the kernel doing similar things:
> e.g. input/misc/gp2ap0002a00f.c
> e.g. drivers/misc/bh1770glc.c
> e.g. drivers/staging/iio/isl29018.c
>
> iio seems to be most active and has IIO_PROXIMITY, but I do not see how
> the application is easily notified: iio collects merely collects the
> sensor data
Not true. IIO has a reasonably well developed event interface iff the 
hardware supports
it.  There is no support for simulating a hardware detector in kernel in 
a generic sense.
I'd not be anti an implementation of this though.  It would sit as an 
additional buffer
implementation (similar to that use for the input bridge - see below) 
and do simple
calculations / comparisons - then providing iio events when conditions 
are passed etc.
Could be rather cute actually ;)  Tricky bit would be delinking it as 
far as possible from
the individual drivers.  Could do it completely separately...
(i.e. have another iio device that is a child of the original and has only
events rather than raw access etc).
>
> drivers in misc just create some custom sysfs interface
Agreed. That option is bad!
>
> input/misc has just one driver dealing with proximity
>
> is there some advise where proximity driver support might best fit?
Whilst the application you have (and some devices) are used simply as 
buttons
this isn't always the case and as you are considering writing a driver 
that others
will hopefully use, keep that in mind.  If you don't mind me asking what 
device
are you using?

If all it does is an interrupt (and no raw data access) then input is 
probably the
best choice.  If it will be used for things other than human input, then IIO
is worth considering.  Note we have work in progress to bridge from iio 
devices
across to input, but the gaping hole there at the moment is this doesn't 
include
threshold type events (what we consider events in IIO doesn't include normal
data flow).  Its on the todo list (in my head :)
>
> thanks, regards, p.
>