Re: Representing a rotary encoder input device

[Jason Thorpe <thorpej%me.com@localhost>]

> On Sep 22, 2021, at 8:43 AM, Greg Troxel <gdt%lexort.com@localhost> wrote:
> 
> 
> What do other systems do?  It strikes me what wsmouse feels like it is
> for things connected with the kbd/mouse/display world.  To be
> cantankerous, using it seems a little bit like representing a GPIO input
> as a 1-button mouse that doesn't move.

I haven't looked at what Linux does with rotary encoders yet, specifically.  For GPIO buttons, I do know that those are translated into Linux key press events in their general input stream.  We do that for buttons, too... that's what the "gpiokeys" driver is for, and these are the Devicetree bindings for it:

	https://github.com/devicetree-org/devicetree-source/blob/master/Bindings/input/gpio-keys.txt

> I would imagine that a rotary encoder is more likely to be a volume or
> level control, but perhaps not for the machine, perhaps just reported
> over MQTT so Home Assistant on some other machine can deal.

In my use case where the encoder is a volume control, it really is for the device it's attached to.

> If you are really talking about encoders hooked to gpio, then perhaps
> gpio should grow a facility to take N pins and say they are some kind of
> encoder and then have a gpio encoder abstraction.

Yes, that's what the Devicetree binding facilitates ... writing a driver that gathers up multiple GPIO inputs to present a higher-level device.

> But maybe you are trying to use an encoder to add scroll to a 3-button
> mouse?

No, that's not what I'm doing.

-- thorpej