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 don’t know enough about rotary encoders to figure out whether a generic API would be useful. 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. 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”. Regards, Vipul Rahane > On Sep 15, 2017, at 9:28 AM, Kevin Townsend <[email protected]> > wrote: > > The nRF51 and nRF52 both have a HW quadrature decoder, making it easy to use > rotary encoders like https://www.adafruit.com/product/377) without all kinds > of GPIO processing. > > Rotary encoders with a select switch are a really nice feedback mechanism and > you can design a fairly rich physical UX with just one of them. > > We have the sensor API, but where would a driver for something like this fit > into Mynewt, in your opinion(s)? > > There are other similar options like cap touch (I guess that could be a > sensor?), numeric keypad entry (https://www.adafruit.com/product/419), or a > GPIO grid for keyboard input. > > I'm willing to submit a driver for the encoder, but there should probably be > some discussion of the lower level framework for this kind of input device??? > > Kevin >
