On Thu, 25 Jun 2009 23:05:55 +0800 Jani Nikula <ext-jani.1.nikula@xxxxxxxxx> wrote: > 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? > Yes, correct. I just want to reply your previous mail, but seems you find that. :-) > > 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. > Yes, sending first state 0 to input layer does nothing wrong. > > 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
