I've looked into keyboard locking for some of my machines - I found
that I could only get the keyboard to lock when I moved the mouse and
I had *not* got the psaux driver installed. (The mouse was producing
data on the aux port because I started Linux from loadlin, and the DOS
initialisation had enabled the aux device.)
Both the keyboard and the mouse send data on the same pair of ports
(command/status on 0x64, data on 0x60), however, keyboard data
triggers IRQ 1, and mouse data triggers IRQ 12.
The IRQ handler the keyboard driver uses is (roughly) of the form:
read status register
while (status indicates data waiting)
{
if (psaux driver has ever been loaded and status indicates aux data)
break out of loop
read scancode from data register
handle scancode
read status register
}
The IRQ handler for the psaux driver is of the form:
read status register
if status register shows that aux data is waiting
read data from data register
Loading and unloading the psaux driver has a permanent effect on the
keyboard interrupt handler, since it makes aux data break out of the
keyboard reading loop. If the psaux driver has never been loaded, the
mouse data is treated as keyboard data. (This appears to be the
condition that seems to causes the keyboard to lockup - I haven't
investigated enough to know why.)
If the psaux driver has been loaded then unloaded, the aux interrupts
are disabled, and the aux port is disabled. It is not clear is the
remaining aux data is cleared from the controller's output queue. If
it is not, then there is a small chance that you will end up with aux
data on the output queue that will never be read by the keyboard
driver. It's also not clear that you can't get a deadlock because you
get data on both the keyboard and aux devices and the wrong driver
gets the interrupt first.
A simpler structure for the two routines above would be to have both
keyboard and psaux interrupts handled by one interrupt handler:
read status register
while (status indicates data waiting)
{
read data register
if (status register indicated that data was psaux)
call psaux driver if it is installed
else
call the keyboard driver
read status register
}
This way, you can be sure that the data register is always read so you
won't get a deadlock where they keyboard driver is waiting for the
(possibly unloaded) psaux driver to do something.
In addition, unloading the psaux module should call this routine to
empty the controller's queue after after the aux device is disabled to
get rid of waiting aux data.
Peter