History

peony 498cfbf913 Removed error dump.		2024-12-01 13:39:40 +01:00
..
src	Uhm, I dunno how that got there.	2024-12-01 13:13:13 +01:00
meta.toml	PS/2 work	2024-11-10 21:24:19 +01:00
README.md	PS/2 literally almost work	2024-11-17 22:59:05 +01:00

README.md

Unified PS/2 Driver

Te entire thing is held together inspite

!!Assumptions!!

Anyone who works on this should work to keep this list as small as possible/remove as many of these as possible.

Bit 5 of the response form 0x64 indicates which port the data is coming from. (Not true on all systems)
A parity or timeout error never occurs.
PS/2 controller exists.
Both PS/2 ports being broken doesn't need handling.
One PS/2 port being broken doesn't need special attention.
PS/2 controller doesn't need to perform a self-check.
These DeviceIDs never exist:
- 0xFFFD
- 0xFFFE
- 0xFFFF
- 0x01xx
- 0x03xx
- 0x04xx
Literally all PS/2 keyboards can be handeled the exact same way. We have the capability for detecting different keyboard types, I just don't bother with it because that would litreally take months to get working.
The device doesn't send any data while we're waiting for an ACK.

Supporting mice in the keyboard port and vice versa was a bad idea, but I do not regret it because it means we're "superior" to real world operating systems.