Is PS/2 (as opposed to USB) enough for a keyboard driver?

[Lephe]

Hello OSDev!

I have an old kernel stub with PS/2 logic for keyboard input. It works well in QEMU and Virtualbox, but miserably fails on my physical machine (laptop). I suspect a bug in it (obviously), and I'll be writing it again from scratch soon. No big deal really, but it raised at lot of questions.

At the start, I thought that my laptop could have a USB keyboard, while I was sending orders to the PS/2 controller. I'm originally from the userspace programming world, and I like things that are properly defined and reliable. Clearly this (Brendan) lit a red blinking LED in my brain :

I'm guessing it doesn't and it's actually a USB keyboard, and you're relying on the "dodgy beyond belief" PS/2 emulation the firmware tries to do.

I'm assuming there is no reliable way of detecting which operations will be supported by the firmware, so here is my first question:

Is there a set of PS/2 operations that is considered "safe" to perform on emulated PS/2 controllers?

I searched the wiki and the forum for mentions of USB keyboards but found little. I may have missed crucial info; what came up is mainly this (LtG):

There are also USB keyboards, most (all?) MoBo's support translating USB keyboard into a PS/2, so you don't have to deal with USB. USB is significantly more complex and takes a lot more effort. PS/2 I think is pretty simple, read the wiki and the specs.

My main question is the following:

Is it suitable for a full-fledged OS to rely on this translation and consider keyboards to be PS/2 devices?

