Re: question about ruby's keyboard.c & keybdev.c

[James S. <jsi...@tr...>]

> > > for maintenance reasons. keybdev.c provides bridge code between input
> > > layer and old-style keyboard.c. In ruby this is no longer necessary as
> > > the new-style keyboard.c registers itself directly to the input layer.
> > >

You still need keybdev.c with 2.5.25. It will be a few weeks before we
will migrate the console system to the input api.

> > That's right, I'm working on the merge right now.
>
> And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech!

Just a few more steps to go. I submited the console patches to Linus. Now
to wait for them to go in.

> While preparing the PPC part I noticed one thing though, how do you intend to
> handle the platforms (2 PPC embedded boards and MIPS AFAICS) that redefined
> kbd_read_input/kbd_read_status/kbd_write_output/kbd_write_command so far
> (using ioremap/readb/writeb and sometimes special access sequences)?

Why we break them. One thing I learned the hard way with the fbdev layer
is if you want to change the api you need to change the upper layer first
and break every driver. Its the only way it will work.

> Do you want #ifdefs in i8042.[ch]? Or separated includes and/or drivers like
> i8042-ppc.[ch]?

:-(

> One more thing, CONFIG_SERIO_I8042 currently depends on CONFIG_ISA, does this
> really make sense?

??