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.
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
