I need to write a custom input driver that supports both hard buttons and a
rotary encoder. The encoder will be used to implement a user interface that
can scroll up/down menu items, files, etc and then press to click the
selection.
This doesn’t seem to fit cleanly into the absolute/relative/keypad type
model that the Input DDK supports. The encoder gives a direction and a
count, not X/Y coordinates or keyboard scan type codes.
Anyone implemented a rotary encoder input driver? I’d love to learn from
your experiences. All ideas and suggestions welcome.
Ken Schumm wrote:
This doesn’t seem to fit cleanly into the absolute/relative/keypad type
model that the Input DDK supports. The encoder gives a direction and a
count, not X/Y coordinates or keyboard scan type codes.
Absolute position and relative distance are interchangeable via differencing and accumulating.
Anyone implemented a rotary encoder input driver? I’d love to learn from
your experiences. All ideas and suggestions welcome.
All early mouses were just two rotary encoders and some buttons so what you are asking for is actually how GUIs got started and even to this day an optical mouse has no reference of where it is placed on your mat/desk so can only usefully send deltas to the driver and it’s the driver that will accumulate these into an absolute position.
Evan
Ken Schumm wrote:
I need to write a custom input driver that supports both hard buttons and a
rotary encoder. The encoder will be used to implement a user interface that
can scroll up/down menu items, files, etc and then press to click the
selection.
This doesn’t seem to fit cleanly into the absolute/relative/keypad type
model that the Input DDK supports. The encoder gives a direction and a
count, not X/Y coordinates or keyboard scan type codes.
Anyone implemented a rotary encoder input driver? I’d love to learn from
your experiences. All ideas and suggestions welcome.
Well, I once implemented a steering wheel and pedals.
(Not a simulation, either; we could drive our robot
vehicle). I had a second thread in a Photon application
reading USB HID input device events, another thread
dealing with the real-time system, and the main Photon
thread doing the GUI. With proper Photon locking,
this all worked fine. The mouse and keyboard
went through the Photon queue, but the steering
wheel and pedals did not.
Photon is good for this sort of thing. Just
make sure you obey Photon’s locking rules, which
are documented in the help files.
John Nagle