OSDev.org

Some time ago I have written a very basic driver for the firmware-emulated PS/2 controller, to receive key presses from a connected USB keyboard. I try to avoid having to write an entire USB implementation, since the focus of this project is more on research, and only very basic I/O is necessary.

The driver just enables IRQ1 and, on interrupt, reads port 0x60 to retrieve the scan code. This works pretty well for 6th and 7th gen Intel processors, but on 4th and 5th gen systems it has a slightly weird behavior: First of all, the configuration register of the emulated controller has value 0x70, so both PS/2 ports are disabled. I then set this register to 0x65 (as for the other computers). Unfortunately I still do not get any interrupt - until I start polling port 0x60, which after a key press raises IRQ1 and triggers my interrupt handler.

So right now for each single keyboard interrupt, I have to read port 0x60 beforehand - which renders that interrupt rather useless, since I have to poll anyway.

Has anyone of you ever encountered such a behavior, or do you have an idea on how to fix this without needing to implement an entire USB stack?

You could probably read the port every now and then from e.g. the timer ISR. By no means I advocate for it being the right thing to do, just a quck and dirty workaround.

Have you tried reading port 0x60 just once after enabling IRQs to flush the buffer? There could be some kind of race condition in the PS/2 controller emulation that causes a byte to enter the buffer before the IRQ is enabled.

To be honest I never trust emulated PS/2 controllers as they have undefined behaviors, like when my Asus motherboard doesn't return the scancode set and it's using scancode set 2. I'd say implement an USB stack or something.

I have tried that, but it does not change the behavior; I still only get an IRQ when reading the port.


Thank you for the suggestion, I have just implemented this and it works well

I completely agree with you, the real solution is implementing a proper USB stack - right now the I/O has very low priority for me (it should just work ), but maybe at some point in the future I will spend some effort to implement an USB-based keyboard driver. Thank you for your help!