proximity sensor, input

proximity sensor, input

[Peter Meerwald]

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

drivers in misc just create some custom sysfs interface

input/misc has just one driver dealing with proximity

is there some advise where proximity driver support might best fit?

thanks, regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)

Re: proximity sensor, input

[Shubhrajyoti Datta]

Hi Peter,

Can you explain more about how your proximity device is?
How does it report through gpio / irq etc ?

Thanks,
Shubhro



On Tue, Apr 10, 2012 at 3:17 PM, Peter Meerwald <pmeerw@pmeerw.net> 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 proximit=
y
> 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
>
> drivers in misc just create some custom sysfs interface
>
> input/misc has just one driver dealing with proximity
>
> is there some advise where proximity driver support might best fit?
>
> thanks, regards, p.
>
> --
>
> Peter Meerwald
> +43-664-2444418 (mobile)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html

Re: proximity sensor, input

[Jonathan Cameron]

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

Re: proximity sensor, input

[Peter Meerwald]

Hello,

thank you for your comments!

> 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).

agree; there might be three conceptual layers:
(1) sensor data acquisition
(2) data aggregation / processing / thresholding
(3) (input) event generation

I can see iio fulfill (1); (2) might be difficult to do in a 
sensor-independant way; (3) should be easy

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

I'm looking at two different sensors (for different purposes); a VCNL4000 
and a Si1143: the former is simplistic (ALS+proximity, no interrupt, has 
to be polled), the latter should allow fancy HCI and ALS (i.e. three IR 
leds that should allow to estimate the positition/direction of a nearby 
object -- so one should be able to distinguish contactless swipe gestures 
etc.)

both are I2C and I'm using a beagleboard as dev platform

> 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 :)

can you please point me to that work on bridging iio and input layer?

thank you for your guideline!

regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)

Re: proximity sensor, input

[Jonathan Cameron]

On 4/10/2012 12:24 PM, Peter Meerwald wrote:
> Hello,
>
> thank you for your comments!
>
>> 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).
> agree; there might be three conceptual layers:
> (1) sensor data acquisition
> (2) data aggregation / processing / thresholding
> (3) (input) event generation
>
> I can see iio fulfill (1); (2) might be difficult to do in a
> sensor-independant way;
Does it need to be in kernel?  I can think of cute ways of doing it 
there, but maybe
a stream of data to userspace then use uinput to push back events into 
the kernel
would do the job for you?
>   (3) should be easy
>
>>> 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?
> I'm looking at two different sensors (for different purposes); a VCNL4000
> and a Si1143: the former is simplistic (ALS+proximity, no interrupt, has
> to be polled), the latter should allow fancy HCI and ALS (i.e. three IR
> leds that should allow to estimate the positition/direction of a nearby
> object -- so one should be able to distinguish contactless swipe gestures
> etc.)
In both cases you have an ALS there, so you could do a multifunction 
driver but not everything
is going to fit into input.
>
> both are I2C and I'm using a beagleboard as dev platform
>
>> 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 :)
> can you please point me to that work on bridging iio and input layer?
err. I'm being a bit slow on posting a current version of that work.
Last version I sent out was:
http://marc.info/?l=linux-iio&m=133077653302884&w=2 
<http://marc.info/?l=linux-iio&m=133077653302884&w=2>
>
> thank you for your guideline!
>
> regards, p.
>