On Thu, 2009-06-25 at 16:52 +0200, Jani Nikula wrote: > On Thu, 2009-06-25 at 16:08 +0200, ext Alek Du wrote: > > If you schedule the timer when you decide it "stabilized", the final gpio_get_value() > > could still return 0 in the timer handler, if the key released at that time. So your previous > > "stabilized" state is useless. > > True, gpio_keys_report_event should also compare the value to the > previous state and bail out if it's unchanged. Something along the lines > of: > > @@ -46,6 +46,10 @@ static void gpio_keys_report_event(struct work_struct *work) > unsigned int type = button->type ?: EV_KEY; > int state = (gpio_get_value(button->gpio) ? 1 : 0) ^ button->active_low; > > + if (state == bdata->state) > + return; > + bdata->state = state; Actually scrap that, the input layer already ignores events with no state changes, right? > Debouncing should also completely ignore a single spike shorter than > debounce_interval. Admittedly gpio-keys was flawed, but please consider > a change like above which should fix that. Same here, gpio-keys did ignore spikes shorter than debounce_interval. BR, Jani. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
