Hi,
psychobeagle12 wrote:
Is this too much stuff to be going on inside the interrupt handler?
Yes, and no. For example, setting keyboard LEDs shouldn't be done in the interrupt handler. Apart from that, I see no reason why the interrupt handler's code would be too slow.
psychobeagle12 wrote:
I was considering using a bitmap approach to flag whether a key is down or up, combined with a scancode queue instead of a character queue that would allow me to enter and exit the interrupt quickly. The bitmap would be used to determine which keys are down at any given moment, and the scancode queue would allow me to fetch keys in the order in which they were pressed. Again, this code is working as-is, though every now and then I get a glitch (pressing the GUI keys gives me an odd character, and if I press them twice the driver locks up.) So, my question is, should I be trying a different approach here I suppose. Thoughts?
In general; I'd suggest that the keyboard IRQ handler should only convert the scancode into a standard "key code" and send the resulting key code to something else (a kernel thread, a "bottom half interrupt handler", whatever).
That "something else" would (e.g.) keep track of the state of each key, convert key codes into "keypress packets" (e.g. including using tables for whatever keyboard layout the user happens to be using to determine the Unicode code point, if any), handle keyboard LEDs, etc. Also, because you'd be using standardised "key codes" (rather than device specific scan codes) the same "something else" could be used by (e.g.) a USB keyboard driver and a PS/2 keyboard driver.
Also note that (at least in my opinion) it's strange for the same PS/2 keyboard driver to handle different scan code sets. More likely the "PS/2 controller driver" would try to disable the scancode translation, then it would use "identify device" to determine what sort of device is present on each PS/2 port (keyboard, mouse, bar-code scanner, touch-pad, whatever); then it would either starts a "no scan-code translation PS/2 keyboard driver" (which sets scan-code set 2 and only ever cares about scan-code set 2), or starts a different/separate "with scan-code set translation PS/2 keyboard driver" (which sets scan-code set 2, and only ever cares about scan-code set 1, because the PS/2 controller is converting from scan-code set 2 back into scan-code set 1).
Note: The PS/2 controller is mostly just a serial port controller with 2 serial ports (where "PS/2" is just a serial communication protocol, similar to RS232 but different). There is nothing preventing you from having (e.g.) a PS/2 keyboard in each port, or a PS/2 mouse in each port, or a special PCI card that provides additional PS/2 ports so you can have 4 PS/2 keyboards at the same time.Cheers,
Brendan