Some rotary-encoder devices (such as those with detents) are capable
of producing a stable event on each step. This simple patch adds support
for this case, by implementing a new interruption handler.

The handler needs only detect the direction of the turn and generate
an event according to this detection.

We encode the previous and the current state, and then use the sum of them
to decide on the direction of the turn, according to the following simple
table:

Previous state + currrent state | Movement
==========================================
        0b1101                  | clockwise
        0b0100                  |   ..
        0b0010                  |   ..
        0b1011                  |   ..
==========================================
        0b1110                  | counter-clockwise
        0b0111                  |   ..
        0b0001                  |   ..
        0b1000                  |   ..

(The other sumed values are considered illegal)

This calculation is based on some previous work found at this blog:

  http://bildr.org/2012/08/rotary-encoder-arduino/

The result is a seemingly very robust behavior, with a truly simple
implementation, that produces an event on each turn of the device.

I don't have much experience with this rotary-encoder devices, so I'm sending
this just as an RFC/PATCH, to get some early feedback. In particular, I got a
bit puzzled by the current implementation with 'armed' and 'dis-armed'.
Maybe there's some way of using the current driver and get an event on each 
turn?

If this change looks more or less acceptable, I can add device-tree bindings
(which are missing from this first patch) and re-send.

Thanks!

Ezequiel Garcia (1):
  Input: rotary-encoder: Add 'stepped' irq handler

 drivers/input/misc/rotary_encoder.c | 34 ++++++++++++++++++++++++++++++++++
 include/linux/rotary_encoder.h      |  1 +
 2 files changed, 35 insertions(+)

-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to