Hi Vipul,
On 15/09/17 23:19, Vipul Rahane wrote:
That is interesting. I have never really used one but sounds cool.
IMO, we should create a driver group - input_devices just like sensors.
I think this is different enough from sensors that it deserves a
dedicated group, yes.
I don’t know enough about rotary encoders to figure out whether a generic API
would be useful.
For rotary encoders, it's generally very standard. It's a two line
interface where you need to track the previous state of the two pins
and, when compared with the current state, you know whether you are
turning CW or CCW:
https://en.wikipedia.org/wiki/Rotary_encoder#Incremental_rotary_encoder
You can use them for menu navigation, but also to track things like
rotation speed.
The only real variant on low cost encoders is whether or not the encoder
has an optional 'SWITCH', which means you can press the shaft like a
button for a select action. This is just handled like a standard button
input, though.
Any sort of engineering test equipment like oscilloscopes, function
generators, etc., usually has several rotary encoders for user input.
Any knob you turn is most likely using one, like adjusting the
horizontal or vertical values on a scope.
Is one of the application Mouse scrolls ? If so, we should probably think about
generalizing based on the type of data it gives back but that’s just me.
These are used in the central scroll wheel on mice, for example, yes,
but it's very nuetral and not really application specific. I think you
can just have a generic 'rotary encoder' type and track absolute
position over time (the accumulation of all positive and negative
values), and a callback whenever there is a change in the position
either + or - (cw or ccw).
Keyboards are input devices as well but a capacitive touch sensor would go under
sensors and a gpio grid/matrix keyboard/capactive touch keyboard probably won’t have
the same output, so generalizing them won’t be possible and would just go under
"hw/drivers/input_devices”.
Keyboards are a more complicated example since you then need to deal
with mapping GPIO input pairs (row + column) to values, which changes
from one keyboard layout to the next (English = QWERTY, French = AZERTY,
etc.). I would still consider this an input device, but a more
specialized 'input grid', which covers a large variety of input devices
(numeric keypads, etc.).
Rotary encoders are far easier to start with, but it's worth thinking
about other options.
Would something like a trimpot or other potentiometer
(https://en.wikipedia.org/wiki/Potentiometer) be considered a 'sensor'
or an 'input device'? It is based on sampling an analog input and the
voltage will vary between GND..VCC, so it's very sensor like, but the
main goal is usually to provide user input so I'm not sure where that
could go. (Volume knobs are often implemented using a potentiometer, for
example, or you might use a trimpot to configure a device at startup to
control something like pressure, brightness, refresh rate, etc., using a
screw driver for manual input.)
Best regards,
Kevin
