James Simmons wrote:
> To use the keyboard driver you need to
> 1) enable the input core and keyboard support in the input menu.
Would be nice to change the comment describing the Keyboard core
support (CONFIG_INPUT_KEYBDEV) in this patch: people (as dumb me)
may read the help in menuconfig and say:
I have no USB HID or ADB keyboard...
Recompile, reboot => no keyboard, no control-alt-del => Reset (fsck...).
Else it is working here on a P133 with nothing special (std PS2 mouse).
BTW you just undefine I8042_OVERRIDE_KEYLOCK but this define is
never used.
Etienne.
___________________________________________________________
Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr !
Yahoo! Courrier : http://fr.mail.yahoo.com
> Would be nice to change the comment describing the Keyboard core
> support (CONFIG_INPUT_KEYBDEV) in this patch: people (as dumb me)
> may read the help in menuconfig and say:
> I have no USB HID or ADB keyboard...
> Recompile, reboot => no keyboard, no control-alt-del => Reset (fsck...).
Yeah. That does need to be added.
> Else it is working here on a P133 with nothing special (std PS2 mouse).
>From the several reports I have had with the driver it looks pretty
stable. Alan what do you think about adding it to the ac tree?
> BTW you just undefine I8042_OVERRIDE_KEYLOCK but this define is
> never used.
Not implemented yet.
On Wed, Oct 03, 2001 at 12:28:34PM -0700, James Simmons wrote:
>
> > Would be nice to change the comment describing the Keyboard core
> > support (CONFIG_INPUT_KEYBDEV) in this patch: people (as dumb me)
> > may read the help in menuconfig and say:
> > I have no USB HID or ADB keyboard...
> > Recompile, reboot => no keyboard, no control-alt-del => Reset (fsck...).
>
> Yeah. That does need to be added.
>
> > Else it is working here on a P133 with nothing special (std PS2 mouse).
>
> >From the several reports I have had with the driver it looks pretty
> stable. Alan what do you think about adding it to the ac tree?
>
> > BTW you just undefine I8042_OVERRIDE_KEYLOCK but this define is
> > never used.
>
> Not implemented yet.
Quite the opposite: #undef was forgotten in the .h file after the .c
file converted to a runtime option instead of a compiletime one. I
removed it in the CVS now.
--
Vojtech Pavlik
SuSE Labs
> > Not implemented yet.
>
> Quite the opposite: #undef was forgotten in the .h file after the .c
> file converted to a runtime option instead of a compiletime one. I
> removed it in the CVS now.
Okay. Another thing is how to deal with IRQ's and the port regions. This
can vary from platform to platform. We could have this as a command line
option as well. In fact we might since it can be built as a module. Alot
of platforms added things to the command line inside the kernel code.
Or we can do lots of #ifdef in i8042.h or using the asm/keyboard method
like now. Personally I don't like this method since even on mips the i8042
port range varies on different machines. So we still end up with a bunch
of messy #ifdef.
On Fri, Oct 05, 2001 at 04:02:08PM -0700, James Simmons wrote:
>
> > > Not implemented yet.
> >
> > Quite the opposite: #undef was forgotten in the .h file after the .c
> > file converted to a runtime option instead of a compiletime one. I
> > removed it in the CVS now.
>
> Okay. Another thing is how to deal with IRQ's and the port regions. This
> can vary from platform to platform. We could have this as a command line
> option as well. In fact we might since it can be built as a module. Alot
> of platforms added things to the command line inside the kernel code.
> Or we can do lots of #ifdef in i8042.h or using the asm/keyboard method
> like now. Personally I don't like this method since even on mips the i8042
> port range varies on different machines. So we still end up with a bunch
> of messy #ifdef.
I'd prefer a bunch of #ifdefs in i8042.h with defaults and a command
line option to change that if needed. For some of the more differing
architectures (Sun Ultra AX) which have i8042-alike chips in them
complete separate drivers may make sense as well.
--
Vojtech Pavlik
SuSE Labs