Button example is not using `gpio-keys` driver

[arifbalik]

The basic button example shows the use of gpio-keys but does not use the input subsys to read the button events, instead it initializes the gpio pin again and reads it with GPIO API.

It has to be decided if this example wants to show how to use GPIO API or how to use gpio-keys. If the answer is GPIO API, zephyr-user can be used;

#include <zephyr/dt-bindings/gpio/gpio.h>

/ {
     zephyr,user {
             signal-gpios = < &gpio0 PIN FLAGS >;
     };
};

Alternatively, gpio-keys can be used fully and input subsystem can be showcased.

[github-actions[bot]]

Hi @arifbalik! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[fabiobaltieri]

Yeah the two examples (blinky and button) are essentially "gpio output" and "gpio input", they were created before the respective subsystems (leds and input).

What are you proposing exactly? The input sample is there and it's pretty much just an empty option (all the debugging code is part of the subsystem). Moving the node in zephyr,user does not make much sense to me, the current alias works just fine and allows for buttons to be used with both the subsystem or directly.

[arifbalik]

Well, it kinda creates a confusion, at least it did for me. Also there is not a simple example showing how input works with individual buttons and switches. My proposal is that we use input api

[fabiobaltieri]

Well, it kinda creates a confusion, at least it did for me. Also there is not a simple example showing how input works with individual buttons and switches. My proposal is that we use input api

Ok now we are getting somewhere, that's the issue.

The simple example for input is https://docs.zephyrproject.org/latest/samples/subsys/input/input_dump/README.html, it really does not get much simpler than that, there's no code, it just prints any input event, buttons and everything else.

This is linked from the button sample doc (https://docs.zephyrproject.org/latest/samples/basic/button/README.html) but I think that there's some discoverability issue because I've heard people saying that Zephyr has no debounced input driver while it's just there waiting to be used.

Is that what you expected? How do you think we could make that easier to find? Maybe a comment in the button code as well?

[arifbalik]

Exactly, the reason i opened the issue is precisely this because I did write my own debounced button driver. Although I was happy about the implementation which was very similar :)

Well, i think input dump shows the thing, maybe we can add a comment as you said. Let me see what i can do

[fabiobaltieri]

Thanks, yeah if you could open a PR with an extra comment in the code it'd be much appreciated.

[arifbalik]

Oh, my bad, it seems like you've added this note 2 months ago; https://github.com/zephyrproject-rtos/zephyr/commit/2455291da85cfd31529b00bd89eb66232a50a9b6#diff-2912957f693319cfdabe6cf4c2ccecba7c25c2123c0c58b1d5433cad090ed707R13

I would like to write another example, reading buttons with input if you think discoverability is still an issue.

[fabiobaltieri]

Oh, my bad, it seems like you've added this note 2 months ago; 2455291#diff-2912957f693319cfdabe6cf4c2ccecba7c25c2123c0c58b1d5433cad090ed707R13

Yeah, it was after listening an episode of the Embedded FM podcast where the guest said that Zephyr did not have any button debouncing drivers :-)

I think an input based sample there would be redundant to the input_dump one, but a comment in the code (in addition to the one in the sample documentation) may go a long way.