From: Jonathan Cameron <jic23@kernel.org>
To: Matt Ranostay <mranostay@gmail.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Hartmut Knaack <knaack.h@gmx.de>,
Peter Meerwald <pmeerw@pmeerw.net>
Subject: Re: IIO_GESTURE proposal
Date: Tue, 02 Jun 2015 19:28:40 +0100 [thread overview]
Message-ID: <556DF5D8.9080000@kernel.org> (raw)
In-Reply-To: <CAKzfze8qX0WEKmHgBKKVvw-=mzFOUVSQnOXXxjUPdm=BafoYqA@mail.gmail.com>
On 02/06/15 05:35, Matt Ranostay wrote:
> Jonathan,
>
> So I am currently planning on implementing a driver for the Avago
> APDS-9960 that has the typical ALS, RGBC, and proximity sensor
> components. But this part has a gesture function that uses 4 IR
> photodiodes aligned in a grid of UP-DOWN-LEFT-RIGHT that detect IR
> light reflection off an object, and in turn reports back the direction
> a hand or similar would make over the sensor.
>
> Now the data that is reported back is the intensity of each of the 4
> LEDs (UPLR) which then userspace can compute the velocity, and
> direction of the gesture. My question should some thing like this be
> using 4 IIO_INTENSITY channels or just one 32-bit value and new type
> of IIO_GESTURE?
Interesting device.
Anyhow, my immediate reaction is that the single 32 bit value is effectively
device specific whereas breaking it up into 4 values makes it more generic.
(just wait for the predictable 8 led version to offer extra LEDs on the diagonals)
The question that follows is how to make their relative positions / sensitive directions
apparent to userspace?
I'd go for sensitive direction as the optics of different sensors may give very different
correspondences.
So we 'could' do it with modifiers but how do we make them generic enough?
How about a a sensitive_direction type infomask element that gives an approximate
pointing vector? (using the read_raw_multi)
Other suggestion welcome as I have only been considering this whilst navigating Dublin
airport and a few beers waiting for the plane.
Jonathan
>
> Datasheet -> https://cdn.sparkfun.com/datasheets/Sensors/Proximity/apds9960.pdf
>
>
> Thanks,
>
> Matt Ranostay
>
next prev parent reply other threads:[~2015-06-02 18:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-02 4:35 IIO_GESTURE proposal Matt Ranostay
2015-06-02 18:28 ` Jonathan Cameron [this message]
2015-06-03 5:20 ` Matt Ranostay
2015-06-04 16:44 ` Matt Ranostay
2015-06-07 15:43 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=556DF5D8.9080000@kernel.org \
--to=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=mranostay@gmail.com \
--cc=pmeerw@pmeerw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).