It seems to me that Linux views my keyboard as a PS/2 device. Here is the output of hwinfo --keyboard (/dev/input/event0 is indeed my laptop's keyboard):

Code: Select all

18: PS/2 00.0: 10800 Keyboard                                   
  [Created at input.226]
  Unique ID: nLyy.+49ps10DtUF
  Hardware Class: keyboard
  Model: "AT Translated Set 2 keyboard"
  Vendor: 0x0001 
  Device: 0x0001 "AT Translated Set 2 keyboard"
  Compatible to: int 0x0211 0x0001
  Device File: /dev/input/event0
  Device Number: char 13:64
  Driver Info #0:
    XkbRules: xfree86
    XkbModel: pc104
  Config Status: cfg=new, avail=yes, need=no, active=unknown

Or maybe it's actually a real PS/2 device... I don't know how to check this.

Any help would be greatly appreciated.

[DavidCooper]

Laptops typically have a real PS/2 connection rather than emulating one, although they can usually emulate one as well if you plug one in - both keyboards will work until you start fiddling with the USB controller(s), at which point one of them will stop responding. On newer machines where the screen can be detached to serve as a tablet, I suspect they're more likely to use USB for the keyboard connection, but I've never tested one to find out. Desktop machines are also more likely to use USB (unless they're old), so expect them to emulate the PS/2 keyboard.

Because USB keyboard PS/2 emulation breaks when you start talking to the USB controller, you cannot continue to rely on PS/2 emulation as your OS becomes more advanced - you will need to write USB drivers to access the keyboard and pointing devices, but there is good literature out there which can help you get past that stage. While developing your OS through that stage, it is best to work on a machine with a real PS/2 keyboard so that you can go on interacting with your OS while debugging your USB code. Either way, you don't want to skip the PS/2 driver stage - even if it's emulated, it should still provide basic functionality well enough for the machine to be usable while booting it up (which means your OS should be able to depend on it early on), but in answer to your main question, no - an advanced OS should not go on relying on emulated PS/2 keyboard because that will break long before your OS becomes fully fledged.

So, debug your PS/2 driver first - it should be able to get keyboard input even from a machine with dodgy emulation, but I suspect your machine has a real PS/2 keyboard anyway. Then start looking into USB, but to minimise unnecessary loss of life it's a good idea to buy a copy of Ben Lunt's book on the subject.

[Octocontrabass]

Is there a set of PS/2 operations that is considered "safe" to perform on emulated PS/2 controllers?

It's probably safe to assume the emulated PS/2 controller has been initialized by firmware to be compatible with DOS, which means it raises IRQ1 when a scan code is ready, and you can read port 0x60 to receive set 1 scan codes.

Is it suitable for a full-fledged OS to rely on this translation and consider keyboards to be PS/2 devices?

No. The firmware may not be able to emulate a PS/2 controller, and you can't support USB if you're using the emulated PS/2 controller.

[Brendan]

Hi,

Is there a set of PS/2 operations that is considered "safe" to perform on emulated PS/2 controllers?

If you split things into "initialisation" and "runtime"; I'd consider all of the "runtime" operations relatively safe (e.g. getting bytes from keyboard and setting keyboard LEDs). All of the "initialisation" stuff has a far higher risk of being emulated badly or not at all.

The main reason for this is that it was intended for ancient OSs (e.g. MS-DOS) that existed before USB was introduced, where these OSs had no drivers at all (relied on the BIOS to provide keyboard support) and where applications that "hook"/replace/extend the BIOS keyboard support also relied on the PS/2 controller and PS/2 devices already being initialised.

Is it suitable for a full-fledged OS to rely on this translation and consider keyboards to be PS/2 devices?

An OS can't be considered a full-fledged OS if it:

• Assumes that a PS/2 controller exists when it might not
• Assumes that a PS/2 controller is operating correctly when it might have become faulty
• Assumes that a PS/2 keyboard exists and is plugged into the first PS/2 port (and fails to do proper device auto-detection)
• Assumes that PS/2 devices are operating correctly when they might have become faulty
• Doesn't support "hot-plug PS/2" (including the old "mechanical switch" KVMs)
• Fails to be able to support completely unrelated USB devices (e.g. USB flash) because the OS can't prevent BIOS and its PS/2 emulation from interfering with USB controllers

Of course almost all of this requires using things are likely to cause problems with buggy and/or incomplete emulation in the "PS/2 emulation for USB" case. Even if you're willing to ignore the lack of support for unrelated USB devices; "PS/2 emulation" forces the OS to choose between "bad because it fails to do PS/2 initialisation properly" and "bad because it that fails to work properly on lots of computers because of buggy and/or incomplete firmware emulation of PS/2".

Note that a lot of beginners want to rush to get keyboard working; and they'll ruin everything (memory management, scheduling, device enumeration, etc) to get keyboard working badly. This is fine for a hobby/toy OS if and only if the goal is to learn about something else (e.g. if you only want to learn about GUIs then it doesn't really matter how bad everything else is or how much you avoided learning about everything else); but for other purposes (e.g. if you want learn everything needed to create a full fledged OS) its better to avoid wasting time doing work that needs to be discarded later because of "rushing".

It's not hard to disable "PS/2 emulation" in USB controllers (without doing anything else with USB controllers and without implementing USB support) so that you're able to write a PS/2 controller driver (and PS/2 keyboard/mouse/touchpad/whatever drivers) properly. It just means that (for anything that needs a keyboard) the OS will need real PS/2 keyboards (until you implement support for USB later).


Cheers,

Brendan

[Sik]

On newer machines where the screen can be detached to serve as a tablet, I suspect they're more likely to use USB for the keyboard connection, but I've never tested one to find out.

I had to deal with setting up one of those laptops once (running Windows 8​), the keyboard was connected over Bluetooth (even when attached - literally all attaching did was hold the screen on some clips, no actual electronic connection is made). Took a while to figure out why the keyboard was refusing to work. Thankfully getting to the control panel and then enabling Bluetooth could be done with just the touch screen.

No idea if the firmware ever tries to talk to Bluetooth keyboards during the boot sequence. I'm not hopeful about said keyboard ever being emulated as PS/2 (or even USB).


EDIT: spoiled by emoticons >_>

[Lephe]

So many answers! Thanks a lot

I have no specific goal, but I clearly want to do things properly. Taking your advice into account, my course of action right now would be:

• Develop a PS/2 driver with proper device detection, self-tests, etc.
• Use it for more advanced things like userspace, scheduling, or other drivers
• When I get to USB (later), debug it using my laptop's PS/2 keyboard and test it using an external USB keyboard

I now have a clearer understanding of what PS/2 emulation does, thanks. Originally my PS/2 driver initialization routine (roughly) performs a controller self-test, then checks for dual channels, performs interface tests, looks for devices, resets and finally enables them. Considering your answers, I don't feel very safe using this procedure on a machine with a motherboard-emulated PS/2 controller. Would the following be appropriate for keyboard detection?

• Boot the kernel without doing anything related to PS/2
• Disable PS/2 emulation in the USB controller
• Check for a real PS/2 controller and (possibly) a PS/2 keyboard
• Then check for USB keyboards

The other thing that bothers me is that according to the wiki, PS/2 controllers must be detected through ACPI before being used. But ACPI (and here I mean ACPICA which seems the most reasonable option to me) requires fairly advanced memory management, multithreading and scheduling (advanced features only?); I'm far from supporting all of this. May my OS crash from trying to use an non-existing PS/2 controller until I support ACPI?

Finally, since Brendan bothered to list some ways in which an OS can fail to properly manipulate devices, I'd like to know if the following solutions are suitable:

• Existence of PS/2 controller → ACPI tables?
• Correct operation of PS/2 controller → Controller self-test?
• Existence and "location" of PS/2 keyboard → Interface tests and Identify commands?
• Correct operation of PS/2 keyboard → Keyboard self-test?
• Hot-plug PS/2 → Wiki explains it, I'll check it out.
• USB driver → That would be for later on

Thanks again for your kind replies!

[Korona]

For non-legacy-free PCs (i.e. most, but not all PCs that are sold in 2017 and earlier) just assuming that the PS2 controller sits at ports 0x60 and 0x61. It is fine if your PS2 driver that assumes this, when you're starting to write an OS. As Brendan pointed out, it won't be fine for a full-fledged OS. It makes sense to keep in mind that these I/O ports (and the IRQ routing) need to be detected during runtime on some systems, so design your driver in a way that allows you to change that later on. However, I'd recommend you to prefer fast iteration (i.e. get the code running and then expand it) over investing too much time into designing the code's architecture.

You can do slightly better than just assuming that there is no USB emulation by disabling USB emulation before initializing the PS2 controller. This requires no knowledge of USB: You just need access to the PCI configuration space and to some {O,U,E,X}HCI registers and set some bits to disable the emulation. Later on, you can switch to ACPI to detect the controller and the PCI root bridges.

Yes, ACPICA requires access to a heap and some basic scheduling; however, that stuff should not be out of reach, even for smaller hobby projects. It will just take some time to implement it.

[Octocontrabass]

But ACPI (and here I mean ACPICA which seems the most reasonable option to me) requires fairly advanced memory management, multithreading and scheduling (advanced features only?); I'm far from supporting all of this.

You don't need most of that to find the table that will tell you if a PS/2 controller is present. All you have to do is find the FADT and see if it indicates the presence of a PS/2 controller. (Pay attention to the version of the FADT, too. Only version 3 and higher can indicate the presence of a PS/2 controller. For version 1, just assume a PS/2 controller is present. Version 2 doesn't exist.)

