Re: Representing a rotary encoder input device
On Sep 22, 2021, at 7:10 AM, Jason Thorpe wrote: > Well, ultimately, we translate “HID report” -> “ws* input event”. Or are you > suggesting that we should have a new interface to user-space that just sends > HID reports? That sounds like a good long-term plan, IMO, given the prevalence of HID in the modern era and the ability to map virtually everything to it. I've though occasionally about putting together drivers for some of the HP-HIL devices (single-dial-and-button rotary encoder, dial box with nine rotary encoders, and button box with 32 buttons with LEDs) but haven't had much clue how to wire them into the higher layers of the system to actually use. Having something like a HID abstraction layer that they could adapt to would make that more straightforward. -- Chris
Re: Representing a rotary encoder input device
> On Sep 22, 2021, at 5:23 PM, Chris Hanson wrote: > > On Sep 22, 2021, at 7:10 AM, Jason Thorpe wrote: > >> Well, ultimately, we translate “HID report” -> “ws* input event”. Or are >> you suggesting that we should have a new interface to user-space that just >> sends HID reports? > > That sounds like a good long-term plan, IMO, given the prevalence of HID in > the modern era and the ability to map virtually everything to it. That wouldn't really bother me and seems like a really good idea, it's just work that I don't want to do :-) (A set of helper functions to generate HID reports for devices that need to translate to HID from their native protocol would of course be super helpful.) > I've though occasionally about putting together drivers for some of the > HP-HIL devices (single-dial-and-button rotary encoder, dial box with nine > rotary encoders, and button box with 32 buttons with LEDs) but haven't had > much clue how to wire them into the higher layers of the system to actually > use. Some people have all the luck getting cool HP-HIL devices! -- thorpej
Re: Representing a rotary encoder input device
thor...@me.com (Jason Thorpe) writes: >Well, ultimately, we translate =E2=80=9CHID report=E2=80=9D -> =E2=80=9Cws= >* input event=E2=80=9D. Or are you suggesting that we should have a new = >interface to user-space that just sends HID reports? We already have a user-space interface that sends HID reports, we could make it a bit more universal.
Re: Representing a rotary encoder input device
> On Sep 22, 2021, at 8:43 AM, Greg Troxel 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
Re: Representing a rotary encoder input device
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 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. 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. But maybe you are trying to use an encoder to add scroll to a 3-button mouse? signature.asc Description: PGP signature
Re: Representing a rotary encoder input device
> On Sep 22, 2021, at 7:52 AM, Mouse wrote: > >> Well, ultimately, we translate â??HID reportâ?? -> â??ws* input eventâ??. O$ > > Do you really want input devices to be inaccessible except through > ws* interfaces? Unless it's possible to get ws* events without needing > the whole wscons infrastructure set up (eg, on a machine with serial > console), that strikes me as a bad idea. (Keyboards and mice also > really should be accessible without all of wscons too, but that's less > likely to be a practical issue.) Well, I'm not particularly interested in having to decode each device type separately in user-space. ws* presents an abstraction from which you can read the events. There's nothing that says you have to have those things connected to a display. -- thorpej
Re: Representing a rotary encoder input device
> Well, ultimately, we translate â??HID reportâ?? -> â??ws* input eventâ??. O$ Do you really want input devices to be inaccessible except through ws* interfaces? Unless it's possible to get ws* events without needing the whole wscons infrastructure set up (eg, on a machine with serial console), that strikes me as a bad idea. (Keyboards and mice also really should be accessible without all of wscons too, but that's less likely to be a practical issue.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Representing a rotary encoder input device
> On Sep 21, 2021, at 10:47 PM, Michael van Elst wrote: > > thor...@me.com (Jason Thorpe) writes: > >> Trying to think about the best way to represent such a device, I guess = >> within wscons (they almost seem sort of like a 1-axis mouse, but I could = >> be convinced otherwise). > > You can make it a HID, because that's what it is. > > Currently we only expose USB hid devices and sys/dev/hid is not much > more than a framework to support these. This would need to be extended > to a real abstraction (and uhidev might then be just a subclass). Well, ultimately, we translate “HID report” -> “ws* input event”. Or are you suggesting that we should have a new interface to user-space that just sends HID reports? -- thorpej
Re: Representing a rotary encoder input device
thor...@me.com (Jason Thorpe) writes: >Trying to think about the best way to represent such a device, I guess = >within wscons (they almost seem sort of like a 1-axis mouse, but I could = >be convinced otherwise). You can make it a HID, because that's what it is. Currently we only expose USB hid devices and sys/dev/hid is not much more than a framework to support these. This would need to be extended to a real abstraction (and uhidev might then be just a subclass). If someone then wants to use this input device for console, you can easily attach a wsmouse to it.
Re: Representing a rotary encoder input device
Are you planning on including rotary Quadrature Encoders? Often, such encoders when used for volume-control type applications have an extra contact set, actuated by pushing the knob in. They have the A and B quadrature and this (optional) pushbutton. On Tue, Sep 21, 2021 at 5:53 PM Jason Thorpe wrote: > Hey folks... > > As part of a long-running hardware project I have been playing with, I'm > experimenting with using a rotary encoder for input. For reference, here > is the Devicetree binding for rotary encoders: > > > https://github.com/devicetree-org/devicetree-source/blob/master/Bindings/input/rotary-encoder.txt > > Rotary encoders come in a bunch of different forms, of course... ranging > from simple knobs with detents to devices similar to the original iPod > click wheel. Some include built-in push buttons (that signal a separate > GPIO from the two GPIOs used to signal the rotary control itself). > > Trying to think about the best way to represent such a device, I guess > within wscons (they almost seem sort of like a 1-axis mouse, but I could be > convinced otherwise). > > Personally I'm seeing my use cases teetering towards using relative events > (value selection that from 0-9 that wraps around back to 0, and also volume > control that simply saturates at 0 or 100). But I want to make sure I > cover the absolute cases, as well. > > Thoughts? > > -- thorpej > >
Re: Representing a rotary encoder input device
On Tue, Sep 21, 2021 at 17:53 Jason Thorpe wrote: > Hey folks... > > As part of a long-running hardware project I have been playing with, I'm > experimenting with using a rotary encoder for input. For reference, here > is the Devicetree binding for rotary encoders: > > > https://github.com/devicetree-org/devicetree-source/blob/master/Bindings/input/rotary-encoder.txt > > Rotary encoders come in a bunch of different forms, of course... ranging > from simple knobs with detents to devices similar to the original iPod > click wheel. Some include built-in push buttons (that signal a separate > GPIO from the two GPIOs used to signal the rotary control itself). > > Trying to think about the best way to represent such a device, I guess > within wscons (they almost seem sort of like a 1-axis mouse, but I could be > convinced otherwise). > > Personally I'm seeing my use cases teetering towards using relative events > (value selection that from 0-9 that wraps around back to 0, and also volume > control that simply saturates at 0 or 100). But I want to make sure I > cover the absolute cases, as well. > Hey Jason - sounds interesting. Do you think this covers a simple case of “is moving clockwise”, or “is moving counter-clockwise”, w or w/o velocity? -bch > Thoughts? > > -- thorpej > >
