Re: AMBA Keyboard and Mouse?

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

> > Great!!! Want to give this driver a try? I have it attached. You need to
> > have in input core selected
> > 
> > Input core support
> > Keyboard support
> > 
> > As you know keyboard support is to make the input keybaord behave as a
> > PS/2 keyboard so you need pc_keyb.c compiled in. Yes it is not so hot but
> > 2.5.X will fix that once keyboard.c in char will be converted over to be
> > input based. The next thing is to attach the device you need the program
> > attached above, inputattach. Just do for example
> > 
> > inputattach --ps2serkbd /dev/ttySA1 &
> > 
> > Of course pick the correct serial port. 
> 
> Umm, ok, I've looked through it, and I have a couple of questions:
> 
> 1. when the machine fails to boot, how do you use the keyboard sysrq
> functions if you need a userspace program to run to get the keyboard
> working?  Also, think about the ramdisk loading that requires you to
> hit a key _before_ root is even available (you can't).  This is my
> main concern with this approach.

> If a "serial port" is intended to be used for a keyboard, and has a
> PS2 connector attached to it, then I think we should have some way
> of allowing the kernel to automatically initialise it.

Yes we know. That is why the interest in your "universal" serial code. 
Right now the serial drivers are too diverse to have this happen so we
went the safe route, using the line disipline. We need to make it so that
any serial device can be plugged/unplugged from one type of serial port to
another and it will work perfectly. 
 
> 2. we need yet more code to create these "keyboard" serial drivers,
> with associated device nodes that do not currently exist.  (don't
> expect the above to be tested in a short space of time due to this).

More code? If you mean serio.c and serport.c. Well that same code is
reused by many drivers. It ends up saving more and more when you have more
devices. As for keybdev.c. Well that will go away in 2.5.X. It is only a
hack for now to make input devices behave like PS/2 keyboards. The core of
the console code is wrapped around the assumption that you have a PS/2
keyboard. Once the console migrates to the input api this issue will go
away. I assume you mean by associated device nodes /dev/input/eventX. You
don't need to create them. They just provide away to access the keybaord
hardware in a universal way from userland.