feat(drivers): add analog joystick driver

[xqinx]

Analog joystick drivers using ADC to read joystick sensor output and convert the reading to [-1.0 1.0] range. Joystick of choose in the implementation is THB from C&K, but it should apply to similar products with analog inputs as well.

example usage in dts:

joystick0: thb {
     compatible = "ck,thb";
     label = "JOYSTICK";
     io-channels = <&adc 0>, <&adc 5>;
     io-channel-names = "X-AXIS", "Y-AXIS";
     max-mv = <1650>;
     status = "disabled";
};

A demo using this joystick as a pointer device can be found here from this project

[myst729]

Is it possible to make this a more generic ADC driver, then implement peripherals on top of it? Something like joystick, as well as linear slider, hall effect sensor, etc.

[xqinx]

Is it possible to make this a more generic ADC driver, then implement peripherals on top of it? Something like joystick, as well as linear slider, hall effect sensor, etc.

Thanks for the comment! This is an interesting proposal, and if I understood correctly you are suggesting adding an abstraction layer between the OS ADC API and various sensor implementations, i.e. instead of going [ADC API] --> [Joystick], a generic ADC layer sits in between so [ADC API] --> [Generic Analog] --> [Joystick, slider, etc.] and the intuition would be to put most of the ADC configuration and initialization logic in this [Generic Analog] layer, correct?

IMHO I don't think this [Generic Analog] layer can provide much more value than the OS ADC API, in fact, if it was generic enough, it should probably go to the OS ADC API itself. On the other hand, in the sensor implementation code, a bulk of their code always involves implementing the sensor_driver_api, which is closely coupled to the specific sensor (an immediate example would be to choose the correct sensor_channel for each sensor) and not easy to be abstracted away neither.

Therefore an additional abstraction layer may not be the best way to go, what do you think?

[myst729]

Well, I'm not a hardware guy. My comment may be naive and unfeasible. In the first place, what I want is to use magnet switches with hall effect sensors and analog multiplexers. I've done it on top of QMK, which provides a very convenient ADC driver. So I could focus on the custom matrix scan part. I'd like to do this on ZMK too. But honestly, I'm not familiar with ZMK yet, its developing experience is very different from QMK.

[xqinx]

Well, I'm not a hardware guy. My comment may be naive and unfeasible. In the first place, what I want is to use magnet switches with hall effect sensors and analog multiplexers. I've done it on top of QMK, which provides a very convenient ADC driver. So I could focus on the custom matrix scan part. I'd like to do this on ZMK too. But honestly, I'm not familiar with ZMK yet, its developing experience is very different from QMK.

I see, yea what you described is indeed in the scope of an ADC driver, which Zephyr provides a nice abstraction for. A middle layer abstraction on top of that doesn't seem to be useful I think

[myst729]

I see, yea what you described is indeed in the scope of an ADC driver, which Zephyr provides a nice abstraction for. A middle layer abstraction on top of that doesn't seem to be useful I think

Looks like it's time to start learning Zephyr 🥲

[saitamandl]

Any updates on this PR? Would be really great to be able to add an PSP style joystick Are the PR #2176 and #1446 related to this?

[rp1231]

xinput support would be great!