[OpenWrt-Devel] [PATCH v2] gpio-button-hotplug: mind debounce interval consistently

[David Bauer]

Hello Christian,

On 7/14/19 12:04 AM, Christian Lamparter wrote:
> The "goto set_setstate;" only happens if state = 0 (Which in gpio-button
> context means) that the button is in an unpressed state.

Okay, you are right, this is one thing i missed.

If we suspect, the polarity is correctly set for every board, your code is completely
right and should behave the same for polled and irq based keys.

So, the question is primarily if we want a event if a button is pressed continuously
on bootup. I think this is the point where our expectations differ.

I might be a bit late for this realization, sorry for that :D

> You can see that gpio_keys_polled_check_state() always "ate" initial
> state event for polled buttons (yes, both states - pressed and unpressed -) got
> ignored.  Which I think is very wrong... mostly because it goes against the 
> decades of experience I have with "holding down buttons while powering up devices"
> and expect them to get noticed properly :D. That's why my code only eats the initial
> unpressed/0 event, but reports the pressed button event. This should still be
> compatible with the current failsafe setup. 

Honestly, i think our expectations divert here a little ;)

OpenWrt Wiki states "It listens for a button press inside a specific two second window,
which is indicated with LEDs and by transmitting an UDP package."

and

"Recommended for most users: Wait for a flashing LED and press a button.
This is usually the easiest method once you figure out the correct moment."

So yes, this differs from the usual "Hold a button and insert power". However,
entering failsafe on any button state change event would be the behavior i suspect.

> Related Note: 
> As for the sudden burst of the "device is always entering failsafe".
> I can see how this is causing problems now. Because if the polarity of
> a button was declared (or that got copied from another device without
> checking ;) ) with the wrong way; This will now become a problem because
> it "physically unpressed" button gets reported as "pressed" and this causes
> the device to always enter failsafe (unless the very button with the wrong
> polarity is pressed, which in this context means unpressed).

This is - sadly - not the reason why I'm observing this issue :(
Polarity is correctly declared for my devolo board.

> However, I think this is a problem of the individual dts/board support code.
> But sadly I have currently no time to monitor the forums, bugtracker, ML or
> github for these problems... so what to do?

This is clearly nothing we should worry about. I made myself also guilty of this
mistake and it makes things weird in so many ways.

It's a bug in the boards integration and nothing we have to catch on our layer :)

>> You are right. Your commit was relating to the reset of the counter, my remark was
>> about "There should be no events in case last_state == current_state also for irq
>> keys. So no functional problem to see here :)
> 
> Ok, so this is fine?

Yes :)

> 
> As everyone who follows the thread can see: The struggle is real!
> Even for something as seemingly simple and benign as a gpio-button.

Okay, so how do we want to proceed? I would propose to merge your iteration
(as it was working for me in both modes) to master, wait for people to complain
and then pickit to 19.07? It should be an improvement over the current situation
anyways. I would view the failsafe mode on a continuous press as a new "feature" here ;) 

Best wishes
David

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel