>
> This information would be far more informative if you printed the
> button that is pressed/released here.
ok
>
> > + }
> > + gb->previous_state = val;
> > + }
>
> You do nothing for debouncing the keys.
yes my hardware manage directly (gpio IP)
we can add it later
> > + return ret;
> > + }
> > + gpio_direction_input(gpio);
> > + }
> > +
> > + pdata->poller.func = gpio_key_poller;
> > +
> > + cdev = &pdata->cdev;
> > + dev->type_data = cdev;
> > + cdev->dev = dev;
> > + cdev->f_caps = CONSOLE_STDIN;
> > + cdev->tstc = gpio_keys_tstc;
> > + cdev->getc = gpio_keys_getc;
> > +
> > + console_register(&pdata->cdev);
>
> As I tried to explain yesterday I'm not sure that directly registering
> the gpio keys as a console is the right thing to do. A keyboard has
> more attributes than what we have in the console. For example a keyboard
> has a button press / button release event which we don't have on the
> console.
agreed but today we do not have a input framework yet
I'm planning to add such framework but as a second step
I'll add the usb keyboard too
>
> > +
> > + return poller_register(&pdata->poller);
> > +}
> > +
> > +static struct driver_d gpio_keys_driver = {
> > + .name = "gpio_keys",
> > + .probe = gpio_keys_probe,
> > +};
> > +
> > +static int gpio_keys_init(void)
> > +{
> > + register_driver(&gpio_keys_driver);
> > + return 0;
>
> Since we now do not panic anymore when an initcall fails but only
> use the return value for debug purposes please do a
>
> return register_driver(&gpio_keys_driver);
ok
Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
