Most likely it's because USB is handled by the kernel, but the BIOS has keyboard routines for ps/2 keyboards built in. I bet if you had "legacy USB" or whatever enabled in your bios you could work something out that way.
I bet it's more that there's fixed, dedicated hardware for PS/2 that's dead simple to use (or traps into System Management Mode or some such that emulate the hardware for those I/O ports in the case "legacy USB").
I doubt they've kept env around to make BIOS calls at runtime. You have to run those in 16-bit real mode, so it's a massive pain to use outside the initial bootloader in a modern kernel env.
This is the code for how it's reading keyboard input. Seems like it's just dead simple? From what I understand about how BugChecker works, I don't think anything else matters, except maybe ensuring stability.
I wonder how much abstraction is living in the BIOS and hardware bits to make this work, vs those I/O ports literally being a direct interface to the PS/2 keyboard.
The purpose of "USB Legacy Mode" as I understood it was to make a USB keyboard appear to be a PS/2 keyboard during boot, so if you could somehow make that mode stay active even after windows boots, maybe it would work with this?
>I wonder how much abstraction is living in the BIOS and hardware bits to make this work
I think any modern chipset that supports PS/2 still includes a keyboard controller that is essentially the same as it was 30+ years ago, only the ISA bus is emulated over a serial connection[0].
The interesting thing is that even back then, that controller was translating the raw scancodes sent from the keyboard, in order to be compatible with the original IBM PC. And for compatibility with the first (84 key IIRC) AT keyboard, the keyboard itself also sends certain keys as sequences starting with a "fake" Ctrl or Shift keypress, instead of a single number for each key.
There are commands to turn all (or most) of this translation off in both the controller and the keyboard itself, but on newer system or with USB->legacy translation they may not work [1]. So any keyboard driver today is essentially stuck interpreting these translated scancodes.
> I wonder how much abstraction is living in the BIOS and hardware bits to make this work, vs those I/O ports literally being a direct interface to the PS/2 keyboard.
Depends on that Legacy USB flag. For a real PS/2 device that I/O port is a pretty direct line to a microcontroller living on the southbridge (or a Super I/O chip sitting off of an LPC bus) that babysits the PS/2 bus. But with that Legacy USB flag enabled it's a trap to System Management Mode to emulate it the same way an I/O port access in user space might trap into the kernel.
>At the moment, BugChecker requires a PS/2 keyboard
I've seen plenty of blue screens when the kernel has one too many or too less of a handle, lock, or memory allocation, so maybe it needs a safe way of cleaning up things before it take over the kernel usb stack or implement its own.
I'm holding out for a nice AC'97 [0] or modern equivalent mp3 player [1] like the IceExt softice extension.
My Dell optiplex 9020 all-in-one, a compatibility beast, has all the usb ports you can think of, hdmi, sd card, CD drive, VGA... And yes, support for PS2 keyboard and mouse.
It can run windows 11.
Got it in 2012 or so, still running strong with a memory upgrade from 4->12.
Best computer I've owned.
Easy to maintain, nice documentation about the hardware and solid as a rock.
How about running it inside a VM, they usually emulate PS/2 devices. Or are there similar debuggers natively in something like VirtualBox/VMware already anyway?
This is one of those weird requirements where you just know there’s some chaotic shit going on under the hood (of windows or bugchecker)