Jonathan,
Doing some thinking over the last couple days, and need some additional input.
1) Do IIO_MOD_DIRECTION{UP, DOWN, LEFT ,RIGHT} modifiers seem generic enough
2) Now the gesture functionally for this APDS9960 part isn't something
you can read_raw due to the fact reading the registers directly would
empty the FIFO on-chip RAM. I don't see away of having an
iio_chan_spec be blacklisted from in_*_raw sysfs entry? Which would be
need to prevent side-effects.
3) Should gesture reporting be done with a triggered_buffer or would
iio_push_event make more sense? I suspect the latter since you don't
really care about data that you have missed and don't need it
buffered.
Thanks,
Matt
On Tue, Jun 2, 2015 at 10:20 PM, Matt Ranostay <mranostay@xxxxxxxxx> wrote:
> On Tue, Jun 2, 2015 at 11:28 AM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>> 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)
>
> The latter seems more sane and functional. Would this just tell
> userspace the orientation that the sensor is mounted on a board? I
> would assume so since the LEDs are integrated on the sensor IC.
>
>>
>> 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
>>>
>>
--
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