Correct operation of PS/2 controller → Controller self-test?

Some PS/2 controllers may always return success, so don't assume a successful self-test means it will be well-behaved. Some PS/2 controllers will reset all of their settings during the self-test, so you'll need to configure everything to sensible defaults afterwards.

[Brendan]

Hi,

I now have a clearer understanding of what PS/2 emulation does, thanks. Originally my PS/2 driver initialization routine (roughly) performs a controller self-test, then checks for dual channels, performs interface tests, looks for devices, resets and finally enables them. Considering your answers, I don't feel very safe using this procedure on a machine with a motherboard-emulated PS/2 controller. Would the following be appropriate for keyboard detection?

• Boot the kernel without doing anything related to PS/2
• Disable PS/2 emulation in the USB controller
• Check for a real PS/2 controller and (possibly) a PS/2 keyboard
• Then check for USB keyboards

For device enumeration in general (not PS/2 alone); my OS is designed to:

• Go through all the PCI devices; disable all "legacy emulation" possible (including "PS/2 emulation" in USB controllers, legacy ISA emulation in hard disk controllers, legacy VGA emulation in video controllers, ...); and then completely disable the devices themselves (so that they don't respond to anything on the PCI bus except PCI configuration space accesses).
• Do any manual detection of ancient ISA and legacy devices (e.g. ISA cards, floppy controller, serial ports, parallel ports, PS/2 controller, etc) after I'm sure that nothing modern can interfere with the manual detection.
• Start any drivers needed for ancient ISA and legacy devices
• Go through all the PCI devices a second time; trying to find device drivers for them and "re-enabling" the devices if a driver is found (as part of the device driver initialisation).

The other thing that bothers me is that according to the wiki, PS/2 controllers must be detected through ACPI before being used. But ACPI (and here I mean ACPICA which seems the most reasonable option to me) requires fairly advanced memory management, multithreading and scheduling (advanced features only?); I'm far from supporting all of this. May my OS crash from trying to use an non-existing PS/2 controller until I support ACPI?

ACPI can be split into 2 parts - reading stuff from tables (FADT, APIC/MADT, SLIT, SRAT, etc) during boot, and the run-time AML (ACPI Machine Language). The tables (during boot) are simple/easy and don't require much work at all. The run-time AML is a hideous nightmare.

Determining if a PS/2 controller exists is the former (just reading a single flag from a table) and doesn't involve anything complicated.

Finally, since Brendan bothered to list some ways in which an OS can fail to properly manipulate devices, I'd like to know if the following solutions are suitable:

• Existence of PS/2 controller → ACPI tables?
• Correct operation of PS/2 controller → Controller self-test?
• Existence and "location" of PS/2 keyboard → Interface tests and Identify commands?
• Correct operation of PS/2 keyboard → Keyboard self-test?
• Hot-plug PS/2 → Wiki explains it, I'll check it out.
• USB driver → That would be for later on

As a generic guideline; about 50% of a driver's code should be to detect and handle things that should never happen. Code to test the correct operation of the PS/2 controller would include the controller's self test feature and the interface tests; but there'd also be time-outs throughout the controller's initialisation code and various other checks. For example; if you're following the initialisation sequence described here, then you could check if the first PS/2 port is disabled (as expected) during "step 5", you'd have a time-out for "step 6" (in case the controller doesn't respond to the self test at all) and also in "step 7" (in case there's no response from the interface tests), etc. Any kind of abnormality would be treated as a "controller not operating correctly", until you reach "step 10" (which is the end of PS/2 controller initialisation and the beginning of PS/2 device initialisation).

Once the PS/2 controller is tested and initialised; you'd ask each PS/2 device what it is, and start a driver for whatever the device in each port says it is (e.g. if the device plugged into the second PS/2 port says that it's a keyboard, then you'd start a PS/2 keyboard driver for the device plugged into second PS/2 port).

The keyboard self-test (its response to the "reset" command) is the main test; but again there's a lot of time-outs (a time-out for every command sent to keyboard) and additional checks you can do (e.g. after the "set scancode set" command you could use the "get current scancode set" to check if the keyboard did the command properly); and then (during initialisation and at any time after that) the keyboard can send you a "key detection error or internal buffer overrun" status code.


Cheers,

Brendan

[Lephe]

All right, I was already checking the behavior of the controller at run-time (ensuring ACK, testing return values, etc.) but I had missed the possible timeouts. Checking the scan code set after changing it (as you suggested) also looks a wise thing to do. Unpredictable hardware is the worst... ^^

The way you disable emulation before checking for devices (as Korona pointed out) corresponds to what I had in mind (although I'll have to refine my device enumeration). I will also look into the simple parts of ACPI.

It seems that I suddenly have a lot to implement. Thanks again for your valuable help