Re: proximity sensor, input

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

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