OSDev.org

I'm currently in the process of testing my PS/2 keyboard drivers on real hardware, and i'm running into some weird behaviour on a Dell Optiplex 760. I'm observing the following behaviours:
Keyboard is advertised with 0x00 as it's identification string, the same as any mouse i plug in to the system.
When forcing my keyboard driver to take ownership of the device on port 1 irregardless of the identification string, the driver does receive events in response to key presses on the attached keyboard, however the received key codes are not what I expected them to be, and furthermore seem to somewhat random, in the sense that the same key doesn't always give the same keycode, even for simple keys like letters or numbers.

Has anyone seen such behaviour before? Is it more likely that my code is doing something weird that just happens to work on qemu, bochs and virtualbox and my laptop, but breaks on this particular hardware, or could it be a bios/firmware issue?
And does anybody have a reasonable reference implementation in their hobby project that I could try out on this hardware?

Hi,

The first and only rule of "PS/2 emulation for USB devices" is that it's dodgy and no modern OS should ever use it.

What I mean is that an OS should do PCI enumeration, find all USB controllers and disable "PS/2 emulation" in all USB controllers; and should not touch anything to do with PS/2 until after "PS/2 emulation" is disabled.

Note: If convenient; disabling "PS/2 emulation" in USB controllers can be done early during boot using special purpose code, before the OS starts a real USB controller driver, and even if proper USB controller drivers don't exist. For me specifically, I'm planning to do this very early during boot (before boot code tries to establish a "dynamic root of trust" via. AMD's SKINIT instruction or similar, before kernel is started) to reduce security risks.

If your code works properly on computers with actual PS/2 (that aren't using "PS/2 emulation"), then I'd assume your code is fine.


Cheers,

Brendan

Hmm, shame that PS/2 emulation is that dodgy. Was hoping to get things working without writing a usb stack for my current project (the primary goals are in design choice consequence evaluation for an upcoming project), but it is good to know that given the fact that it works on my laptop (which uses PS/2 internally for some reason) means my PS/2 implementation is (probably) OK.